From nobody Mon Jun 2 01:33:09 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5411A01B2 for ; Mon, 2 Jun 2014 01:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 xsZmz4s1pVCQ for ; Mon, 2 Jun 2014 01:33:03 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 369121A0105 for ; Mon, 2 Jun 2014 01:33:03 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::8] (unknown [IPv6:2001:67c:10ec:2a49:8000::8]) by trammell.ch (Postfix) with ESMTPSA id A1C1D1A0A54; Mon, 2 Jun 2014 10:32:55 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_F8D57F2A-1967-4087-AC0A-39D3259BC338"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Brian Trammell In-Reply-To: <5388FC56.6000705@gmail.com> Date: Mon, 2 Jun 2014 10:32:55 +0200 Message-Id: <6E13430E-5714-47C1-A84C-53B6E819DB0C@trammell.ch> References: <5387C0C1.3030909@gmail.com> <05c46a173690f08b6f910b090ac974ec.squirrel@www.erg.abdn.ac.uk> <5388B53D.1000406@erg.abdn.ac.uk> <5388FC56.6000705@gmail.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/mIrvjZUTFe7UK1r7_MdeLPMhmms Cc: Gorry Fairhurst , "Joe Hildebrand \(jhildebr\)" , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 08:33:05 -0000 --Apple-Mail=_F8D57F2A-1967-4087-AC0A-39D3259BC338 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Spencer, all, catching up on this thread in random-access order; replying only to the = process question here... On 30 May 2014, at 23:47, Spencer Dawkins = wrote: >=20 > On 05/30/2014 11:46 AM, Joe Hildebrand (jhildebr) wrote: >> On 5/30/14, 10:43 AM, "Gorry Fairhurst" wrote: >>=20 >>> Maybe I am hearing you wrong: My problem is that I'd argue that you = are >>> failing the WG before it starts, by somehow saying you can do the >>> analysis and setup the stack, but that the group won't publish the >>> networking specs that allow it to be used across a path to another >>> system? Or are you saying the group shouldn't be chartered until it = has >>> a candidate solution for this? - Either way I think either I or you = may >>> be confused. >> No, I'm suggesting the group recharter when it has a candidate = solution. >> Rechartering is relatively easy, particularly if you're showing signs = of >> success on the existing charter. >=20 > Hi, Joe et al. >=20 > So I'm not quite visualizing the proposal. Even rough text would help. >=20 > Guessing in anticipation of text arriving ... is the idea that the = working group to be would develop however many proposals as seem useful, = and then >=20 > IF one is blindingly obvious as the right thing to do > THEN publish as PS > ELSE IF people are willing to "experiment" with drafts > THEN experiment, and publish what works as PS > ELSE publish one or more Experimental RFCs and let 100 implementations = bloom? Speaking for myself, it seems to me that this is exactly what = Experimental RFCs _should_ be for, so I'd tend to lean toward a TAPS WG = that publishes implementable proposals for partial or complete solutions = to the transport evolution problem relatively quickly. I do share (what I read as) Joe's concern that the road from I-D to even = an experimental RFC tends to take a lot of energy that could be spend on = other things, so maybe we have a set of I-Ds with intended status = experimental that we only put the final energy into publication as an = RFC when it becomes obvious we want to reference later. (Whether all that belongs in _this_ charter as opposed to a subsequent = one is an open question in my mind.) Cheers, Brian > Or, if not, could you clue me in? >=20 > Thanks, >=20 > Spencer, who is quite pleased with the discussion so far >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_F8D57F2A-1967-4087-AC0A-39D3259BC338 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTjDa3AAoJENt3nsOmbNJcv9cH/2966bmCTyvTRjW4oFLA/pqp dBC+UntoZ1ID/vbUkObVzvb2Ky8dkxg8ktdi/QvoEfVYMCJSoFM27lZBbRZt68tx 4f5OYTGELzpX9OI17a8ZGHGKGCoTJwpmC3l9gttZQiwQiBX24N+G2htz3/PSWyEP NaBSW4syJ9Y6SduXEWdfkyX8A2cF3BoYMJUZl0AFzwfMao+fDk66ktstdAowIDaF hriM4t5kbL7aeDHq/QM8CD/ykh6xGsgtvf2gdhMWrGyVANugaOSKE7K2qtbH/kqQ Amf7ReN4UEC1cOUSNfFOsDGs63+I7fYL3BJRyLa65wW7fACkvjdhtasD5rvSBJY= =wP0Q -----END PGP SIGNATURE----- --Apple-Mail=_F8D57F2A-1967-4087-AC0A-39D3259BC338-- From nobody Mon Jun 2 01:49:29 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CE61A0192 for ; Mon, 2 Jun 2014 01:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 WELNmfczaQN8 for ; Mon, 2 Jun 2014 01:49:26 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id A02B21A0105 for ; Mon, 2 Jun 2014 01:49:25 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::8] (unknown [IPv6:2001:67c:10ec:2a49:8000::8]) by trammell.ch (Postfix) with ESMTPSA id 132231A0151; Mon, 2 Jun 2014 10:49:19 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_D44C482A-9C16-436A-BDEC-C3157EEF6251"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Brian Trammell In-Reply-To: Date: Mon, 2 Jun 2014 10:49:19 +0200 Message-Id: <08CA607F-BACE-4195-8C6A-FA43E81BE163@trammell.ch> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <5387BF2C.9010201@gmail.com> To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/YfjjG21ujNHSJ05FpRrShfeI15I Cc: Spencer Dawkins , "taps@ietf.org" Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 08:49:27 -0000 --Apple-Mail=_D44C482A-9C16-436A-BDEC-C3157EEF6251 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 30 May 2014, at 18:00, Joe Hildebrand (jhildebr) = wrote: > On 5/29/14, 5:13 PM, "Spencer Dawkins" > wrote: >=20 >> I believe Spencer was encouraging Brian (and it turns out I was using >> "Brian" as a multicast address that also resolves to "Joe", and any >> other IAB members who are listening) to tell us if the IAB is likely = to >> have a revised program that we could usefully refer to in the charter >> any time soon. >=20 > Brian is offline for a couple of days. I'm back and working my way through the thread... >> Unless the answer is some variant of "the IAB just approved a = relevant >> program", it's fine to leave the IAB unmentioned. >=20 > We've got some emerging consensus on the IAB on what the relevant = program > will be, but are not quite ready to announce it yet. I suggest = leaving a > placeholder that we'll fill in as the process progresses. On my list for today is putting down some language for this (which we = think but are not sure will be called the TCP/IP Evolution program) for = final discussion within the IAB; as this program's scope will most = probably be constrained to encouraging cross-area and cross-problem = coordination on transport evolution topics, I suspect that for topics = within the TAPS charter, the program's members will simply be = contributors to the TAPS WG, facilitating interaction with other WGs and = RGs. So a specific line item mentioning the IAB or an IAB program would = be nice but is IMO not necessary; we'll keep bothering the WG = regardless. ;) Cheers, Brian --Apple-Mail=_D44C482A-9C16-436A-BDEC-C3157EEF6251 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTjDqPAAoJENt3nsOmbNJc5jMH/1Ye6eNePDNOQI281D2/GrZ8 eU8oRkkYrx4imNZLB9KBUwRVHX0CimbKH0/BxyFjE14MOEsgv9F9T54F1mjIaXcr juHNGNm/OmX/xX0066UsvuzOXKZ6J569JTayZqhpdMsR/5u3RJ37btAILYuHhIVh a7OrWoQqalhL063vPG/irmRthH21zGHfu3c2kAstuffJwI5JsZXuj7V7P369MHMm 4puOowZu/mr0YkigzDK1O1WjyBlg00lJNVgbzliu4cOZLBcVeSJtdxXqkDXfDrIv miDtaPAsCyTo9yiq6CHlV6+V+FtqmGzcjTtZxsxeOEXrTO35h7kBPmnnVgNZRBQ= =Qc5w -----END PGP SIGNATURE----- --Apple-Mail=_D44C482A-9C16-436A-BDEC-C3157EEF6251-- From nobody Mon Jun 2 07:37:49 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0650F1A0219 for ; Mon, 2 Jun 2014 07:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 zm4xD6_rG4mg for ; Mon, 2 Jun 2014 07:37:44 -0700 (PDT) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079031A0205 for ; Mon, 2 Jun 2014 07:37:43 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id eb12so4723612oac.11 for ; Mon, 02 Jun 2014 07:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=uFxy5tgGiPqZb1MNCJ8ezIxl4FVQ89ljDcogLoYYRbU=; b=cAbP4A3dxgahvyOG6mPTFtvFU/52QslpvIrZCzZLGlpIRxsT8BizHDlIF1dTaZrJge oP9aSLZdt2Cr4dCdNeCopiC8Yug9oT0O/JK6mTvJlJyL5IW0vYNNtxDhLNYxjkCPjd92 Gj66/E1alSIQS3ju8zvzedgWFLyV3ASOgatki4iSiUBRunYNFL/OCw27XElPQYWRMjVt /OBMLsqpNfsRNr7K1ERVFkAUGFkjJa3ID4HoDjYnFP6Y/Vj6QKfEvF2UJgsbTM+oJMag 6mZfIpLDUk2MJXCa0NpllqFvgoPrnIOebGOu7dcGsyAbcV6HPnCLgaBMKmMQuWR2wziW wI7A== X-Received: by 10.60.131.232 with SMTP id op8mr38797568oeb.42.1401719858437; Mon, 02 Jun 2014 07:37:38 -0700 (PDT) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id f2sm26701866oeu.10.2014.06.02.07.37.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Jun 2014 07:37:37 -0700 (PDT) Message-ID: <538C8C30.3020702@gmail.com> Date: Mon, 02 Jun 2014 09:37:36 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brian Trammell , "Joe Hildebrand (jhildebr)" References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <5387BF2C.9010201@gmail.com> <08CA607F-BACE-4195-8C6A-FA43E81BE163@trammell.ch> In-Reply-To: <08CA607F-BACE-4195-8C6A-FA43E81BE163@trammell.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/40ve7Uuzgb955bnBxWBaJEQZYTs Cc: "taps@ietf.org" Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 14:37:46 -0000 On 06/02/2014 03:49 AM, Brian Trammell wrote: > On 30 May 2014, at 18:00, Joe Hildebrand (jhildebr) wrote: > >> On 5/29/14, 5:13 PM, "Spencer Dawkins" >> wrote: >> >>> I believe Spencer was encouraging Brian (and it turns out I was using >>> "Brian" as a multicast address that also resolves to "Joe", and any >>> other IAB members who are listening) to tell us if the IAB is likely to >>> have a revised program that we could usefully refer to in the charter >>> any time soon. >> Brian is offline for a couple of days. > I'm back and working my way through the thread... > >>> Unless the answer is some variant of "the IAB just approved a relevant >>> program", it's fine to leave the IAB unmentioned. >> We've got some emerging consensus on the IAB on what the relevant program >> will be, but are not quite ready to announce it yet. I suggest leaving a >> placeholder that we'll fill in as the process progresses. > On my list for today is putting down some language for this (which we think but are not sure will be called the TCP/IP Evolution program) for final discussion within the IAB; as this program's scope will most probably be constrained to encouraging cross-area and cross-problem coordination on transport evolution topics, I suspect that for topics within the TAPS charter, the program's members will simply be contributors to the TAPS WG, facilitating interaction with other WGs and RGs. Sounds fabulous. Thank you for closing on this. > So a specific line item mentioning the IAB or an IAB program would be nice but is IMO not necessary; we'll keep bothering the WG regardless. ;) And we sure as heck don't have to say in the charter that a working group can talk to the IAB :-) Spencer From nobody Mon Jun 2 08:35:57 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43E31A0366 for ; Mon, 2 Jun 2014 08:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 GWIWTv6yLgcX for ; Mon, 2 Jun 2014 08:35:55 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 096A71A035E for ; Mon, 2 Jun 2014 08:35:54 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id va2so4709636obc.23 for ; Mon, 02 Jun 2014 08:35:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=86XWkL9IePOO1hAOztnySd6HG4Ukxzm2gSynHE9J2Bc=; b=QrNafwKfPswGU0xwxg+O8M/hc00eHpGWtcGtB5vfphjJcTfEBwrMxnx+c1wOTYJ9Gi loiwFh20zRPsKPD7WFgtifNSCk91qdU4YTRNrt02tXTZSIYyXCeBz6YV9ZIBFEc8CP0c xzNPlvujLO4+rV/jFP4y2YdZSR0nLRh+IOMpHvRWbpGk3TkcOGcyVMp8+ri9yJe7Ih8B DDLhxIypJEsdHZwdU5ii+M22ruWuV5+j62AKcmVDvbmGqgzvoNq2je0kPNsoDkbifynG qSJONWt33BA2LCE/UoIymvmI3e+kosu+8VrAd+SKeoyCYsJW4I/aL3gdZo5TTYkXmnue o15g== X-Received: by 10.182.142.194 with SMTP id ry2mr38314037obb.5.1401723349413; Mon, 02 Jun 2014 08:35:49 -0700 (PDT) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id bq1sm20311648obb.20.2014.06.02.08.35.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Jun 2014 08:35:48 -0700 (PDT) Message-ID: <538C99D3.7040605@gmail.com> Date: Mon, 02 Jun 2014 10:35:47 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brian Trammell References: <5387C0C1.3030909@gmail.com> <05c46a173690f08b6f910b090ac974ec.squirrel@www.erg.abdn.ac.uk> <5388B53D.1000406@erg.abdn.ac.uk> <5388FC56.6000705@gmail.com> <6E13430E-5714-47C1-A84C-53B6E819DB0C@trammell.ch> In-Reply-To: <6E13430E-5714-47C1-A84C-53B6E819DB0C@trammell.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/I_s8-Sd3iSeYGOau5oB6jFjXFJ0 Cc: Gorry Fairhurst , "Joe Hildebrand \(jhildebr\)" , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 15:35:56 -0000 On 06/02/2014 03:32 AM, Brian Trammell wrote: > hi Spencer, all, > > catching up on this thread in random-access order; replying only to the process question here... > > On 30 May 2014, at 23:47, Spencer Dawkins wrote: > >> On 05/30/2014 11:46 AM, Joe Hildebrand (jhildebr) wrote: >>> On 5/30/14, 10:43 AM, "Gorry Fairhurst" wrote: >>> >>>> Maybe I am hearing you wrong: My problem is that I'd argue that you are >>>> failing the WG before it starts, by somehow saying you can do the >>>> analysis and setup the stack, but that the group won't publish the >>>> networking specs that allow it to be used across a path to another >>>> system? Or are you saying the group shouldn't be chartered until it has >>>> a candidate solution for this? - Either way I think either I or you may >>>> be confused. >>> No, I'm suggesting the group recharter when it has a candidate solution. >>> Rechartering is relatively easy, particularly if you're showing signs of >>> success on the existing charter. >> Hi, Joe et al. >> >> So I'm not quite visualizing the proposal. Even rough text would help. >> >> Guessing in anticipation of text arriving ... is the idea that the working group to be would develop however many proposals as seem useful, and then >> >> IF one is blindingly obvious as the right thing to do >> THEN publish as PS >> ELSE IF people are willing to "experiment" with drafts >> THEN experiment, and publish what works as PS >> ELSE publish one or more Experimental RFCs and let 100 implementations bloom? > Speaking for myself, it seems to me that this is exactly what Experimental RFCs _should_ be for, so I'd tend to lean toward a TAPS WG that publishes implementable proposals for partial or complete solutions to the transport evolution problem relatively quickly. I'd buy that. > I do share (what I read as) Joe's concern that the road from I-D to even an experimental RFC tends to take a lot of energy that could be spend on other things, so maybe we have a set of I-Ds with intended status experimental that we only put the final energy into publication as an RFC when it becomes obvious we want to reference later. > > (Whether all that belongs in _this_ charter as opposed to a subsequent one is an open question in my mind.) Practice varies across IESGs, but I believe this IESG is fine with saying "forward for publication" in the charter. Obviously, whatever a working group forwards for publication should contain a recommended document category, but the IESG can move it to a more appropriate category if that's the right thing to do, even after IETF Last Call, so don't spend a lot of angst on that. Spencer p.s. the only critical thing is that we do a Last Call at the highest level category we're considering. If you request publication on a PS that needs to be Experimental, no additional last call. If you request publication on an Experimental that needs to be PS, that requires a second Last Call. From http://tools.ietf.org/html/rfc2026#section-6.1.2: The IESG is not bound by the action recommended when the specification was submitted. For example, the IESG may decide to consider the specification for publication in a different category than that requested. If the IESG determines this before the Last- Call is issued then the Last-Call should reflect the IESG's view. The IESG could also decide to change the publication category based on the response to a Last-Call. If this decision would result in a specification being published at a "higher" level than the original Last-Call was for, a new Last-Call should be issued indicating the IESG recommendation. In addition, the IESG may decide to recommend the formation of a new Working Group in the case of significant controversy in response to a Last-Call for specification not originating from an IETF Working Group. From nobody Mon Jun 2 14:01:32 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9011E1A03F6 for ; Mon, 2 Jun 2014 14:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 OCNlgtl8D4GB for ; Mon, 2 Jun 2014 14:01:27 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 959C71A03EC for ; Mon, 2 Jun 2014 14:01:27 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id wo20so5133911obc.20 for ; Mon, 02 Jun 2014 14:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qev6Q/z1NYlVYrwYAiolLZ6YFRaskCsQsYl+wUpSaLM=; b=pJN+h+5NmQDMp5YeC5xOI3HrhLpFcX56Xh1eFEnUSL5tT4Zb8UXW5EuvUQuZrBq7PZ sDHx1+N4DqSQmAagmH25OBsJGYRc2C5soLS09NDQwlxWbMPCpz5XEqvfbPH9m/YyluiN lfq11BlY9MAvtR0K9k6oqLRmyJ5F0O/CnKazMtXhwx0ck0hxuQtI34or49em/WcC0E3N To/EG00vt3Ucv7oXNLVudZ2pFWpybc9FkhxqPacak64JsJLzb4a3Iv3wfG2Hnt1QLzdo Ix8luaWxSLvWxnndXrYjgPr8iKA7eY+NpBXBHnMPk+irn8hWqlEQusiBA8y8QxjrdobX RbXw== X-Received: by 10.182.95.100 with SMTP id dj4mr5733217obb.87.1401742882035; Mon, 02 Jun 2014 14:01:22 -0700 (PDT) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id x8sm3271038obw.0.2014.06.02.14.01.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Jun 2014 14:01:21 -0700 (PDT) Message-ID: <538CE61F.207@gmail.com> Date: Mon, 02 Jun 2014 16:01:19 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brian Trammell References: <5387C0C1.3030909@gmail.com> <05c46a173690f08b6f910b090ac974ec.squirrel@www.erg.abdn.ac.uk> <5388B53D.1000406@erg.abdn.ac.uk> <5388FC56.6000705@gmail.com> <6E13430E-5714-47C1-A84C-53B6E819DB0C@trammell.ch> <538C99D3.7040605@gmail.com> In-Reply-To: <538C99D3.7040605@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/VnDvG9jAlO2NyaVsCjCstHmrfqw Cc: Gorry Fairhurst , "Joe Hildebrand \(jhildebr\)" , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 21:01:29 -0000 On 06/02/2014 10:35 AM, Spencer Dawkins wrote: > > On 06/02/2014 03:32 AM, Brian Trammell wrote: >> hi Spencer, all, >> >> catching up on this thread in random-access order; replying only to >> the process question here... >> >> On 30 May 2014, at 23:47, Spencer Dawkins >> wrote: >> >>> On 05/30/2014 11:46 AM, Joe Hildebrand (jhildebr) wrote: >>>> On 5/30/14, 10:43 AM, "Gorry Fairhurst" wrote: >>>> >>>>> Maybe I am hearing you wrong: My problem is that I'd argue that >>>>> you are >>>>> failing the WG before it starts, by somehow saying you can do the >>>>> analysis and setup the stack, but that the group won't publish the >>>>> networking specs that allow it to be used across a path to another >>>>> system? Or are you saying the group shouldn't be chartered until >>>>> it has >>>>> a candidate solution for this? - Either way I think either I or >>>>> you may >>>>> be confused. >>>> No, I'm suggesting the group recharter when it has a candidate >>>> solution. >>>> Rechartering is relatively easy, particularly if you're showing >>>> signs of >>>> success on the existing charter. >>> Hi, Joe et al. >>> >>> So I'm not quite visualizing the proposal. Even rough text would help. >>> >>> Guessing in anticipation of text arriving ... is the idea that the >>> working group to be would develop however many proposals as seem >>> useful, and then >>> >>> IF one is blindingly obvious as the right thing to do >>> THEN publish as PS >>> ELSE IF people are willing to "experiment" with drafts >>> THEN experiment, and publish what works as PS >>> ELSE publish one or more Experimental RFCs and let 100 >>> implementations bloom? >> Speaking for myself, it seems to me that this is exactly what >> Experimental RFCs _should_ be for, so I'd tend to lean toward a TAPS >> WG that publishes implementable proposals for partial or complete >> solutions to the transport evolution problem relatively quickly. > > I'd buy that. > >> I do share (what I read as) Joe's concern that the road from I-D to >> even an experimental RFC tends to take a lot of energy that could be >> spend on other things, so maybe we have a set of I-Ds with intended >> status experimental that we only put the final energy into >> publication as an RFC when it becomes obvious we want to reference >> later. >> >> (Whether all that belongs in _this_ charter as opposed to a >> subsequent one is an open question in my mind.) > > Practice varies across IESGs, but I believe this IESG is fine with > saying "forward for publication" in the charter. > > Obviously, whatever a working group forwards for publication should > contain a recommended document category, but the IESG can move it to a > more appropriate category if that's the right thing to do, even after > IETF Last Call, so don't spend a lot of angst on that. > > Spencer So, just checking in. I'd like to see an updated charter proposal that reflects recent mailing list discussion, including dropping the specifics about document category, so that the folks on the mailing list can check whether their concerns have been addressed. One more process thing - if I'm getting feedback I can live with when the charter's reviewed on this mailing list, I'd like to put TAPS forward for chartering before IETF 90, but the slot request cutoff is coming up really soon (specifically, 2014-06-06, this coming Friday), so you can expect to see TAPS on the BOF wiki with something like the charter you've been discussing, to make sure it gets a slot. Questions? Comments? Spencer From nobody Mon Jun 2 14:47:39 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4191A0460 for ; Mon, 2 Jun 2014 14:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 rz56XNufVpmM for ; Mon, 2 Jun 2014 14:47:35 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 261A51A036E for ; Mon, 2 Jun 2014 14:47:35 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Wra4g-00060U-D6; Mon, 02 Jun 2014 23:47:22 +0200 Received: from [148.122.12.38] (helo=[10.10.0.155]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Wra4f-00010X-OY; Mon, 02 Jun 2014 23:47:22 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_4F0686DA-FCBC-40B3-B561-E37A61C9E2BB" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <538CE61F.207@gmail.com> Date: Mon, 2 Jun 2014 23:47:20 +0200 Message-Id: <8543296F-9F16-4188-A3F0-D273C9919BB8@ifi.uio.no> References: <5387C0C1.3030909@gmail.com> <05c46a173690f08b6f910b090ac974ec.squirrel@www.erg.abdn.ac.uk> <5388B53D.1000406@erg.abdn.ac.uk> <5388FC56.6000705@gmail.com> <6E13430E-5714-47C1-A84C-53B6E819DB0C@trammell.ch> <538C99D3.7040605@gmail.com> <538CE61F.207@gmail.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 10 msgs/h 4 sum rcpts/h 10 sum msgs/h 4 total rcpts 17145 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 8D60021F5585DF694E716FA2A0515A7A1C602CD8 X-UiO-SPAM-Test: remote_host: 148.122.12.38 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 41 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/ySpCil9B4aJROS-50vs-mhKGEvE Cc: "gorry@erg.abdn.ac.uk \(erg\)" , Brian Trammell , "Joe Hildebrand \(jhildebr\)" , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 21:47:38 -0000 --Apple-Mail=_4F0686DA-FCBC-40B3-B561-E37A61C9E2BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi! Spencer, thank you very much for this update. Much appreciated! Regarding the charter bit, let's try to figure out what specifically is = needed. Here's the link to the always-most-up-to-date version: https://sites.google.com/site/transportprotocolservices/charter-proposal You wrote: > I'd like to see an updated charter proposal that reflects recent = mailing list discussion, including dropping the specifics about document = category, so that the folks on the mailing list can check whether their = concerns have been addressed. What exactly do you mean with "dropping the specifics about document = category" - is the suggestion to change WG goal #1, which now reads: "identify services provided by existing IETF transport protocols and = congestion control mechanisms, based on Standards-track and Experimental = RFCs." to ""identify services provided by existing IETF transport protocols and = congestion control mechanisms" ? For other changes, I'll try to recap the current state; please, all, if = you feel I'm misrepresenting things, 1) it's definitely not = intentionally, 2) by all means correct me! The way I see it, we have 2 issues to discuss. ISSUE 1: ------------ We had some consensus on the charter as it currently stands; then, there = was the comment by Aaron about a small wording change that I had missed, = in WG goal #2, which currently reads: "specify a set of transport services that end systems need to provide = and provide guidance on choosing among available mechanisms and = protocols to obtain a given transport service." Joe spoke against Aaron's change and offered an alternative proposal, = which again Gorry didn't like, saying that it seems to him to be a big = change in what he's seen on the list.=20 My question at this point is: can we keep the original text of goal #2 = as I quote it here, or does anybody have yet another proposal that we = all can live with? ISSUE 2: ------------ There were some arguments about the need for WG goal #3, mechanisms to = discover the availability of protocols... - and it seems that several = of us want to keep it. Can we (with the current text), or do we need to = discuss this more? Any other issues? Shoot, all :-) Cheers, Michael --Apple-Mail=_4F0686DA-FCBC-40B3-B561-E37A61C9E2BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi!

Spencer, thank you very much = for this update. Much appreciated!

Regarding = the charter bit, let's try to figure out what specifically is needed. = Here's the link to the always-most-up-to-date version:

You = wrote:

I'd like to see an updated charter = proposal that reflects recent mailing list discussion, including = dropping the specifics about document category, so that the folks on the = mailing list can check whether their concerns have been = addressed.

What exactly do you = mean with "dropping the specifics about document category" - is the = suggestion to change WG goal #1, which now reads:
"identify = services provided by existing IETF transport protocols and congestion = control mechanisms, based on Standards-track and Experimental = RFCs."
to
""identify services provided by = existing IETF transport protocols and congestion control mechanisms" = ?


For other changes, I'll try to = recap the current state; please, all, if you feel I'm misrepresenting = things, 1) it's definitely not intentionally, 2) by all means correct = me!


The way I see it, we = have 2 issues to discuss.


ISSUE = 1:
------------

We had some consensus = on the charter as it currently stands; then, there was the comment by = Aaron about a small wording change that I had missed, in WG goal #2, = which currently reads:

"specify a set of = transport services that end systems need to provide and provide = guidance on choosing among available mechanisms and protocols to = obtain a given transport service."

Joe spoke = against Aaron's change and offered an alternative proposal, which again = Gorry didn't like, saying that it seems to him to be a big change in = what he's seen on the list. 

My question = at this point is: can we keep the original text of goal #2 as I quote it = here, or does anybody have yet another proposal that we all can live = with?


ISSUE = 2:
------------

There were some = arguments about the need for WG goal #3, mechanisms to discover the = availability of protocols...   - and it seems that several of us = want to keep it. Can we (with the current text), or do we need to = discuss this = more?



Any other = issues? Shoot, all =  :-)

Cheers,
Michael
= --Apple-Mail=_4F0686DA-FCBC-40B3-B561-E37A61C9E2BB-- From nobody Mon Jun 2 15:03:08 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9FE1A0414 for ; Mon, 2 Jun 2014 15:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 J78TaI-jYBrC for ; Mon, 2 Jun 2014 15:03:02 -0700 (PDT) Received: from mail-vc0-f200.google.com (mail-vc0-f200.google.com [209.85.220.200]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 189C41A0431 for ; Mon, 2 Jun 2014 15:03:01 -0700 (PDT) Received: by mail-vc0-f200.google.com with SMTP id la4so4125222vcb.7 for ; Mon, 02 Jun 2014 15:02:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=FvJO80XaRTXCyOD34tDGkZiLSlwwF4WETPbhviR7B34=; b=mYmTyCso33VDYbhbp6MS1cWRzXk2MGuJ/i1hRW07Wngkub/ZQvQPP67+12y/L/6Rxk HnkgmfCekNuWdBwbT3R0q30meRcq5Qt4HSX0mdKoV3jZUsGS5AvAjVytCaDgPSd/N1ey Tz+8JwEWkhGtLfIi/eIucwb5oA1w5PwCA08P0cCUGV1WjQqrMY1QqvRUIZ88alAqr8o8 2rLoppZcGrpEtMgZfq+y1rKOj85MArrndhIvmBznPosR7I38GvwvI4rui+m0afFZ6yP4 p5Q9/yCwO6qQVdM1b6n5Bbof6WaFOC1kl6mO8bQfZTP9U4a4GnKGabVNe4rJ1nyqTYLj ZhVw== X-Gm-Message-State: ALoCoQk+BrbW4P7l7NgwandP4m0ux0FyNKbPHJNpB0LlEZpU4/QNeAb49d07Gc6MKQr0CPbbicwX X-Received: by 10.52.121.19 with SMTP id lg19mr2698521vdb.54.1401746574033; Mon, 02 Jun 2014 15:02:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.85.72 with HTTP; Mon, 2 Jun 2014 15:02:33 -0700 (PDT) In-Reply-To: <8543296F-9F16-4188-A3F0-D273C9919BB8@ifi.uio.no> References: <5387C0C1.3030909@gmail.com> <05c46a173690f08b6f910b090ac974ec.squirrel@www.erg.abdn.ac.uk> <5388B53D.1000406@erg.abdn.ac.uk> <5388FC56.6000705@gmail.com> <6E13430E-5714-47C1-A84C-53B6E819DB0C@trammell.ch> <538C99D3.7040605@gmail.com> <538CE61F.207@gmail.com> <8543296F-9F16-4188-A3F0-D273C9919BB8@ifi.uio.no> From: Aaron Falk Date: Mon, 2 Jun 2014 18:02:33 -0400 Message-ID: To: Michael Welzl Content-Type: multipart/alternative; boundary=089e013a1b1c9c5d7404fae18e7c Archived-At: http://mailarchive.ietf.org/arch/msg/taps/8kW5p-IpNvjUYOPTkLmVO52bKEg Cc: "gorry@erg.abdn.ac.uk \(erg\)" , Brian Trammell , Spencer Dawkins , "Joe Hildebrand \(jhildebr\)" , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 22:03:06 -0000 --089e013a1b1c9c5d7404fae18e7c Content-Type: text/plain; charset=UTF-8 Michael- I'm actually OK with Joe's proposed wording: On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > On 5/30/14, 8:29 AM, "Aaron Falk" wrote: > > >My proposed wording change (which at least Gorry accepted) is not in the > >current draft. Repeating: > > > > > >Revise working group goal #2 to read "specify a set of transport services > >that end systems **implementing TAPS** need to provide and provide > >guidance on choosing among available mechanisms and protocols to obtain a > >given transport service." > > There's no protocol for TAPS yet, so nobody is going to "implement TAPS". > Suggested change: "end systems need to provide" -> "applications want to > use". It allows the wg more flexibility which is probably appropriate in this stage. --aaron On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl wrote: > Hi! > > Spencer, thank you very much for this update. Much appreciated! > > Regarding the charter bit, let's try to figure out what specifically is > needed. Here's the link to the always-most-up-to-date version: > https://sites.google.com/site/transportprotocolservices/charter-proposal > > You wrote: > > I'd like to see an updated charter proposal that reflects recent mailing > list discussion, including dropping the specifics about document category, > so that the folks on the mailing list can check whether their concerns have > been addressed. > > > What exactly do you mean with "dropping the specifics about document > category" - is the suggestion to change WG goal #1, which now reads: > "identify services provided by existing IETF transport protocols and > congestion control mechanisms, based on Standards-track and Experimental > RFCs." > to > ""identify services provided by existing IETF transport protocols and > congestion control mechanisms" ? > > > For other changes, I'll try to recap the current state; please, all, if > you feel I'm misrepresenting things, 1) it's definitely not intentionally, > 2) by all means correct me! > > > The way I see it, we have 2 issues to discuss. > > > ISSUE 1: > ------------ > > We had some consensus on the charter as it currently stands; then, there > was the comment by Aaron about a small wording change that I had missed, in > WG goal #2, which currently reads: > > "specify a set of transport services that end systems need to provide > and provide guidance on choosing among available mechanisms and protocols > to obtain a given transport service." > > Joe spoke against Aaron's change and offered an alternative proposal, > which again Gorry didn't like, saying that it seems to him to be a big > change in what he's seen on the list. > > My question at this point is: can we keep the original text of goal #2 as > I quote it here, or does anybody have yet another proposal that we all can > live with? > > > ISSUE 2: > ------------ > > There were some arguments about the need for WG goal #3, mechanisms to > discover the availability of protocols... - and it seems that several of > us want to keep it. Can we (with the current text), or do we need to > discuss this more? > > > > Any other issues? Shoot, all :-) > > Cheers, > Michael > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > > --089e013a1b1c9c5d7404fae18e7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Michael-

I'm actually OK with Joe&#= 39;s proposed wording:

On Fri, May 30, 2014 at 11:= 55 AM, Joe Hildebrand (jhildebr)=C2=A0<jhildebr@cisco.com>= =C2=A0wrote:
On 5/30/14, 8:29 AM, "Aaron Falk"= ; <falk-ietf@dgftech.com>= ; wrote:

>My proposed wording change (which at least Gorry accepted) is not i= n the
>current draft. =C2=A0Repeating:
>
>
>Revise = working group goal #2 to read "specify a set of transport services
>that end systems **implementing TAPS** need to provide and provide
>guidance on choosing among available mechanisms and protocols to obtain= a
>given transport service."

There's no protoc= ol for TAPS yet, so nobody is going to "implement TAPS".
Suggested change: "end systems need to provide" -> "appli= cations want to
use".

It allows the wg more flexibilit= y which is probably appropriate in this stage.

--a= aron
=C2=A0


<= div class=3D"gmail_quote"> On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl <michawe@ifi.uio.no>= wrote:
Hi!

Spencer, thank y= ou very much for this update. Much appreciated!

Re= garding the charter bit, let's try to figure out what specifically is n= eeded. Here's the link to the always-most-up-to-date version:

You wrote:

I'd like to see an updated charter proposal that reflects recent mailin= g list discussion, including dropping the specifics about document category= , so that the folks on the mailing list can check whether their concerns ha= ve been addressed.

What exactly do you mean with = "dropping the specifics about document category" - is the suggest= ion to change WG goal #1, which now reads:
"identify service= s provided by existing IETF transport protocols and congestion control mech= anisms, based on Standards-track and Experimental RFCs."
to
""identify services provided by existing = IETF transport protocols and congestion control mechanisms" ?


For other changes, I'll try to recap th= e current state; please, all, if you feel I'm misrepresenting things, 1= ) it's definitely not intentionally, 2) by all means correct me!


The way I see it, we have 2 issues= to discuss.


ISSUE 1:
---= ---------

We had some consensus on the charter as = it currently stands; then, there was the comment by Aaron about a small wor= ding change that I had missed, in WG goal #2, which currently reads:

"specify a set of transport services that end syst= ems need to provide and=C2=A0provide guidance on choosing among available m= echanisms and=C2=A0protocols to obtain a given transport service."

Joe spoke against Aaron's change and offered an alternat= ive proposal, which again Gorry didn't like, saying that it seems to hi= m to be a big change in what he's seen on the list.=C2=A0
My question at this point is: can we keep the original text of g= oal #2 as I quote it here, or does anybody have yet another proposal that w= e all can live with?


ISSUE 2:<= /div>
------------

There were some arguments = about the need for WG goal #3, mechanisms to discover the availability of p= rotocols... =C2=A0 - and it seems that several of us want to keep it. Can w= e (with the current text), or do we need to discuss this more?



Any other issues? Shoot, = all =C2=A0:-)

Cheers,
Michael
=

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


--089e013a1b1c9c5d7404fae18e7c-- From nobody Mon Jun 2 15:13:17 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A821A0422 for ; Mon, 2 Jun 2014 15:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 wq-BQTmk7r06 for ; Mon, 2 Jun 2014 15:13:12 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30D8F1A03C9 for ; Mon, 2 Jun 2014 15:13:12 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WraTZ-0002O2-NF; Tue, 03 Jun 2014 00:13:05 +0200 Received: from [148.122.12.38] (helo=[10.10.1.109]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1WraTY-0003aL-JK; Tue, 03 Jun 2014 00:13:05 +0200 References: <5387C0C1.3030909@gmail.com> <05c46a173690f08b6f910b090ac974ec.squirrel@www.erg.abdn.ac.uk> <5388B53D.1000406@erg.abdn.ac.uk> <5388FC56.6000705@gmail.com> <6E13430E-5714-47C1-A84C-53B6E819DB0C@trammell.ch> <538C99D3.7040605@gmail.com> <538CE61F.207@gmail.com> <8543296F-9F16-4188-A3F0-D273C9919BB8@ifi.uio.no> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-182CC19E-BA79-4DB1-B11C-662583934660 Content-Transfer-Encoding: 7bit Message-Id: <5ACF2F3E-2967-4C03-B055-1F4111873ECD@ifi.uio.no> X-Mailer: iPhone Mail (11D167) From: Michael Welzl Date: Tue, 3 Jun 2014 00:13:03 +0200 To: Aaron Falk X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 1 sum rcpts/h 11 sum msgs/h 3 total rcpts 17152 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D1B6B22090FE7741E0A1BAB4B3F8415B3E380CA2 X-UiO-SPAM-Test: remote_host: 148.122.12.38 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 43 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/884lxBT24dt4v_bzv2FZxnkM2Bw Cc: "gorry@erg.abdn.ac.uk \(erg\)" , Brian Trammell , Spencer Dawkins , "Joe Hildebrand \(jhildebr\)" , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 22:13:14 -0000 --Apple-Mail-182CC19E-BA79-4DB1-B11C-662583934660 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable other opinions? (myself, i'm neutral) Sent from my iPhone > On 3. juni 2014, at 00:02, Aaron Falk wrote: >=20 > Michael- >=20 > I'm actually OK with Joe's proposed wording: >=20 >> On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (jhildebr) wrote: >> On 5/30/14, 8:29 AM, "Aaron Falk" wrote: >>=20 >> >My proposed wording change (which at least Gorry accepted) is not in the= >> >current draft. Repeating: >> > >> > >> >Revise working group goal #2 to read "specify a set of transport service= s >> >that end systems **implementing TAPS** need to provide and provide >> >guidance on choosing among available mechanisms and protocols to obtain a= >> >given transport service." >>=20 >> There's no protocol for TAPS yet, so nobody is going to "implement TAPS".= >> Suggested change: "end systems need to provide" -> "applications want to >> use". >=20 > It allows the wg more flexibility which is probably appropriate in this st= age. >=20 > --aaron > =20 >=20 >=20 >> On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl wrote:= >> Hi! >>=20 >> Spencer, thank you very much for this update. Much appreciated! >>=20 >> Regarding the charter bit, let's try to figure out what specifically is n= eeded. Here's the link to the always-most-up-to-date version: >> https://sites.google.com/site/transportprotocolservices/charter-proposal >>=20 >> You wrote: >>=20 >>> I'd like to see an updated charter proposal that reflects recent mailing= list discussion, including dropping the specifics about document category, s= o that the folks on the mailing list can check whether their concerns have b= een addressed. >>=20 >> What exactly do you mean with "dropping the specifics about document cate= gory" - is the suggestion to change WG goal #1, which now reads: >> "identify services provided by existing IETF transport protocols and cong= estion control mechanisms, based on Standards-track and Experimental RFCs." >> to >> ""identify services provided by existing IETF transport protocols and con= gestion control mechanisms" ? >>=20 >>=20 >> For other changes, I'll try to recap the current state; please, all, if y= ou feel I'm misrepresenting things, 1) it's definitely not intentionally, 2)= by all means correct me! >>=20 >>=20 >> The way I see it, we have 2 issues to discuss. >>=20 >>=20 >> ISSUE 1: >> ------------ >>=20 >> We had some consensus on the charter as it currently stands; then, there w= as the comment by Aaron about a small wording change that I had missed, in W= G goal #2, which currently reads: >>=20 >> "specify a set of transport services that end systems need to provide and= provide guidance on choosing among available mechanisms and protocols to ob= tain a given transport service." >>=20 >> Joe spoke against Aaron's change and offered an alternative proposal, whi= ch again Gorry didn't like, saying that it seems to him to be a big change i= n what he's seen on the list.=20 >>=20 >> My question at this point is: can we keep the original text of goal #2 as= I quote it here, or does anybody have yet another proposal that we all can l= ive with? >>=20 >>=20 >> ISSUE 2: >> ------------ >>=20 >> There were some arguments about the need for WG goal #3, mechanisms to di= scover the availability of protocols... - and it seems that several of us w= ant to keep it. Can we (with the current text), or do we need to discuss thi= s more? >>=20 >>=20 >>=20 >> Any other issues? Shoot, all :-) >>=20 >> Cheers, >> Michael >>=20 >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 --Apple-Mail-182CC19E-BA79-4DB1-B11C-662583934660 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
other opinions? (myself, i'm neutral)

Sent from my iPhone

On 3. juni 2014, at 00:02, Aaron Falk <falk-ietf@dgftech.com> wrote:

Michael-

I'm actually OK with Joe's proposed wording:

On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:
On 5/30/14, 8:29 AM, "Aaron Falk" <falk-ietf@dgftech.com> wrote:

>My proposed wording change (which at least Gorry accepted) is not in the
>current draft.  Repeating:
>
>
>Revise working group goal #2 to read "specify a set of transport services
>that end systems **implementing TAPS** need to provide and provide
>guidance on choosing among available mechanisms and protocols to obtain a
>given transport service."

There's no protocol for TAPS yet, so nobody is going to "implement TAPS".
Suggested change: "end systems need to provide" -> "applications want to
use".

It allows the wg more flexibility which is probably appropriate in this stage.

--aaron
 


On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl <michawe@ifi.uio.no> wrote:
Hi!

Spencer, thank you very much for this update. Much appreciated!

Regarding the charter bit, let's try to figure out what specifically is needed. Here's the link to the always-most-up-to-date version:

You wrote:

I'd like to see an updated charter proposal that reflects recent mailing list discussion, including dropping the specifics about document category, so that the folks on the mailing list can check whether their concerns have been addressed.

What exactly do you mean with "dropping the specifics about document category" - is the suggestion to change WG goal #1, which now reads:
"identify services provided by existing IETF transport protocols and congestion control mechanisms, based on Standards-track and Experimental RFCs."
to
""identify services provided by existing IETF transport protocols and congestion control mechanisms" ?


For other changes, I'll try to recap the current state; please, all, if you feel I'm misrepresenting things, 1) it's definitely not intentionally, 2) by all means correct me!


The way I see it, we have 2 issues to discuss.


ISSUE 1:
------------

We had some consensus on the charter as it currently stands; then, there was the comment by Aaron about a small wording change that I had missed, in WG goal #2, which currently reads:

"specify a set of transport services that end systems need to provide and provide guidance on choosing among available mechanisms and protocols to obtain a given transport service."

Joe spoke against Aaron's change and offered an alternative proposal, which again Gorry didn't like, saying that it seems to him to be a big change in what he's seen on the list. 

My question at this point is: can we keep the original text of goal #2 as I quote it here, or does anybody have yet another proposal that we all can live with?


ISSUE 2:
------------

There were some arguments about the need for WG goal #3, mechanisms to discover the availability of protocols...   - and it seems that several of us want to keep it. Can we (with the current text), or do we need to discuss this more?



Any other issues? Shoot, all  :-)

Cheers,
Michael


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


--Apple-Mail-182CC19E-BA79-4DB1-B11C-662583934660-- From nobody Mon Jun 2 15:44:42 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6EA1A03E7 for ; Mon, 2 Jun 2014 15:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 elgu6NwI3xgC for ; Mon, 2 Jun 2014 15:44:38 -0700 (PDT) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E94111A0330 for ; Mon, 2 Jun 2014 15:44:37 -0700 (PDT) X-Spam-Processed: mail.kau.se, Tue, 03 Jun 2014 00:44:21 +0200 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: annabrun@kau.se X-MDRemoteIP: 89.233.217.70 X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se X-MDaemon-Deliver-To: taps@ietf.org Message-ID: <538CFE49.6020706@kau.se> Date: Tue, 03 Jun 2014 00:44:25 +0200 From: Anna Brunstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: taps@ietf.org References: <5387C0C1.3030909@gmail.com> <05c46a173690f08b6f910b090ac974ec.squirrel@www.erg.abdn.ac.uk> <5388B53D.1000406@erg.abdn.ac.uk> <5388FC56.6000705@gmail.com> <6E13430E-5714-47C1-A84C-53B6E819DB0C@trammell.ch> <538C99D3.7040605@gmail.com> <538CE61F.207@gmail.com> <8543296F-9F16-4188-A3F0-D273C9919BB8@ifi.uio.no> <5ACF2F3E-2967-4C03-B055-1F4111873ECD@ifi.uio.no> In-Reply-To: <5ACF2F3E-2967-4C03-B055-1F4111873ECD@ifi.uio.no> Content-Type: multipart/alternative; boundary="------------090306070109020402030109" Archived-At: http://mailarchive.ietf.org/arch/msg/taps/_pmDjwwvqTukAIfP2HqRNmSC6Ts Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 22:44:41 -0000 This is a multi-part message in MIME format. --------------090306070109020402030109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I do not like "applications want to use". The application requirements give input for the services to specify, but to say that we should specify what applications want to use sounds strange to me. I think the current formulation is better and more clear. I am also fine with the "implementing TAPS" addition that Aaron suggested. But as Joe did not like "implementing", how about: "specify a set of transport services that end systems supporting TAPS need to provide and provide guidance on choosing among available mechanisms and protocols to obtain a given transport service." Anna On 2014-06-03 00:13, Michael Welzl wrote: > other opinions? (myself, i'm neutral) > > Sent from my iPhone > > On 3. juni 2014, at 00:02, Aaron Falk > wrote: > >> Michael- >> >> I'm actually OK with Joe's proposed wording: >> >> On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (jhildebr) >> > wrote: >> >> On 5/30/14, 8:29 AM, "Aaron Falk" > > wrote: >> >> >My proposed wording change (which at least Gorry accepted) is >> not in the >> >current draft. Repeating: >> > >> > >> >Revise working group goal #2 to read "specify a set of transport >> services >> >that end systems **implementing TAPS** need to provide and provide >> >guidance on choosing among available mechanisms and protocols to >> obtain a >> >given transport service." >> >> There's no protocol for TAPS yet, so nobody is going to >> "implement TAPS". >> Suggested change: "end systems need to provide" -> "applications >> want to >> use". >> >> >> It allows the wg more flexibility which is probably appropriate in >> this stage. >> >> --aaron >> >> >> On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl > > wrote: >> >> Hi! >> >> Spencer, thank you very much for this update. Much appreciated! >> >> Regarding the charter bit, let's try to figure out what >> specifically is needed. Here's the link to the >> always-most-up-to-date version: >> https://sites.google.com/site/transportprotocolservices/charter-proposal >> >> You wrote: >> >>> I'd like to see an updated charter proposal that reflects recent >>> mailing list discussion, including dropping the specifics about >>> document category, so that the folks on the mailing list can >>> check whether their concerns have been addressed. >> >> What exactly do you mean with "dropping the specifics about >> document category" - is the suggestion to change WG goal #1, >> which now reads: >> "identify services provided by existing IETF transport protocols >> and congestion control mechanisms, based on Standards-track and >> Experimental RFCs." >> to >> ""identify services provided by existing IETF transport protocols >> and congestion control mechanisms" ? >> >> >> For other changes, I'll try to recap the current state; please, >> all, if you feel I'm misrepresenting things, 1) it's definitely >> not intentionally, 2) by all means correct me! >> >> >> The way I see it, we have 2 issues to discuss. >> >> >> ISSUE 1: >> ------------ >> >> We had some consensus on the charter as it currently stands; >> then, there was the comment by Aaron about a small wording change >> that I had missed, in WG goal #2, which currently reads: >> >> "specify a set of transport services that end systems need to >> provide and provide guidance on choosing among available >> mechanisms and protocols to obtain a given transport service." >> >> Joe spoke against Aaron's change and offered an alternative >> proposal, which again Gorry didn't like, saying that it seems to >> him to be a big change in what he's seen on the list. >> >> My question at this point is: can we keep the original text of >> goal #2 as I quote it here, or does anybody have yet another >> proposal that we all can live with? >> >> >> ISSUE 2: >> ------------ >> >> There were some arguments about the need for WG goal #3, >> mechanisms to discover the availability of protocols... - and >> it seems that several of us want to keep it. Can we (with the >> current text), or do we need to discuss this more? >> >> >> >> Any other issues? Shoot, all :-) >> >> Cheers, >> Michael >> >> >> _______________________________________________ >> 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 --------------090306070109020402030109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

I do not like "applications want to use". The application requirements give input for the services to specify, but to say that we should specify what applications want to use sounds strange to me.

I think the current formulation is better and more clear. I am also fine with the "implementing TAPS" addition that Aaron suggested. But as Joe did not like "implementing", how about:

"specify a set of transport services that end systems supporting TAPS need to provide and provide guidance on choosing among available mechanisms and protocols to obtain a given transport service."

Anna


On 2014-06-03 00:13, Michael Welzl wrote:
other opinions? (myself, i'm neutral)

Sent from my iPhone

On 3. juni 2014, at 00:02, Aaron Falk <falk-ietf@dgftech.com> wrote:

Michael-

I'm actually OK with Joe's proposed wording:

On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:
On 5/30/14, 8:29 AM, "Aaron Falk" <falk-ietf@dgftech.com> wrote:

>My proposed wording change (which at least Gorry accepted) is not in the
>current draft.  Repeating:
>
>
>Revise working group goal #2 to read "specify a set of transport services
>that end systems **implementing TAPS** need to provide and provide
>guidance on choosing among available mechanisms and protocols to obtain a
>given transport service."

There's no protocol for TAPS yet, so nobody is going to "implement TAPS".
Suggested change: "end systems need to provide" -> "applications want to
use".

It allows the wg more flexibility which is probably appropriate in this stage.

--aaron
 


On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl <michawe@ifi.uio.no> wrote:
Hi!

Spencer, thank you very much for this update. Much appreciated!

Regarding the charter bit, let's try to figure out what specifically is needed. Here's the link to the always-most-up-to-date version:

You wrote:

I'd like to see an updated charter proposal that reflects recent mailing list discussion, including dropping the specifics about document category, so that the folks on the mailing list can check whether their concerns have been addressed.

What exactly do you mean with "dropping the specifics about document category" - is the suggestion to change WG goal #1, which now reads:
"identify services provided by existing IETF transport protocols and congestion control mechanisms, based on Standards-track and Experimental RFCs."
to
""identify services provided by existing IETF transport protocols and congestion control mechanisms" ?


For other changes, I'll try to recap the current state; please, all, if you feel I'm misrepresenting things, 1) it's definitely not intentionally, 2) by all means correct me!


The way I see it, we have 2 issues to discuss.


ISSUE 1:
------------

We had some consensus on the charter as it currently stands; then, there was the comment by Aaron about a small wording change that I had missed, in WG goal #2, which currently reads:

"specify a set of transport services that end systems need to provide and provide guidance on choosing among available mechanisms and protocols to obtain a given transport service."

Joe spoke against Aaron's change and offered an alternative proposal, which again Gorry didn't like, saying that it seems to him to be a big change in what he's seen on the list. 

My question at this point is: can we keep the original text of goal #2 as I quote it here, or does anybody have yet another proposal that we all can live with?


ISSUE 2:
------------

There were some arguments about the need for WG goal #3, mechanisms to discover the availability of protocols...   - and it seems that several of us want to keep it. Can we (with the current text), or do we need to discuss this more?



Any other issues? Shoot, all  :-)

Cheers,
Michael


_______________________________________________
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

--------------090306070109020402030109-- From nobody Tue Jun 3 00:31:21 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1821A0110 for ; Tue, 3 Jun 2014 00:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 KY6YU3Fuwxpl for ; Tue, 3 Jun 2014 00:31:15 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 096F51A0043 for ; Tue, 3 Jun 2014 00:31:15 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id C6B602B40BB; Tue, 3 Jun 2014 08:31:08 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Tue, 3 Jun 2014 08:31:09 +0100 Message-ID: <1370a16d8e23356937eb03b56721a258.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <538CFE49.6020706@kau.se> References: <5387C0C1.3030909@gmail.com> <05c46a173690f08b6f910b090ac974ec.squirrel@www.erg.abdn.ac.uk> <5388B53D.1000406@erg.abdn.ac.uk> <5388FC56.6000705@gmail.com> <6E13430E-5714-47C1-A84C-53B6E819DB0C@trammell.ch> <538C99D3.7040605@gmail.com> <538CE61F.207@gmail.com> <8543296F-9F16-4188-A3F0-D273C9919BB8@ifi.uio.no> <5ACF2F3E-2967-4C03-B055-1F4111873ECD@ifi.uio.no> <538CFE49.6020706@kau.se> Date: Tue, 3 Jun 2014 08:31:09 +0100 From: gorry@erg.abdn.ac.uk To: "Anna Brunstrom" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/taps/I8DIge_tcwDwVkNpPJ7ItRFAwc4 Cc: taps@ietf.org Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 07:31:19 -0000 My original point was that I did not think this was the piece about what applications wanted to use - that I thought was going to be part of #2, my thoughts were that #3 related to the transport system working out what was actually supported, and the mechanisms (tricks, protocols and messages to be exchanged) to complete this process determining a usable transport. My view is probably a fairly modular way of looking at the problem - but it would allow at least something to be built, and experimentally deployed - who knows, if the method works it would achieve the goal. That's not to say there isn't a chance for a richer "apps" interaction, i'd juts like a focus on what paths *support*. Putting more over UDP probably heightens the need to also do the apps part - but UDP also has its own set of path issues. My argument is that the TAPS #3 item needs to focus on finding a transport that can be used over the path - if that can't be fixed, then TAPS can't succeed. Gorry > Hi, > > I do not like "applications want to use". The application requirements > give input for the services to specify, but to say that we should > specify what applications want to use sounds strange to me. > > I think the current formulation is better and more clear. I am also fine > with the "implementing TAPS" addition that Aaron suggested. But as Joe > did not like "implementing", how about: > > "specify a set of transport services that end systems supporting TAPS > need to provide and provide guidance on choosing among available > mechanisms and protocols to obtain a given transport service." > > Anna > > > On 2014-06-03 00:13, Michael Welzl wrote: >> other opinions? (myself, i'm neutral) >> >> Sent from my iPhone >> >> On 3. juni 2014, at 00:02, Aaron Falk > > wrote: >> >>> Michael- >>> >>> I'm actually OK with Joe's proposed wording: >>> >>> On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (jhildebr) >>> > wrote: >>> >>> On 5/30/14, 8:29 AM, "Aaron Falk" >> > wrote: >>> >>> >My proposed wording change (which at least Gorry accepted) is >>> not in the >>> >current draft. Repeating: >>> > >>> > >>> >Revise working group goal #2 to read "specify a set of transport >>> services >>> >that end systems **implementing TAPS** need to provide and provide >>> >guidance on choosing among available mechanisms and protocols to >>> obtain a >>> >given transport service." >>> >>> There's no protocol for TAPS yet, so nobody is going to >>> "implement TAPS". >>> Suggested change: "end systems need to provide" -> "applications >>> want to >>> use". >>> >>> >>> It allows the wg more flexibility which is probably appropriate in >>> this stage. >>> >>> --aaron >>> >>> >>> On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl >> > wrote: >>> >>> Hi! >>> >>> Spencer, thank you very much for this update. Much appreciated! >>> >>> Regarding the charter bit, let's try to figure out what >>> specifically is needed. Here's the link to the >>> always-most-up-to-date version: >>> https://sites.google.com/site/transportprotocolservices/charter-proposal >>> >>> You wrote: >>> >>>> I'd like to see an updated charter proposal that reflects recent >>>> mailing list discussion, including dropping the specifics about >>>> document category, so that the folks on the mailing list can >>>> check whether their concerns have been addressed. >>> >>> What exactly do you mean with "dropping the specifics about >>> document category" - is the suggestion to change WG goal #1, >>> which now reads: >>> "identify services provided by existing IETF transport protocols >>> and congestion control mechanisms, based on Standards-track and >>> Experimental RFCs." >>> to >>> ""identify services provided by existing IETF transport protocols >>> and congestion control mechanisms" ? >>> >>> >>> For other changes, I'll try to recap the current state; please, >>> all, if you feel I'm misrepresenting things, 1) it's definitely >>> not intentionally, 2) by all means correct me! >>> >>> >>> The way I see it, we have 2 issues to discuss. >>> >>> >>> ISSUE 1: >>> ------------ >>> >>> We had some consensus on the charter as it currently stands; >>> then, there was the comment by Aaron about a small wording change >>> that I had missed, in WG goal #2, which currently reads: >>> >>> "specify a set of transport services that end systems need to >>> provide and provide guidance on choosing among available >>> mechanisms and protocols to obtain a given transport service." >>> >>> Joe spoke against Aaron's change and offered an alternative >>> proposal, which again Gorry didn't like, saying that it seems to >>> him to be a big change in what he's seen on the list. >>> >>> My question at this point is: can we keep the original text of >>> goal #2 as I quote it here, or does anybody have yet another >>> proposal that we all can live with? >>> >>> >>> ISSUE 2: >>> ------------ >>> >>> There were some arguments about the need for WG goal #3, >>> mechanisms to discover the availability of protocols... - and >>> it seems that several of us want to keep it. Can we (with the >>> current text), or do we need to discuss this more? >>> >>> >>> >>> Any other issues? Shoot, all :-) >>> >>> Cheers, >>> Michael >>> >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>> >>> >> >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Tue Jun 3 01:18:27 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F601A017B for ; Tue, 3 Jun 2014 01:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 cfiFyTJopqNM for ; Tue, 3 Jun 2014 01:18:02 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA3CA1A0162 for ; Tue, 3 Jun 2014 01:18:01 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Wrjus-0002SC-0V; Tue, 03 Jun 2014 10:17:54 +0200 Received: from dhcp-064122.wlan.ntnu.no ([78.91.64.122]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Wrjuq-0003hG-QB; Tue, 03 Jun 2014 10:17:53 +0200 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_9D3EAB38-6D85-4035-8845-D8A5EFF36516" From: Michael Welzl X-Priority: 3 (Normal) In-Reply-To: <1370a16d8e23356937eb03b56721a258.squirrel@www.erg.abdn.ac.uk> Date: Tue, 3 Jun 2014 10:17:52 +0200 Message-Id: References: <5387C0C1.3030909@gmail.com> <05c46a173690f08b6f910b090ac974ec.squirrel@www.erg.abdn.ac.uk> <5388B53D.1000406@erg.abdn.ac.uk> <5388FC56.6000705@gmail.com> <6E13430E-5714-47C1-A84C-53B6E819DB0C@trammell.ch> <538C99D3.7040605@gmail.com> <538CE61F.207@gmail.com> <8543296F-9F16-4188-A3F0-D273C9919BB8@ifi.uio.no> <5ACF2F3E-2967-4C03-B055-1F4111873ECD@ifi.uio.no> <538CFE49.6020706@kau.se> <1370a16d8e23356937eb03b56721a258.squirrel@www.erg.abdn.ac.uk> To: "gorry@erg.abdn.ac.uk (erg)" X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 4 sum rcpts/h 11 sum msgs/h 5 total rcpts 17162 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: E443AFF42681843D33AB83E5C2C397E6B9003B47 X-UiO-SPAM-Test: remote_host: 78.91.64.122 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 3 max/h 3 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/h9yQ_tUQ8Xujc7VPFVRbtVV2R58 Cc: Anna Brunstrom , taps@ietf.org Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 08:18:15 -0000 --Apple-Mail=_9D3EAB38-6D85-4035-8845-D8A5EFF36516 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Anna talked about item #2, not item #3 (where no other wording was = proposed I think), so your response is confusing. Try again? Do you agree with Anna's proposed wording for item #2? I do. On 3. juni 2014, at 09:31, gorry@erg.abdn.ac.uk wrote: > My original point was that I did not think this was the piece about = what > applications wanted to use - that I thought was going to be part of = #2, my > thoughts were that #3 related to the transport system working out what = was > actually supported, and the mechanisms (tricks, protocols and messages = to > be exchanged) to complete this process determining a usable transport. = My > view is probably a fairly modular way of looking at the problem - but = it > would allow at least something to be built, and experimentally = deployed - > who knows, if the method works it would achieve the goal. >=20 > That's not to say there isn't a chance for a richer "apps" = interaction, > i'd juts like a focus on what paths *support*. Putting more over UDP > probably heightens the need to also do the apps part - but UDP also = has > its own set of path issues. My argument is that the TAPS #3 item needs = to > focus on finding a transport that can be used over the path - if that > can't be fixed, then TAPS can't succeed. >=20 > Gorry >=20 >> Hi, >>=20 >> I do not like "applications want to use". The application = requirements >> give input for the services to specify, but to say that we should >> specify what applications want to use sounds strange to me. >>=20 >> I think the current formulation is better and more clear. I am also = fine >> with the "implementing TAPS" addition that Aaron suggested. But as = Joe >> did not like "implementing", how about: >>=20 >> "specify a set of transport services that end systems supporting TAPS >> need to provide and provide guidance on choosing among available >> mechanisms and protocols to obtain a given transport service." >>=20 >> Anna >>=20 >>=20 >> On 2014-06-03 00:13, Michael Welzl wrote: >>> other opinions? (myself, i'm neutral) >>>=20 >>> Sent from my iPhone >>>=20 >>> On 3. juni 2014, at 00:02, Aaron Falk >> > wrote: >>>=20 >>>> Michael- >>>>=20 >>>> I'm actually OK with Joe's proposed wording: >>>>=20 >>>> On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (jhildebr) >>>> > wrote: >>>>=20 >>>> On 5/30/14, 8:29 AM, "Aaron Falk" >>> > wrote: >>>>=20 >>>>> My proposed wording change (which at least Gorry accepted) is >>>> not in the >>>>> current draft. Repeating: >>>>>=20 >>>>>=20 >>>>> Revise working group goal #2 to read "specify a set of transport >>>> services >>>>> that end systems **implementing TAPS** need to provide and provide >>>>> guidance on choosing among available mechanisms and protocols to >>>> obtain a >>>>> given transport service." >>>>=20 >>>> There's no protocol for TAPS yet, so nobody is going to >>>> "implement TAPS". >>>> Suggested change: "end systems need to provide" -> "applications >>>> want to >>>> use". >>>>=20 >>>>=20 >>>> It allows the wg more flexibility which is probably appropriate in >>>> this stage. >>>>=20 >>>> --aaron >>>>=20 >>>>=20 >>>> On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl >>> > wrote: >>>>=20 >>>> Hi! >>>>=20 >>>> Spencer, thank you very much for this update. Much appreciated! >>>>=20 >>>> Regarding the charter bit, let's try to figure out what >>>> specifically is needed. Here's the link to the >>>> always-most-up-to-date version: >>>> = https://sites.google.com/site/transportprotocolservices/charter-proposal >>>>=20 >>>> You wrote: >>>>=20 >>>>> I'd like to see an updated charter proposal that reflects = recent >>>>> mailing list discussion, including dropping the specifics about >>>>> document category, so that the folks on the mailing list can >>>>> check whether their concerns have been addressed. >>>>=20 >>>> What exactly do you mean with "dropping the specifics about >>>> document category" - is the suggestion to change WG goal #1, >>>> which now reads: >>>> "identify services provided by existing IETF transport protocols >>>> and congestion control mechanisms, based on Standards-track and >>>> Experimental RFCs." >>>> to >>>> ""identify services provided by existing IETF transport = protocols >>>> and congestion control mechanisms" ? >>>>=20 >>>>=20 >>>> For other changes, I'll try to recap the current state; please, >>>> all, if you feel I'm misrepresenting things, 1) it's definitely >>>> not intentionally, 2) by all means correct me! >>>>=20 >>>>=20 >>>> The way I see it, we have 2 issues to discuss. >>>>=20 >>>>=20 >>>> ISSUE 1: >>>> ------------ >>>>=20 >>>> We had some consensus on the charter as it currently stands; >>>> then, there was the comment by Aaron about a small wording = change >>>> that I had missed, in WG goal #2, which currently reads: >>>>=20 >>>> "specify a set of transport services that end systems need to >>>> provide and provide guidance on choosing among available >>>> mechanisms and protocols to obtain a given transport service." >>>>=20 >>>> Joe spoke against Aaron's change and offered an alternative >>>> proposal, which again Gorry didn't like, saying that it seems to >>>> him to be a big change in what he's seen on the list. >>>>=20 >>>> My question at this point is: can we keep the original text of >>>> goal #2 as I quote it here, or does anybody have yet another >>>> proposal that we all can live with? >>>>=20 >>>>=20 >>>> ISSUE 2: >>>> ------------ >>>>=20 >>>> There were some arguments about the need for WG goal #3, >>>> mechanisms to discover the availability of protocols... - and >>>> it seems that several of us want to keep it. Can we (with the >>>> current text), or do we need to discuss this more? >>>>=20 >>>>=20 >>>>=20 >>>> Any other issues? Shoot, all :-) >>>>=20 >>>> Cheers, >>>> Michael >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>>=20 >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >>=20 >=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_9D3EAB38-6D85-4035-8845-D8A5EFF36516 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Anna = talked about item #2, not item #3 (where no other wording was proposed I = think), so your response is confusing. Try again?

Do = you agree with Anna's proposed wording for item #2?  I = do.


On 3. juni 2014, at 09:31, gorry@erg.abdn.ac.uk = wrote:

My original point was that I did = not think this was the piece about what
applications wanted to use - = that I thought was going to be part of #2, my
thoughts were that #3 = related to the transport system working out what was
actually = supported, and the mechanisms (tricks, protocols and messages to
be = exchanged) to complete this process determining a usable transport. =  My
view is probably a fairly modular way of looking at the = problem - but it
would allow at least something to be built, and = experimentally deployed -
who knows, if the method works it would = achieve the goal.

That's not to say there isn't a chance for a = richer "apps" interaction,
i'd juts like a focus on what paths = *support*.  Putting more over UDP
probably heightens the need to = also do the apps part - but UDP also has
its own set of path issues. = My argument is that the TAPS #3 item needs to
focus on finding a = transport that can be used over the path - if that
can't be fixed, = then TAPS can't succeed.

Gorry

Hi,

I do not like "applications want to use". The = application requirements
give input for the services to specify, but = to say that we should
specify what applications want to use sounds = strange to me.

I think the current formulation is better and more = clear. I am also fine
with the "implementing TAPS" addition that = Aaron suggested. But as Joe
did not like "implementing", how = about:

"specify a set of transport services that end systems = supporting TAPS
need to provide and provide guidance on choosing = among available
mechanisms and protocols to obtain a given transport = service."

Anna


On 2014-06-03 00:13, Michael Welzl = wrote:
other opinions? (myself, i'm = neutral)

Sent from my iPhone

On 3. juni 2014, at 00:02, = Aaron Falk <falk-ietf@dgftech.com
<mailto:falk-ietf@dgftech.com>= > wrote:

Michael-

I'm = actually OK with Joe's proposed wording:

On Fri, May 30, 2014 at = 11:55 AM, Joe Hildebrand (jhildebr)
<jhildebr@cisco.com <mailto:jhildebr@cisco.com>> = wrote:

   On 5/30/14, 8:29 AM, "Aaron Falk" <falk-ietf@dgftech.com
 &= nbsp; <mailto:falk-ietf@dgftech.com>= > wrote:

My proposed wording change = (which at least Gorry accepted) is
   not = in the
current draft. =  Repeating:


Revise working group goal #2 to read = "specify a set of = transport
   services
that end systems **implementing TAPS** need to provide and = provide
guidance on choosing among available mechanisms and protocols = to
   obtain a
given transport = service."

   There's no protocol for = TAPS yet, so nobody is going to
   "implement = TAPS".
   Suggested change: "end systems need to = provide" -> "applications
   want = to
   use".


It allows the wg more = flexibility which is probably appropriate in
this = stage.

--aaron


On Mon, Jun 2, 2014 at 5:47 PM, Michael = Welzl <michawe@ifi.uio.no
<mailto:michawe@ifi.uio.no>> = wrote:

   Hi!

   Spencer, = thank you very much for this update. Much = appreciated!

   Regarding the charter bit, let's = try to figure out what
   specifically is needed. = Here's the link to the
   always-most-up-to-date = version:
   https://sites.google.com/site/transportprotocolservices/charter-pr= oposal

   You wrote:

   I'd like to see an updated charter = proposal that reflects recent
   mailing list = discussion, including dropping the specifics = about
   document category, so that the folks on the = mailing list can
   check whether their concerns have = been addressed.

   What exactly do = you mean with "dropping the specifics = about
   document category" - is the suggestion to = change WG goal #1,
   which now = reads:
   "identify services provided by existing IETF = transport protocols
   and congestion control = mechanisms, based on Standards-track = and
   Experimental = RFCs."
   to
   ""identify services = provided by existing IETF transport protocols
   and = congestion control mechanisms" ?


   For other = changes, I'll try to recap the current state; = please,
   all, if you feel I'm misrepresenting = things, 1) it's definitely
   not intentionally, 2) by = all means correct me!


   The way I see it, we = have 2 issues to discuss.


   ISSUE = 1:
   ------------

   We had = some consensus on the charter as it currently = stands;
   then, there was the comment by Aaron about = a small wording change
   that I had missed, in WG = goal #2, which currently reads:

   "specify a set = of transport services that end systems need = to
   provide and provide guidance on choosing among = available
   mechanisms and protocols to obtain a = given transport service."

   Joe spoke against = Aaron's change and offered an alternative
   proposal, = which again Gorry didn't like, saying that it seems = to
   him to be a big change in what he's seen on the = list.

   My question at this point is: can we keep = the original text of
   goal #2 as I quote it here, or = does anybody have yet another
   proposal that we all = can live with?


   ISSUE = 2:
   ------------

   There were = some arguments about the need for WG goal = #3,
   mechanisms to discover the availability of = protocols...   - and
   it seems that = several of us want to keep it. Can we (with = the
   current text), or do we need to discuss this = more?



   Any other issues? Shoot, all =  :-)

   Cheers,
   Michael

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




_________________= ______________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/ma= ilman/listinfo/taps

__________________________________= _____________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/ma= ilman/listinfo/taps



__________________________= _____________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/ma= ilman/listinfo/taps

= --Apple-Mail=_9D3EAB38-6D85-4035-8845-D8A5EFF36516-- From nobody Tue Jun 3 01:46:41 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC381A0172 for ; Tue, 3 Jun 2014 01:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 zq9IW0GPK2YC for ; Tue, 3 Jun 2014 01:46:36 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id E17CB1A016B for ; Tue, 3 Jun 2014 01:46:35 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id E64782B4522; Tue, 3 Jun 2014 09:46:29 +0100 (BST) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id E98842B40BB; Tue, 3 Jun 2014 09:46:27 +0100 (BST) Message-ID: <538D8B63.5020307@erg.abdn.ac.uk> Date: Tue, 03 Jun 2014 09:46:27 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Michael Welzl References: <5387C0C1.3030909@gmail.com> <05c46a173690f08b6f910b090ac974ec.squirrel@www.erg.abdn.ac.uk> <5388B53D.1000406@erg.abdn.ac.uk> <5388FC56.6000705@gmail.com> <6E13430E-5714-47C1-A84C-53B6E819DB0C@trammell.ch> <538C99D3.7040605@gmail.com> <538CE61F.207@gmail.com> <8543296F-9F16-4188-A3F0-D273C9919BB8@ifi.uio.no> <5ACF2F3E-2967-4C03-B055-1F4111873ECD@ifi.uio.no> <538CFE49.6020706@kau.se> <1370a16d8e23356937eb03b56721a258.squirrel@www.erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/b2I6hh8I7QKZjjyjBU9a184pEf8 Cc: Anna Brunstrom , taps@ietf.org Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 08:46:38 -0000 Sorry, "yes". Gorry On 03/06/2014 09:17, Michael Welzl wrote: > Anna talked about item #2, not item #3 (where no other wording was proposed I think), so your response is confusing. Try again? > > Do you agree with Anna's proposed wording for item #2? I do. > > > On 3. juni 2014, at 09:31, gorry@erg.abdn.ac.uk wrote: > >> My original point was that I did not think this was the piece about what >> applications wanted to use - that I thought was going to be part of #2, my >> thoughts were that #3 related to the transport system working out what was >> actually supported, and the mechanisms (tricks, protocols and messages to >> be exchanged) to complete this process determining a usable transport. My >> view is probably a fairly modular way of looking at the problem - but it >> would allow at least something to be built, and experimentally deployed - >> who knows, if the method works it would achieve the goal. >> >> That's not to say there isn't a chance for a richer "apps" interaction, >> i'd juts like a focus on what paths *support*. Putting more over UDP >> probably heightens the need to also do the apps part - but UDP also has >> its own set of path issues. My argument is that the TAPS #3 item needs to >> focus on finding a transport that can be used over the path - if that >> can't be fixed, then TAPS can't succeed. >> >> Gorry >> >>> Hi, >>> >>> I do not like "applications want to use". The application requirements >>> give input for the services to specify, but to say that we should >>> specify what applications want to use sounds strange to me. >>> >>> I think the current formulation is better and more clear. I am also fine >>> with the "implementing TAPS" addition that Aaron suggested. But as Joe >>> did not like "implementing", how about: >>> >>> "specify a set of transport services that end systems supporting TAPS >>> need to provide and provide guidance on choosing among available >>> mechanisms and protocols to obtain a given transport service." >>> >>> Anna >>> >>> >>> On 2014-06-03 00:13, Michael Welzl wrote: >>>> other opinions? (myself, i'm neutral) >>>> >>>> Sent from my iPhone >>>> >>>> On 3. juni 2014, at 00:02, Aaron Falk >>> > wrote: >>>> >>>>> Michael- >>>>> >>>>> I'm actually OK with Joe's proposed wording: >>>>> >>>>> On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (jhildebr) >>>>> > wrote: >>>>> >>>>> On 5/30/14, 8:29 AM, "Aaron Falk" >>>> > wrote: >>>>> >>>>>> My proposed wording change (which at least Gorry accepted) is >>>>> not in the >>>>>> current draft. Repeating: >>>>>> >>>>>> >>>>>> Revise working group goal #2 to read "specify a set of transport >>>>> services >>>>>> that end systems **implementing TAPS** need to provide and provide >>>>>> guidance on choosing among available mechanisms and protocols to >>>>> obtain a >>>>>> given transport service." >>>>> >>>>> There's no protocol for TAPS yet, so nobody is going to >>>>> "implement TAPS". >>>>> Suggested change: "end systems need to provide" -> "applications >>>>> want to >>>>> use". >>>>> >>>>> >>>>> It allows the wg more flexibility which is probably appropriate in >>>>> this stage. >>>>> >>>>> --aaron >>>>> >>>>> >>>>> On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl >>>> > wrote: >>>>> >>>>> Hi! >>>>> >>>>> Spencer, thank you very much for this update. Much appreciated! >>>>> >>>>> Regarding the charter bit, let's try to figure out what >>>>> specifically is needed. Here's the link to the >>>>> always-most-up-to-date version: >>>>> https://sites.google.com/site/transportprotocolservices/charter-proposal >>>>> >>>>> You wrote: >>>>> >>>>>> I'd like to see an updated charter proposal that reflects recent >>>>>> mailing list discussion, including dropping the specifics about >>>>>> document category, so that the folks on the mailing list can >>>>>> check whether their concerns have been addressed. >>>>> >>>>> What exactly do you mean with "dropping the specifics about >>>>> document category" - is the suggestion to change WG goal #1, >>>>> which now reads: >>>>> "identify services provided by existing IETF transport protocols >>>>> and congestion control mechanisms, based on Standards-track and >>>>> Experimental RFCs." >>>>> to >>>>> ""identify services provided by existing IETF transport protocols >>>>> and congestion control mechanisms" ? >>>>> >>>>> >>>>> For other changes, I'll try to recap the current state; please, >>>>> all, if you feel I'm misrepresenting things, 1) it's definitely >>>>> not intentionally, 2) by all means correct me! >>>>> >>>>> >>>>> The way I see it, we have 2 issues to discuss. >>>>> >>>>> >>>>> ISSUE 1: >>>>> ------------ >>>>> >>>>> We had some consensus on the charter as it currently stands; >>>>> then, there was the comment by Aaron about a small wording change >>>>> that I had missed, in WG goal #2, which currently reads: >>>>> >>>>> "specify a set of transport services that end systems need to >>>>> provide and provide guidance on choosing among available >>>>> mechanisms and protocols to obtain a given transport service." >>>>> >>>>> Joe spoke against Aaron's change and offered an alternative >>>>> proposal, which again Gorry didn't like, saying that it seems to >>>>> him to be a big change in what he's seen on the list. >>>>> >>>>> My question at this point is: can we keep the original text of >>>>> goal #2 as I quote it here, or does anybody have yet another >>>>> proposal that we all can live with? >>>>> >>>>> >>>>> ISSUE 2: >>>>> ------------ >>>>> >>>>> There were some arguments about the need for WG goal #3, >>>>> mechanisms to discover the availability of protocols... - and >>>>> it seems that several of us want to keep it. Can we (with the >>>>> current text), or do we need to discuss this more? >>>>> >>>>> >>>>> >>>>> Any other issues? Shoot, all :-) >>>>> >>>>> Cheers, >>>>> Michael >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > From nobody Tue Jun 3 01:54:14 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF231A017C for ; Tue, 3 Jun 2014 01:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 OAS5-ksNO1FY for ; Tue, 3 Jun 2014 01:54:10 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 279621A0172 for ; Tue, 3 Jun 2014 01:54:10 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WrkTr-0003Re-0r for taps@ietf.org; Tue, 03 Jun 2014 10:54:03 +0200 Received: from dhcp-064122.wlan.ntnu.no ([78.91.64.122]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WrkTq-00051S-8l for taps@ietf.org; Tue, 03 Jun 2014 10:54:02 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <538D8B63.5020307@erg.abdn.ac.uk> Date: Tue, 3 Jun 2014 10:54:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5387C0C1.3030909@gmail.com> <05c46a173690f08b6f910b090ac974ec.squirrel@www.erg.abdn.ac.uk> <5388B53D.1000406@erg.abdn.ac.uk> <5388FC56.6000705@gmail.com> <6E13430E-5714-47C1-A84C-53B6E819DB0C@trammell.ch> <538C99D3.7040605@gmail.com> <538CE61F.207@gmail.com> <8543296F-9F16-4188-A3F0-D273C9919BB8@ifi.uio.no> <5ACF2F3E-2967-4C03-B055-1F4111873ECD@ifi.uio.no> <538CFE49.6020706@kau.se> <1370a16d8e23356937eb03b56721a258.squirrel@www.erg.abdn.ac.uk> <538D8B63.5020307@erg.abdn.ac.uk> To: taps@ietf.org X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 19 msgs/h 12 sum rcpts/h 22 sum msgs/h 13 total rcpts 17173 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 7FB30F5745EA39B1AEF3ACE0083BF6F71139171C X-UiO-SPAM-Test: remote_host: 78.91.64.122 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 11 total 11 max/h 11 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/T_qqruaHgIcO84A_PpPzz0Ut-Jk Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 08:54:12 -0000 Aaron? Joe? On 3. juni 2014, at 10:46, Gorry Fairhurst wrote: > Sorry, "yes". >=20 > Gorry >=20 >=20 > On 03/06/2014 09:17, Michael Welzl wrote: >> Anna talked about item #2, not item #3 (where no other wording was = proposed I think), so your response is confusing. Try again? >>=20 >> Do you agree with Anna's proposed wording for item #2? I do. >>=20 >>=20 >> On 3. juni 2014, at 09:31, gorry@erg.abdn.ac.uk wrote: >>=20 >>> My original point was that I did not think this was the piece about = what >>> applications wanted to use - that I thought was going to be part of = #2, my >>> thoughts were that #3 related to the transport system working out = what was >>> actually supported, and the mechanisms (tricks, protocols and = messages to >>> be exchanged) to complete this process determining a usable = transport. My >>> view is probably a fairly modular way of looking at the problem - = but it >>> would allow at least something to be built, and experimentally = deployed - >>> who knows, if the method works it would achieve the goal. >>>=20 >>> That's not to say there isn't a chance for a richer "apps" = interaction, >>> i'd juts like a focus on what paths *support*. Putting more over = UDP >>> probably heightens the need to also do the apps part - but UDP also = has >>> its own set of path issues. My argument is that the TAPS #3 item = needs to >>> focus on finding a transport that can be used over the path - if = that >>> can't be fixed, then TAPS can't succeed. >>>=20 >>> Gorry >>>=20 >>>> Hi, >>>>=20 >>>> I do not like "applications want to use". The application = requirements >>>> give input for the services to specify, but to say that we should >>>> specify what applications want to use sounds strange to me. >>>>=20 >>>> I think the current formulation is better and more clear. I am also = fine >>>> with the "implementing TAPS" addition that Aaron suggested. But as = Joe >>>> did not like "implementing", how about: >>>>=20 >>>> "specify a set of transport services that end systems supporting = TAPS >>>> need to provide and provide guidance on choosing among available >>>> mechanisms and protocols to obtain a given transport service." >>>>=20 >>>> Anna >>>>=20 >>>>=20 >>>> On 2014-06-03 00:13, Michael Welzl wrote: >>>>> other opinions? (myself, i'm neutral) >>>>>=20 >>>>> Sent from my iPhone >>>>>=20 >>>>> On 3. juni 2014, at 00:02, Aaron Falk >>>> > wrote: >>>>>=20 >>>>>> Michael- >>>>>>=20 >>>>>> I'm actually OK with Joe's proposed wording: >>>>>>=20 >>>>>> On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (jhildebr) >>>>>> > wrote: >>>>>>=20 >>>>>> On 5/30/14, 8:29 AM, "Aaron Falk" >>>>> > wrote: >>>>>>=20 >>>>>>> My proposed wording change (which at least Gorry accepted) is >>>>>> not in the >>>>>>> current draft. Repeating: >>>>>>>=20 >>>>>>>=20 >>>>>>> Revise working group goal #2 to read "specify a set of transport >>>>>> services >>>>>>> that end systems **implementing TAPS** need to provide and = provide >>>>>>> guidance on choosing among available mechanisms and protocols to >>>>>> obtain a >>>>>>> given transport service." >>>>>>=20 >>>>>> There's no protocol for TAPS yet, so nobody is going to >>>>>> "implement TAPS". >>>>>> Suggested change: "end systems need to provide" -> = "applications >>>>>> want to >>>>>> use". >>>>>>=20 >>>>>>=20 >>>>>> It allows the wg more flexibility which is probably appropriate = in >>>>>> this stage. >>>>>>=20 >>>>>> --aaron >>>>>>=20 >>>>>>=20 >>>>>> On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl >>>>> > wrote: >>>>>>=20 >>>>>> Hi! >>>>>>=20 >>>>>> Spencer, thank you very much for this update. Much = appreciated! >>>>>>=20 >>>>>> Regarding the charter bit, let's try to figure out what >>>>>> specifically is needed. Here's the link to the >>>>>> always-most-up-to-date version: >>>>>> = https://sites.google.com/site/transportprotocolservices/charter-proposal >>>>>>=20 >>>>>> You wrote: >>>>>>=20 >>>>>>> I'd like to see an updated charter proposal that reflects = recent >>>>>>> mailing list discussion, including dropping the specifics = about >>>>>>> document category, so that the folks on the mailing list can >>>>>>> check whether their concerns have been addressed. >>>>>>=20 >>>>>> What exactly do you mean with "dropping the specifics about >>>>>> document category" - is the suggestion to change WG goal #1, >>>>>> which now reads: >>>>>> "identify services provided by existing IETF transport = protocols >>>>>> and congestion control mechanisms, based on Standards-track = and >>>>>> Experimental RFCs." >>>>>> to >>>>>> ""identify services provided by existing IETF transport = protocols >>>>>> and congestion control mechanisms" ? >>>>>>=20 >>>>>>=20 >>>>>> For other changes, I'll try to recap the current state; = please, >>>>>> all, if you feel I'm misrepresenting things, 1) it's = definitely >>>>>> not intentionally, 2) by all means correct me! >>>>>>=20 >>>>>>=20 >>>>>> The way I see it, we have 2 issues to discuss. >>>>>>=20 >>>>>>=20 >>>>>> ISSUE 1: >>>>>> ------------ >>>>>>=20 >>>>>> We had some consensus on the charter as it currently stands; >>>>>> then, there was the comment by Aaron about a small wording = change >>>>>> that I had missed, in WG goal #2, which currently reads: >>>>>>=20 >>>>>> "specify a set of transport services that end systems need to >>>>>> provide and provide guidance on choosing among available >>>>>> mechanisms and protocols to obtain a given transport service." >>>>>>=20 >>>>>> Joe spoke against Aaron's change and offered an alternative >>>>>> proposal, which again Gorry didn't like, saying that it seems = to >>>>>> him to be a big change in what he's seen on the list. >>>>>>=20 >>>>>> My question at this point is: can we keep the original text of >>>>>> goal #2 as I quote it here, or does anybody have yet another >>>>>> proposal that we all can live with? >>>>>>=20 >>>>>>=20 >>>>>> ISSUE 2: >>>>>> ------------ >>>>>>=20 >>>>>> There were some arguments about the need for WG goal #3, >>>>>> mechanisms to discover the availability of protocols... - = and >>>>>> it seems that several of us want to keep it. Can we (with the >>>>>> current text), or do we need to discuss this more? >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Any other issues? Shoot, all :-) >>>>>>=20 >>>>>> Cheers, >>>>>> Michael >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Taps mailing list >>>>>> Taps@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Taps mailing list >>>>> Taps@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/taps >>>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >>=20 >=20 From nobody Tue Jun 3 02:03:37 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 240751A017C for ; Tue, 3 Jun 2014 02:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 tAv0hkojBLHC for ; Tue, 3 Jun 2014 02:03:32 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f51]) (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 306581A00FC for ; Tue, 3 Jun 2014 02:03:32 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from s235i161.wolfson.cam.ac.uk ([128.232.235.161]:44171 helo=[10.0.1.2]) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1Wrkcv-00065U-Xc (Exim 4.82_3-c0e5623) (return-path ); Tue, 03 Jun 2014 10:03:25 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Toby Moncaster In-Reply-To: Date: Tue, 3 Jun 2014 10:03:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5387C0C1.3030909@gmail.com> <05c46a173690f08b6f910b090ac974ec.squirrel@www.erg.abdn.ac.uk> <5388B53D.1000406@erg.abdn.ac.uk> <5388FC56.6000705@gmail.com> <6E13430E-5714-47C1-A84C-53B6E819DB0C@trammell.ch> <538C99D3.7040605@gmail.com> <538CE61F.207@gmail.com> <8543296F-9F16-4188-A3F0-D273C9919BB8@ifi.uio.no> <5ACF2F3E-2967-4C03-B055-1F4111873ECD@ifi.uio.no> <538CFE49.6020706@kau.se> <1370a16d8e23356937eb03b56721a258.squirrel@www.erg.abdn.ac.uk> <538D8B63.5020307@erg.abdn.ac.uk> To: Michael Welzl X-Mailer: Apple Mail (2.1878.2) Sender: "T. Moncaster" Archived-At: http://mailarchive.ietf.org/arch/msg/taps/lcyv5RGUnLV5DBR881CCztpCMSw Cc: taps@ietf.org Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 09:03:35 -0000 I think Anna=92s proposed wording is good. Toby On 3 Jun 2014, at 09:54, Michael Welzl wrote: > Aaron? Joe? >=20 >=20 > On 3. juni 2014, at 10:46, Gorry Fairhurst = wrote: >=20 >> Sorry, "yes". >>=20 >> Gorry >>=20 >>=20 >> On 03/06/2014 09:17, Michael Welzl wrote: >>> Anna talked about item #2, not item #3 (where no other wording was = proposed I think), so your response is confusing. Try again? >>>=20 >>> Do you agree with Anna's proposed wording for item #2? I do. >>>=20 >>>=20 >>> On 3. juni 2014, at 09:31, gorry@erg.abdn.ac.uk wrote: >>>=20 >>>> My original point was that I did not think this was the piece about = what >>>> applications wanted to use - that I thought was going to be part of = #2, my >>>> thoughts were that #3 related to the transport system working out = what was >>>> actually supported, and the mechanisms (tricks, protocols and = messages to >>>> be exchanged) to complete this process determining a usable = transport. My >>>> view is probably a fairly modular way of looking at the problem - = but it >>>> would allow at least something to be built, and experimentally = deployed - >>>> who knows, if the method works it would achieve the goal. >>>>=20 >>>> That's not to say there isn't a chance for a richer "apps" = interaction, >>>> i'd juts like a focus on what paths *support*. Putting more over = UDP >>>> probably heightens the need to also do the apps part - but UDP also = has >>>> its own set of path issues. My argument is that the TAPS #3 item = needs to >>>> focus on finding a transport that can be used over the path - if = that >>>> can't be fixed, then TAPS can't succeed. >>>>=20 >>>> Gorry >>>>=20 >>>>> Hi, >>>>>=20 >>>>> I do not like "applications want to use". The application = requirements >>>>> give input for the services to specify, but to say that we should >>>>> specify what applications want to use sounds strange to me. >>>>>=20 >>>>> I think the current formulation is better and more clear. I am = also fine >>>>> with the "implementing TAPS" addition that Aaron suggested. But as = Joe >>>>> did not like "implementing", how about: >>>>>=20 >>>>> "specify a set of transport services that end systems supporting = TAPS >>>>> need to provide and provide guidance on choosing among available >>>>> mechanisms and protocols to obtain a given transport service." >>>>>=20 >>>>> Anna >>>>>=20 >>>>>=20 >>>>> On 2014-06-03 00:13, Michael Welzl wrote: >>>>>> other opinions? (myself, i'm neutral) >>>>>>=20 >>>>>> Sent from my iPhone >>>>>>=20 >>>>>> On 3. juni 2014, at 00:02, Aaron Falk >>>>> > wrote: >>>>>>=20 >>>>>>> Michael- >>>>>>>=20 >>>>>>> I'm actually OK with Joe's proposed wording: >>>>>>>=20 >>>>>>> On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (jhildebr) >>>>>>> > wrote: >>>>>>>=20 >>>>>>> On 5/30/14, 8:29 AM, "Aaron Falk" >>>>>> > wrote: >>>>>>>=20 >>>>>>>> My proposed wording change (which at least Gorry accepted) is >>>>>>> not in the >>>>>>>> current draft. Repeating: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Revise working group goal #2 to read "specify a set of = transport >>>>>>> services >>>>>>>> that end systems **implementing TAPS** need to provide and = provide >>>>>>>> guidance on choosing among available mechanisms and protocols = to >>>>>>> obtain a >>>>>>>> given transport service." >>>>>>>=20 >>>>>>> There's no protocol for TAPS yet, so nobody is going to >>>>>>> "implement TAPS". >>>>>>> Suggested change: "end systems need to provide" -> = "applications >>>>>>> want to >>>>>>> use". >>>>>>>=20 >>>>>>>=20 >>>>>>> It allows the wg more flexibility which is probably appropriate = in >>>>>>> this stage. >>>>>>>=20 >>>>>>> --aaron >>>>>>>=20 >>>>>>>=20 >>>>>>> On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl = >>>>>> > wrote: >>>>>>>=20 >>>>>>> Hi! >>>>>>>=20 >>>>>>> Spencer, thank you very much for this update. Much = appreciated! >>>>>>>=20 >>>>>>> Regarding the charter bit, let's try to figure out what >>>>>>> specifically is needed. Here's the link to the >>>>>>> always-most-up-to-date version: >>>>>>> = https://sites.google.com/site/transportprotocolservices/charter-proposal >>>>>>>=20 >>>>>>> You wrote: >>>>>>>=20 >>>>>>>> I'd like to see an updated charter proposal that reflects = recent >>>>>>>> mailing list discussion, including dropping the specifics = about >>>>>>>> document category, so that the folks on the mailing list can >>>>>>>> check whether their concerns have been addressed. >>>>>>>=20 >>>>>>> What exactly do you mean with "dropping the specifics about >>>>>>> document category" - is the suggestion to change WG goal #1, >>>>>>> which now reads: >>>>>>> "identify services provided by existing IETF transport = protocols >>>>>>> and congestion control mechanisms, based on Standards-track = and >>>>>>> Experimental RFCs." >>>>>>> to >>>>>>> ""identify services provided by existing IETF transport = protocols >>>>>>> and congestion control mechanisms" ? >>>>>>>=20 >>>>>>>=20 >>>>>>> For other changes, I'll try to recap the current state; = please, >>>>>>> all, if you feel I'm misrepresenting things, 1) it's = definitely >>>>>>> not intentionally, 2) by all means correct me! >>>>>>>=20 >>>>>>>=20 >>>>>>> The way I see it, we have 2 issues to discuss. >>>>>>>=20 >>>>>>>=20 >>>>>>> ISSUE 1: >>>>>>> ------------ >>>>>>>=20 >>>>>>> We had some consensus on the charter as it currently stands; >>>>>>> then, there was the comment by Aaron about a small wording = change >>>>>>> that I had missed, in WG goal #2, which currently reads: >>>>>>>=20 >>>>>>> "specify a set of transport services that end systems need to >>>>>>> provide and provide guidance on choosing among available >>>>>>> mechanisms and protocols to obtain a given transport service." >>>>>>>=20 >>>>>>> Joe spoke against Aaron's change and offered an alternative >>>>>>> proposal, which again Gorry didn't like, saying that it seems = to >>>>>>> him to be a big change in what he's seen on the list. >>>>>>>=20 >>>>>>> My question at this point is: can we keep the original text of >>>>>>> goal #2 as I quote it here, or does anybody have yet another >>>>>>> proposal that we all can live with? >>>>>>>=20 >>>>>>>=20 >>>>>>> ISSUE 2: >>>>>>> ------------ >>>>>>>=20 >>>>>>> There were some arguments about the need for WG goal #3, >>>>>>> mechanisms to discover the availability of protocols... - = and >>>>>>> it seems that several of us want to keep it. Can we (with the >>>>>>> current text), or do we need to discuss this more? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Any other issues? Shoot, all :-) >>>>>>>=20 >>>>>>> Cheers, >>>>>>> Michael >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Taps mailing list >>>>>>> Taps@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Taps mailing list >>>>>> Taps@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>=20 >>>>> _______________________________________________ >>>>> Taps mailing list >>>>> Taps@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>>=20 >>=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Jun 3 11:44:22 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A6D1A025B for ; Tue, 3 Jun 2014 11:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 Csrqziiv-8hX for ; Tue, 3 Jun 2014 11:43:50 -0700 (PDT) Received: from mail-ve0-f199.google.com (mail-ve0-f199.google.com [209.85.128.199]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABFB81A025A for ; Tue, 3 Jun 2014 11:43:42 -0700 (PDT) Received: by mail-ve0-f199.google.com with SMTP id oz11so31632990veb.10 for ; Tue, 03 Jun 2014 11:43:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fKlj6v+OcavBAJv+coZ9jVHY+WwyL6xAgiy6yRoUeyg=; b=frS7NDVxophsTL5oJiUgyndIofokN8WLAGvKuyOsMCUeTaxRULrt6shFCmkG9rxMRK KlgMzhyxNX7uEqBWWbVAC0X6sHzDgaCYb+CqzjOG2wKJwSXKXw8FOlwF+5/1Q3sD9MQz 0HfbggzX6GpMTdUJHdT/eTPejXJVjqQXwM6MtVsEn28gW4aaEDS9iMxMPtkqWY5SZ/je wiE1dfefmHGz8TbP/u9wC9VcrFhP7QEP1hMvJ8YZw9dyrZ8xTgjDb5L29y0X15YBFoE/ cCXXoONBBqxqdPUsRyZhbCni37nNa6mD81ZTeRDXglys9u8OVhRTvi+vyGbdbdb2o4jv 6cWg== X-Gm-Message-State: ALoCoQm4VESAEh9w89WP8zH1G3S1vNy/aa3Yt8sZacy+nbLjfS/Wykh+VnxXInDhfCzvDEOWd49u X-Received: by 10.53.8.162 with SMTP id dl2mr22329073vdd.24.1401821016093; Tue, 03 Jun 2014 11:43:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.85.72 with HTTP; Tue, 3 Jun 2014 11:43:16 -0700 (PDT) In-Reply-To: References: <5387C0C1.3030909@gmail.com> <05c46a173690f08b6f910b090ac974ec.squirrel@www.erg.abdn.ac.uk> <5388B53D.1000406@erg.abdn.ac.uk> <5388FC56.6000705@gmail.com> <6E13430E-5714-47C1-A84C-53B6E819DB0C@trammell.ch> <538C99D3.7040605@gmail.com> <538CE61F.207@gmail.com> <8543296F-9F16-4188-A3F0-D273C9919BB8@ifi.uio.no> <5ACF2F3E-2967-4C03-B055-1F4111873ECD@ifi.uio.no> <538CFE49.6020706@kau.se> <1370a16d8e23356937eb03b56721a258.squirrel@www.erg.abdn.ac.uk> <538D8B63.5020307@erg.abdn.ac.uk> From: Aaron Falk Date: Tue, 3 Jun 2014 14:43:16 -0400 Message-ID: To: Michael Welzl Content-Type: multipart/alternative; boundary=001a1135e18cb404cc04faf2e3f7 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/jN_qdcx0wFfgalCcWp0v3qFr6gQ Cc: "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 18:44:11 -0000 --001a1135e18cb404cc04faf2e3f7 Content-Type: text/plain; charset=UTF-8 fine with me --aaron On Tue, Jun 3, 2014 at 4:54 AM, Michael Welzl wrote: > Aaron? Joe? > > > On 3. juni 2014, at 10:46, Gorry Fairhurst wrote: > > > Sorry, "yes". > > > > Gorry > > > > > > On 03/06/2014 09:17, Michael Welzl wrote: > >> Anna talked about item #2, not item #3 (where no other wording was > proposed I think), so your response is confusing. Try again? > >> > >> Do you agree with Anna's proposed wording for item #2? I do. > >> > >> > >> On 3. juni 2014, at 09:31, gorry@erg.abdn.ac.uk wrote: > >> > >>> My original point was that I did not think this was the piece about > what > >>> applications wanted to use - that I thought was going to be part of > #2, my > >>> thoughts were that #3 related to the transport system working out what > was > >>> actually supported, and the mechanisms (tricks, protocols and messages > to > >>> be exchanged) to complete this process determining a usable transport. > My > >>> view is probably a fairly modular way of looking at the problem - but > it > >>> would allow at least something to be built, and experimentally > deployed - > >>> who knows, if the method works it would achieve the goal. > >>> > >>> That's not to say there isn't a chance for a richer "apps" interaction, > >>> i'd juts like a focus on what paths *support*. Putting more over UDP > >>> probably heightens the need to also do the apps part - but UDP also has > >>> its own set of path issues. My argument is that the TAPS #3 item needs > to > >>> focus on finding a transport that can be used over the path - if that > >>> can't be fixed, then TAPS can't succeed. > >>> > >>> Gorry > >>> > >>>> Hi, > >>>> > >>>> I do not like "applications want to use". The application requirements > >>>> give input for the services to specify, but to say that we should > >>>> specify what applications want to use sounds strange to me. > >>>> > >>>> I think the current formulation is better and more clear. I am also > fine > >>>> with the "implementing TAPS" addition that Aaron suggested. But as Joe > >>>> did not like "implementing", how about: > >>>> > >>>> "specify a set of transport services that end systems supporting TAPS > >>>> need to provide and provide guidance on choosing among available > >>>> mechanisms and protocols to obtain a given transport service." > >>>> > >>>> Anna > >>>> > >>>> > >>>> On 2014-06-03 00:13, Michael Welzl wrote: > >>>>> other opinions? (myself, i'm neutral) > >>>>> > >>>>> Sent from my iPhone > >>>>> > >>>>> On 3. juni 2014, at 00:02, Aaron Falk >>>>> > wrote: > >>>>> > >>>>>> Michael- > >>>>>> > >>>>>> I'm actually OK with Joe's proposed wording: > >>>>>> > >>>>>> On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (jhildebr) > >>>>>> > wrote: > >>>>>> > >>>>>> On 5/30/14, 8:29 AM, "Aaron Falk" >>>>>> > wrote: > >>>>>> > >>>>>>> My proposed wording change (which at least Gorry accepted) is > >>>>>> not in the > >>>>>>> current draft. Repeating: > >>>>>>> > >>>>>>> > >>>>>>> Revise working group goal #2 to read "specify a set of transport > >>>>>> services > >>>>>>> that end systems **implementing TAPS** need to provide and provide > >>>>>>> guidance on choosing among available mechanisms and protocols to > >>>>>> obtain a > >>>>>>> given transport service." > >>>>>> > >>>>>> There's no protocol for TAPS yet, so nobody is going to > >>>>>> "implement TAPS". > >>>>>> Suggested change: "end systems need to provide" -> "applications > >>>>>> want to > >>>>>> use". > >>>>>> > >>>>>> > >>>>>> It allows the wg more flexibility which is probably appropriate in > >>>>>> this stage. > >>>>>> > >>>>>> --aaron > >>>>>> > >>>>>> > >>>>>> On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl >>>>>> > wrote: > >>>>>> > >>>>>> Hi! > >>>>>> > >>>>>> Spencer, thank you very much for this update. Much appreciated! > >>>>>> > >>>>>> Regarding the charter bit, let's try to figure out what > >>>>>> specifically is needed. Here's the link to the > >>>>>> always-most-up-to-date version: > >>>>>> > https://sites.google.com/site/transportprotocolservices/charter-proposal > >>>>>> > >>>>>> You wrote: > >>>>>> > >>>>>>> I'd like to see an updated charter proposal that reflects recent > >>>>>>> mailing list discussion, including dropping the specifics about > >>>>>>> document category, so that the folks on the mailing list can > >>>>>>> check whether their concerns have been addressed. > >>>>>> > >>>>>> What exactly do you mean with "dropping the specifics about > >>>>>> document category" - is the suggestion to change WG goal #1, > >>>>>> which now reads: > >>>>>> "identify services provided by existing IETF transport protocols > >>>>>> and congestion control mechanisms, based on Standards-track and > >>>>>> Experimental RFCs." > >>>>>> to > >>>>>> ""identify services provided by existing IETF transport protocols > >>>>>> and congestion control mechanisms" ? > >>>>>> > >>>>>> > >>>>>> For other changes, I'll try to recap the current state; please, > >>>>>> all, if you feel I'm misrepresenting things, 1) it's definitely > >>>>>> not intentionally, 2) by all means correct me! > >>>>>> > >>>>>> > >>>>>> The way I see it, we have 2 issues to discuss. > >>>>>> > >>>>>> > >>>>>> ISSUE 1: > >>>>>> ------------ > >>>>>> > >>>>>> We had some consensus on the charter as it currently stands; > >>>>>> then, there was the comment by Aaron about a small wording change > >>>>>> that I had missed, in WG goal #2, which currently reads: > >>>>>> > >>>>>> "specify a set of transport services that end systems need to > >>>>>> provide and provide guidance on choosing among available > >>>>>> mechanisms and protocols to obtain a given transport service." > >>>>>> > >>>>>> Joe spoke against Aaron's change and offered an alternative > >>>>>> proposal, which again Gorry didn't like, saying that it seems to > >>>>>> him to be a big change in what he's seen on the list. > >>>>>> > >>>>>> My question at this point is: can we keep the original text of > >>>>>> goal #2 as I quote it here, or does anybody have yet another > >>>>>> proposal that we all can live with? > >>>>>> > >>>>>> > >>>>>> ISSUE 2: > >>>>>> ------------ > >>>>>> > >>>>>> There were some arguments about the need for WG goal #3, > >>>>>> mechanisms to discover the availability of protocols... - and > >>>>>> it seems that several of us want to keep it. Can we (with the > >>>>>> current text), or do we need to discuss this more? > >>>>>> > >>>>>> > >>>>>> > >>>>>> Any other issues? Shoot, all :-) > >>>>>> > >>>>>> Cheers, > >>>>>> Michael > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > --001a1135e18cb404cc04faf2e3f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
fine with me

--aaron


On Tue, Jun 3, 2014 = at 4:54 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
Aaron? =C2=A0Joe?


On 3. juni 2014, at 10:46, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:

> Sorry, "yes".
>
> Gorry
>
>
> On 03/06/2014 09:17, Michael Welzl wrote:
>> Anna talked about item #2, not item #3 (where no other wording was= proposed I think), so your response is confusing. Try again?
>>
>> Do you agree with Anna's proposed wording for item #2? =C2=A0I= do.
>>
>>
>> On 3. juni 2014, at 09:31, gorry@erg.abdn.ac.uk wrote:
>>
>>> My original point was that I did not think this was the piece = about what
>>> applications wanted to use - that I thought was going to be pa= rt of #2, my
>>> thoughts were that #3 related to the transport system working = out what was
>>> actually supported, and the mechanisms (tricks, protocols and = messages to
>>> be exchanged) to complete this process determining a usable tr= ansport. =C2=A0My
>>> view is probably a fairly modular way of looking at the proble= m - but it
>>> would allow at least something to be built, and experimentally= deployed -
>>> who knows, if the method works it would achieve the goal.
>>>
>>> That's not to say there isn't a chance for a richer &q= uot;apps" interaction,
>>> i'd juts like a focus on what paths *support*. =C2=A0Putti= ng more over UDP
>>> probably heightens the need to also do the apps part - but UDP= also has
>>> its own set of path issues. My argument is that the TAPS #3 it= em needs to
>>> focus on finding a transport that can be used over the path - = if that
>>> can't be fixed, then TAPS can't succeed.
>>>
>>> Gorry
>>>
>>>> Hi,
>>>>
>>>> I do not like "applications want to use". The ap= plication requirements
>>>> give input for the services to specify, but to say that we= should
>>>> specify what applications want to use sounds strange to me= .
>>>>
>>>> I think the current formulation is better and more clear. = I am also fine
>>>> with the "implementing TAPS" addition that Aaron= suggested. But as Joe
>>>> did not like "implementing", how about:
>>>>
>>>> "specify a set of transport services that end systems= supporting TAPS
>>>> need to provide and provide guidance on choosing among ava= ilable
>>>> mechanisms and protocols to obtain a given transport servi= ce."
>>>>
>>>> Anna
>>>>
>>>>
>>>> On 2014-06-03 00:13, Michael Welzl wrote:
>>>>> other opinions? (myself, i'm neutral)
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On 3. juni 2014, at 00:02, Aaron Falk <falk-ietf@dgftech.com
>>>>> <mailto:fa= lk-ietf@dgftech.com>> wrote:
>>>>>
>>>>>> Michael-
>>>>>>
>>>>>> I'm actually OK with Joe's proposed wordin= g:
>>>>>>
>>>>>> On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (= jhildebr)
>>>>>> <jhildebr= @cisco.com <mailto:jhildebr@ci= sco.com>> wrote:
>>>>>>
>>>>>> =C2=A0 =C2=A0On 5/30/14, 8:29 AM, "Aaron Falk= " <falk-ietf@dgftech.com
>>>>>> =C2=A0 =C2=A0<mailto:falk-ietf@dgftech.com>> wrote:
>>>>>>
>>>>>>> My proposed wording change (which at least Gor= ry accepted) is
>>>>>> =C2=A0 =C2=A0not in the
>>>>>>> current draft. =C2=A0Repeating:
>>>>>>>
>>>>>>>
>>>>>>> Revise working group goal #2 to read "spe= cify a set of transport
>>>>>> =C2=A0 =C2=A0services
>>>>>>> that end systems **implementing TAPS** need to= provide and provide
>>>>>>> guidance on choosing among available mechanism= s and protocols to
>>>>>> =C2=A0 =C2=A0obtain a
>>>>>>> given transport service."
>>>>>>
>>>>>> =C2=A0 =C2=A0There's no protocol for TAPS yet,= so nobody is going to
>>>>>> =C2=A0 =C2=A0"implement TAPS".
>>>>>> =C2=A0 =C2=A0Suggested change: "end systems n= eed to provide" -> "applications
>>>>>> =C2=A0 =C2=A0want to
>>>>>> =C2=A0 =C2=A0use".
>>>>>>
>>>>>>
>>>>>> It allows the wg more flexibility which is probabl= y appropriate in
>>>>>> this stage.
>>>>>>
>>>>>> --aaron
>>>>>>
>>>>>>
>>>>>> On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl <= michawe@ifi.uio.no
>>>>>> <mailto:m= ichawe@ifi.uio.no>> wrote:
>>>>>>
>>>>>> =C2=A0 =C2=A0Hi!
>>>>>>
>>>>>> =C2=A0 =C2=A0Spencer, thank you very much for this= update. Much appreciated!
>>>>>>
>>>>>> =C2=A0 =C2=A0Regarding the charter bit, let's = try to figure out what
>>>>>> =C2=A0 =C2=A0specifically is needed. Here's th= e link to the
>>>>>> =C2=A0 =C2=A0always-most-up-to-date version:
>>>>>> =C2=A0 =C2=A0https://s= ites.google.com/site/transportprotocolservices/charter-proposal
>>>>>>
>>>>>> =C2=A0 =C2=A0You wrote:
>>>>>>
>>>>>>> =C2=A0 =C2=A0I'd like to see an updated ch= arter proposal that reflects recent
>>>>>>> =C2=A0 =C2=A0mailing list discussion, includin= g dropping the specifics about
>>>>>>> =C2=A0 =C2=A0document category, so that the fo= lks on the mailing list can
>>>>>>> =C2=A0 =C2=A0check whether their concerns have= been addressed.
>>>>>>
>>>>>> =C2=A0 =C2=A0What exactly do you mean with "d= ropping the specifics about
>>>>>> =C2=A0 =C2=A0document category" - is the sugg= estion to change WG goal #1,
>>>>>> =C2=A0 =C2=A0which now reads:
>>>>>> =C2=A0 =C2=A0"identify services provided by e= xisting IETF transport protocols
>>>>>> =C2=A0 =C2=A0and congestion control mechanisms, ba= sed on Standards-track and
>>>>>> =C2=A0 =C2=A0Experimental RFCs."
>>>>>> =C2=A0 =C2=A0to
>>>>>> =C2=A0 =C2=A0""identify services provide= d by existing IETF transport protocols
>>>>>> =C2=A0 =C2=A0and congestion control mechanisms&quo= t; ?
>>>>>>
>>>>>>
>>>>>> =C2=A0 =C2=A0For other changes, I'll try to re= cap the current state; please,
>>>>>> =C2=A0 =C2=A0all, if you feel I'm misrepresent= ing things, 1) it's definitely
>>>>>> =C2=A0 =C2=A0not intentionally, 2) by all means co= rrect me!
>>>>>>
>>>>>>
>>>>>> =C2=A0 =C2=A0The way I see it, we have 2 issues to= discuss.
>>>>>>
>>>>>>
>>>>>> =C2=A0 =C2=A0ISSUE 1:
>>>>>> =C2=A0 =C2=A0------------
>>>>>>
>>>>>> =C2=A0 =C2=A0We had some consensus on the charter = as it currently stands;
>>>>>> =C2=A0 =C2=A0then, there was the comment by Aaron = about a small wording change
>>>>>> =C2=A0 =C2=A0that I had missed, in WG goal #2, whi= ch currently reads:
>>>>>>
>>>>>> =C2=A0 =C2=A0"specify a set of transport serv= ices that end systems need to
>>>>>> =C2=A0 =C2=A0provide and provide guidance on choos= ing among available
>>>>>> =C2=A0 =C2=A0mechanisms and protocols to obtain a = given transport service."
>>>>>>
>>>>>> =C2=A0 =C2=A0Joe spoke against Aaron's change = and offered an alternative
>>>>>> =C2=A0 =C2=A0proposal, which again Gorry didn'= t like, saying that it seems to
>>>>>> =C2=A0 =C2=A0him to be a big change in what he'= ;s seen on the list.
>>>>>>
>>>>>> =C2=A0 =C2=A0My question at this point is: can we = keep the original text of
>>>>>> =C2=A0 =C2=A0goal #2 as I quote it here, or does a= nybody have yet another
>>>>>> =C2=A0 =C2=A0proposal that we all can live with? >>>>>>
>>>>>>
>>>>>> =C2=A0 =C2=A0ISSUE 2:
>>>>>> =C2=A0 =C2=A0------------
>>>>>>
>>>>>> =C2=A0 =C2=A0There were some arguments about the n= eed for WG goal #3,
>>>>>> =C2=A0 =C2=A0mechanisms to discover the availabili= ty of protocols... =C2=A0 - and
>>>>>> =C2=A0 =C2=A0it seems that several of us want to k= eep it. Can we (with the
>>>>>> =C2=A0 =C2=A0current text), or do we need to discu= ss this more?
>>>>>>
>>>>>>
>>>>>>
>>>>>> =C2=A0 =C2=A0Any other issues? Shoot, all =C2=A0:-= )
>>>>>>
>>>>>> =C2=A0 =C2=A0Cheers,
>>>>>> =C2=A0 =C2=A0Michael
>>>>>>
>>>>>>
>>>>>> =C2=A0 =C2=A0_____________________________________= __________
>>>>>> =C2=A0 =C2=A0Taps mailing list
>>>>>> =C2=A0 =C2=A0Taps= @ietf.org <mailto:Taps@ietf.org= >
>>>>>> =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/t= aps
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
ht= tps://www.ietf.org/mailman/listinfo/taps

--001a1135e18cb404cc04faf2e3f7-- From nobody Wed Jun 4 01:39:37 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4831A0111 for ; Wed, 4 Jun 2014 01:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 lYoZhz8Z8cyc for ; Wed, 4 Jun 2014 01:39:33 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 538341A010D for ; Wed, 4 Jun 2014 01:39:32 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Ws6jE-0000Ft-Ld; Wed, 04 Jun 2014 10:39:24 +0200 Received: from dhcp-064120.wlan.ntnu.no ([78.91.64.120]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Ws6jD-0000Q7-94; Wed, 04 Jun 2014 10:39:24 +0200 From: Michael Welzl Content-Type: multipart/alternative; boundary="Apple-Mail=_93AD9604-CC1E-42AF-A015-089C9082B5A4" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Date: Wed, 4 Jun 2014 10:39:22 +0200 References: To: Joe Hildebrand X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 2 sum msgs/h 1 total rcpts 17247 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: AF54A1AFE461651494A967459509B54A80C4B6A6 X-UiO-SPAM-Test: remote_host: 78.91.64.120 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 3 max/h 1 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/P-nBDUsIc4i2_2LVs4HF0FrGvMY Cc: taps@ietf.org Subject: [Taps] Fwd: So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 08:39:36 -0000 --Apple-Mail=_93AD9604-CC1E-42AF-A015-089C9082B5A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Joe, I think I need you to say on the TAPS list whether you agree with this = or not. It's about this text bit: ""specify a set of transport services that end systems supporting TAPS need to provide and provide guidance on choosing among available mechanisms and protocols to obtain a given transport service." (below, Anna spoke against your suggested text and suggested this = alternative) My personal opinion: I'd go with Anna's suggestion - this whole "what do = applications want" question is a never-ending story and doesn't seem to = be necessary to me: as Brian called it, we start with the "support side" = here, not the "demand side". TAPS is only the beginning. Cheers, Michael Begin forwarded message: > From: Aaron Falk > Subject: Re: [Taps] So, is this the -00 charter yet? > Date: 3. juni 2014 20:43:16 CEST > To: Michael Welzl > Cc: "taps@ietf.org" >=20 > fine with me >=20 > --aaron >=20 >=20 > On Tue, Jun 3, 2014 at 4:54 AM, Michael Welzl = wrote: > Aaron? Joe? >=20 >=20 > On 3. juni 2014, at 10:46, Gorry Fairhurst = wrote: >=20 > > Sorry, "yes". > > > > Gorry > > > > > > On 03/06/2014 09:17, Michael Welzl wrote: > >> Anna talked about item #2, not item #3 (where no other wording was = proposed I think), so your response is confusing. Try again? > >> > >> Do you agree with Anna's proposed wording for item #2? I do. > >> > >> > >> On 3. juni 2014, at 09:31, gorry@erg.abdn.ac.uk wrote: > >> > >>> My original point was that I did not think this was the piece = about what > >>> applications wanted to use - that I thought was going to be part = of #2, my > >>> thoughts were that #3 related to the transport system working out = what was > >>> actually supported, and the mechanisms (tricks, protocols and = messages to > >>> be exchanged) to complete this process determining a usable = transport. My > >>> view is probably a fairly modular way of looking at the problem - = but it > >>> would allow at least something to be built, and experimentally = deployed - > >>> who knows, if the method works it would achieve the goal. > >>> > >>> That's not to say there isn't a chance for a richer "apps" = interaction, > >>> i'd juts like a focus on what paths *support*. Putting more over = UDP > >>> probably heightens the need to also do the apps part - but UDP = also has > >>> its own set of path issues. My argument is that the TAPS #3 item = needs to > >>> focus on finding a transport that can be used over the path - if = that > >>> can't be fixed, then TAPS can't succeed. > >>> > >>> Gorry > >>> > >>>> Hi, > >>>> > >>>> I do not like "applications want to use". The application = requirements > >>>> give input for the services to specify, but to say that we should > >>>> specify what applications want to use sounds strange to me. > >>>> > >>>> I think the current formulation is better and more clear. I am = also fine > >>>> with the "implementing TAPS" addition that Aaron suggested. But = as Joe > >>>> did not like "implementing", how about: > >>>> > >>>> "specify a set of transport services that end systems supporting = TAPS > >>>> need to provide and provide guidance on choosing among available > >>>> mechanisms and protocols to obtain a given transport service." > >>>> > >>>> Anna > >>>> > >>>> > >>>> On 2014-06-03 00:13, Michael Welzl wrote: > >>>>> other opinions? (myself, i'm neutral) > >>>>> > >>>>> Sent from my iPhone > >>>>> > >>>>> On 3. juni 2014, at 00:02, Aaron Falk >>>>> > wrote: > >>>>> > >>>>>> Michael- > >>>>>> > >>>>>> I'm actually OK with Joe's proposed wording: > >>>>>> > >>>>>> On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (jhildebr) > >>>>>> > wrote: > >>>>>> > >>>>>> On 5/30/14, 8:29 AM, "Aaron Falk" >>>>>> > wrote: > >>>>>> > >>>>>>> My proposed wording change (which at least Gorry accepted) is > >>>>>> not in the > >>>>>>> current draft. Repeating: > >>>>>>> > >>>>>>> > >>>>>>> Revise working group goal #2 to read "specify a set of = transport > >>>>>> services > >>>>>>> that end systems **implementing TAPS** need to provide and = provide > >>>>>>> guidance on choosing among available mechanisms and protocols = to > >>>>>> obtain a > >>>>>>> given transport service." > >>>>>> > >>>>>> There's no protocol for TAPS yet, so nobody is going to > >>>>>> "implement TAPS". > >>>>>> Suggested change: "end systems need to provide" -> = "applications > >>>>>> want to > >>>>>> use". > >>>>>> > >>>>>> > >>>>>> It allows the wg more flexibility which is probably appropriate = in > >>>>>> this stage. > >>>>>> > >>>>>> --aaron > >>>>>> > >>>>>> > >>>>>> On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl = >>>>>> > wrote: > >>>>>> > >>>>>> Hi! > >>>>>> > >>>>>> Spencer, thank you very much for this update. Much = appreciated! > >>>>>> > >>>>>> Regarding the charter bit, let's try to figure out what > >>>>>> specifically is needed. Here's the link to the > >>>>>> always-most-up-to-date version: > >>>>>> = https://sites.google.com/site/transportprotocolservices/charter-proposal > >>>>>> > >>>>>> You wrote: > >>>>>> > >>>>>>> I'd like to see an updated charter proposal that reflects = recent > >>>>>>> mailing list discussion, including dropping the specifics = about > >>>>>>> document category, so that the folks on the mailing list = can > >>>>>>> check whether their concerns have been addressed. > >>>>>> > >>>>>> What exactly do you mean with "dropping the specifics about > >>>>>> document category" - is the suggestion to change WG goal #1, > >>>>>> which now reads: > >>>>>> "identify services provided by existing IETF transport = protocols > >>>>>> and congestion control mechanisms, based on Standards-track = and > >>>>>> Experimental RFCs." > >>>>>> to > >>>>>> ""identify services provided by existing IETF transport = protocols > >>>>>> and congestion control mechanisms" ? > >>>>>> > >>>>>> > >>>>>> For other changes, I'll try to recap the current state; = please, > >>>>>> all, if you feel I'm misrepresenting things, 1) it's = definitely > >>>>>> not intentionally, 2) by all means correct me! > >>>>>> > >>>>>> > >>>>>> The way I see it, we have 2 issues to discuss. > >>>>>> > >>>>>> > >>>>>> ISSUE 1: > >>>>>> ------------ > >>>>>> > >>>>>> We had some consensus on the charter as it currently stands; > >>>>>> then, there was the comment by Aaron about a small wording = change > >>>>>> that I had missed, in WG goal #2, which currently reads: > >>>>>> > >>>>>> "specify a set of transport services that end systems need = to > >>>>>> provide and provide guidance on choosing among available > >>>>>> mechanisms and protocols to obtain a given transport = service." > >>>>>> > >>>>>> Joe spoke against Aaron's change and offered an alternative > >>>>>> proposal, which again Gorry didn't like, saying that it = seems to > >>>>>> him to be a big change in what he's seen on the list. > >>>>>> > >>>>>> My question at this point is: can we keep the original text = of > >>>>>> goal #2 as I quote it here, or does anybody have yet another > >>>>>> proposal that we all can live with? > >>>>>> > >>>>>> > >>>>>> ISSUE 2: > >>>>>> ------------ > >>>>>> > >>>>>> There were some arguments about the need for WG goal #3, > >>>>>> mechanisms to discover the availability of protocols... - = and > >>>>>> it seems that several of us want to keep it. Can we (with = the > >>>>>> current text), or do we need to discuss this more? > >>>>>> > >>>>>> > >>>>>> > >>>>>> Any other issues? Shoot, all :-) > >>>>>> > >>>>>> Cheers, > >>>>>> Michael > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > >> > > >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps >=20 --Apple-Mail=_93AD9604-CC1E-42AF-A015-089C9082B5A4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Joe,

I think I need you to say on the TAPS list = whether you agree with this or not.

It's about = this text bit:
""specify a set of transport services that end = systems supporting TAPS
need to provide and provide guidance on = choosing among available
mechanisms and protocols to obtain a given = transport service."

(below, Anna spoke against = your suggested text and suggested this = alternative)

My personal opinion: I'd go with = Anna's suggestion - this whole "what do applications want" question is a = never-ending story and doesn't seem to be necessary to me: as Brian = called it, we start with the "support side" here, not the "demand side". = TAPS is only the = beginning.

Cheers,
Michael


Begin forwarded message:

From: Aaron Falk <falk-ietf@dgftech.com>
Subject: = Re: [Taps] So, is = this the -00 charter yet?
Date: = 3. juni 2014 = 20:43:16 CEST
To: = Michael Welzl <michawe@ifi.uio.no>

fine with = me

--aaron


On Tue, Jun 3, = 2014 at 4:54 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
Aaron?  Joe?


On 3. juni 2014, at 10:46, Gorry Fairhurst <gorry@erg.abdn.ac.uk> = wrote:

> Sorry, "yes".
>
> Gorry
>
>
> On 03/06/2014 09:17, Michael Welzl wrote:
>> Anna talked about item #2, not item #3 (where no other wording = was proposed I think), so your response is confusing. Try again?
>>
>> Do you agree with Anna's proposed wording for item #2?  I = do.
>>
>>
>> On 3. juni 2014, at 09:31, gorry@erg.abdn.ac.uk wrote:
>>
>>> My original point was that I did not think this was the = piece about what
>>> applications wanted to use - that I thought was going to be = part of #2, my
>>> thoughts were that #3 related to the transport system = working out what was
>>> actually supported, and the mechanisms (tricks, protocols = and messages to
>>> be exchanged) to complete this process determining a usable = transport.  My
>>> view is probably a fairly modular way of looking at the = problem - but it
>>> would allow at least something to be built, and = experimentally deployed -
>>> who knows, if the method works it would achieve the = goal.
>>>
>>> That's not to say there isn't a chance for a richer "apps" = interaction,
>>> i'd juts like a focus on what paths *support*. =  Putting more over UDP
>>> probably heightens the need to also do the apps part - but = UDP also has
>>> its own set of path issues. My argument is that the TAPS #3 = item needs to
>>> focus on finding a transport that can be used over the path = - if that
>>> can't be fixed, then TAPS can't succeed.
>>>
>>> Gorry
>>>
>>>> Hi,
>>>>
>>>> I do not like "applications want to use". The = application requirements
>>>> give input for the services to specify, but to say that = we should
>>>> specify what applications want to use sounds strange to = me.
>>>>
>>>> I think the current formulation is better and more = clear. I am also fine
>>>> with the "implementing TAPS" addition that Aaron = suggested. But as Joe
>>>> did not like "implementing", how about:
>>>>
>>>> "specify a set of transport services that end systems = supporting TAPS
>>>> need to provide and provide guidance on choosing among = available
>>>> mechanisms and protocols to obtain a given transport = service."
>>>>
>>>> Anna
>>>>
>>>>
>>>> On 2014-06-03 00:13, Michael Welzl wrote:
>>>>> other opinions? (myself, i'm neutral)
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On 3. juni 2014, at 00:02, Aaron Falk <falk-ietf@dgftech.com
>>>>> <mailto:falk-ietf@dgftech.com>> = wrote:
>>>>>
>>>>>> Michael-
>>>>>>
>>>>>> I'm actually OK with Joe's proposed = wording:
>>>>>>
>>>>>> On Fri, May 30, 2014 at 11:55 AM, Joe = Hildebrand (jhildebr)
>>>>>> <jhildebr@cisco.com <mailto:jhildebr@cisco.com>> = wrote:
>>>>>>
>>>>>>    On 5/30/14, 8:29 AM, "Aaron Falk" = <falk-ietf@dgftech.com
= >>>>>>    <mailto:falk-ietf@dgftech.com>> = wrote:
>>>>>>
>>>>>>> My proposed wording change (which at least = Gorry accepted) is
>>>>>>    not in the
>>>>>>> current draft.  Repeating:
>>>>>>>
>>>>>>>
>>>>>>> Revise working group goal #2 to read = "specify a set of transport
>>>>>>    services
>>>>>>> that end systems **implementing TAPS** need = to provide and provide
>>>>>>> guidance on choosing among available = mechanisms and protocols to
>>>>>>    obtain a
>>>>>>> given transport service."
>>>>>>
>>>>>>    There's no protocol for TAPS yet, = so nobody is going to
>>>>>>    "implement TAPS".
>>>>>>    Suggested change: "end systems = need to provide" -> "applications
>>>>>>    want to
>>>>>>    use".
>>>>>>
>>>>>>
>>>>>> It allows the wg more flexibility which is = probably appropriate in
>>>>>> this stage.
>>>>>>
>>>>>> --aaron
>>>>>>
>>>>>>
>>>>>> On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl = <michawe@ifi.uio.no
>>>>>> <mailto:michawe@ifi.uio.no>> = wrote:
>>>>>>
>>>>>>    Hi!
>>>>>>
>>>>>>    Spencer, thank you very much for = this update. Much appreciated!
>>>>>>
>>>>>>    Regarding the charter bit, let's = try to figure out what
>>>>>>    specifically is needed. Here's the = link to the
>>>>>>    always-most-up-to-date = version:
>>>>>>    https://sites.google.com/site/transportprotocolservices/= charter-proposal
>>>>>>
>>>>>>    You wrote:
>>>>>>
>>>>>>>    I'd like to see an updated = charter proposal that reflects recent
>>>>>>>    mailing list discussion, = including dropping the specifics about
>>>>>>>    document category, so that the = folks on the mailing list can
>>>>>>>    check whether their concerns = have been addressed.
>>>>>>
>>>>>>    What exactly do you mean with = "dropping the specifics about
>>>>>>    document category" - is the = suggestion to change WG goal #1,
>>>>>>    which now reads:
>>>>>>    "identify services provided by = existing IETF transport protocols
>>>>>>    and congestion control mechanisms, = based on Standards-track and
>>>>>>    Experimental RFCs."
>>>>>>    to
>>>>>>    ""identify services provided by = existing IETF transport protocols
>>>>>>    and congestion control mechanisms" = ?
>>>>>>
>>>>>>
>>>>>>    For other changes, I'll try to = recap the current state; please,
>>>>>>    all, if you feel I'm = misrepresenting things, 1) it's definitely
>>>>>>    not intentionally, 2) by all means = correct me!
>>>>>>
>>>>>>
>>>>>>    The way I see it, we have 2 issues = to discuss.
>>>>>>
>>>>>>
>>>>>>    ISSUE 1:
>>>>>>    ------------
>>>>>>
>>>>>>    We had some consensus on the = charter as it currently stands;
>>>>>>    then, there was the comment by = Aaron about a small wording change
>>>>>>    that I had missed, in WG goal #2, = which currently reads:
>>>>>>
>>>>>>    "specify a set of transport = services that end systems need to
>>>>>>    provide and provide guidance on = choosing among available
>>>>>>    mechanisms and protocols to obtain = a given transport service."
>>>>>>
>>>>>>    Joe spoke against Aaron's change = and offered an alternative
>>>>>>    proposal, which again Gorry didn't = like, saying that it seems to
>>>>>>    him to be a big change in what = he's seen on the list.
>>>>>>
>>>>>>    My question at this point is: can = we keep the original text of
>>>>>>    goal #2 as I quote it here, or = does anybody have yet another
>>>>>>    proposal that we all can live = with?
>>>>>>
>>>>>>
>>>>>>    ISSUE 2:
>>>>>>    ------------
>>>>>>
>>>>>>    There were some arguments about = the need for WG goal #3,
>>>>>>    mechanisms to discover the = availability of protocols...   - and
>>>>>>    it seems that several of us want = to keep it. Can we (with the
>>>>>>    current text), or do we need to = discuss this more?
>>>>>>
>>>>>>
>>>>>>
>>>>>>    Any other issues? Shoot, all =  :-)
>>>>>>
>>>>>>    Cheers,
>>>>>>    Michael
>>>>>>
>>>>>>
>>>>>>   =  _______________________________________________
>>>>>>    Taps mailing list
>>>>>>    Taps@ietf.org <mailto: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


= --Apple-Mail=_93AD9604-CC1E-42AF-A015-089C9082B5A4-- From nobody Wed Jun 4 01:48:38 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7F01A0109 for ; Wed, 4 Jun 2014 01:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 241yXucedG_X for ; Wed, 4 Jun 2014 01:48:34 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id F23821A0111 for ; Wed, 4 Jun 2014 01:48:33 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::8] (unknown [IPv6:2001:67c:10ec:2a49:8000::8]) by trammell.ch (Postfix) with ESMTPSA id 867331A09E5; Wed, 4 Jun 2014 10:47:56 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_645B3E26-EEFD-4D06-A4C7-03D7FA4C2C9F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Brian Trammell In-Reply-To: Date: Wed, 4 Jun 2014 10:47:56 +0200 Message-Id: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> References: To: Michael Welzl X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/z0O_c1chy-UKhTzgYdtEZf441L0 Cc: Joe Hildebrand , taps@ietf.org Subject: Re: [Taps] Fwd: So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 08:48:37 -0000 --Apple-Mail=_645B3E26-EEFD-4D06-A4C7-03D7FA4C2C9F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Michael, all, I think the point Joe was trying to make here (please correct me, Joe) = is more that the supply-side does, at some point, need to match up with = services that applications that will actually use. Yes, we're doing = things from the supply-side in TAPS, but we will need participation from = application developers at the _very_ least as a sanity check on the = output of TAPS.=20 That said, I'm personally happy with Anna's text here, since trying to = draw a boundary around "what applications want" within the charter is = probably a less productive way to do this IMO than just making sure the = app developers are paying attention _during_ discussions of the = milestones on the charter. The IAB "IP Stack Evolution" = program-in-formation (current name is still subject to change, program = scope to be published shortly) will have as one of its goals working = together with the chairs of TAPS and within the WG itself to foster this = cross-area coordination. Cheers, Brian On 04 Jun 2014, at 10:39, Michael Welzl wrote: > Hi Joe, >=20 > I think I need you to say on the TAPS list whether you agree with this = or not. >=20 > It's about this text bit: > ""specify a set of transport services that end systems supporting TAPS > need to provide and provide guidance on choosing among available > mechanisms and protocols to obtain a given transport service." >=20 > (below, Anna spoke against your suggested text and suggested this = alternative) >=20 > My personal opinion: I'd go with Anna's suggestion - this whole "what = do applications want" question is a never-ending story and doesn't seem = to be necessary to me: as Brian called it, we start with the "support = side" here, not the "demand side". TAPS is only the beginning. >=20 > Cheers, > Michael >=20 >=20 >=20 > Begin forwarded message: >=20 >> From: Aaron Falk >> Subject: Re: [Taps] So, is this the -00 charter yet? >> Date: 3. juni 2014 20:43:16 CEST >> To: Michael Welzl >> Cc: "taps@ietf.org" >>=20 >> fine with me >>=20 >> --aaron >>=20 >>=20 >> On Tue, Jun 3, 2014 at 4:54 AM, Michael Welzl = wrote: >> Aaron? Joe? >>=20 >>=20 >> On 3. juni 2014, at 10:46, Gorry Fairhurst = wrote: >>=20 >> > Sorry, "yes". >> > >> > Gorry >> > >> > >> > On 03/06/2014 09:17, Michael Welzl wrote: >> >> Anna talked about item #2, not item #3 (where no other wording was = proposed I think), so your response is confusing. Try again? >> >> >> >> Do you agree with Anna's proposed wording for item #2? I do. >> >> >> >> >> >> On 3. juni 2014, at 09:31, gorry@erg.abdn.ac.uk wrote: >> >> >> >>> My original point was that I did not think this was the piece = about what >> >>> applications wanted to use - that I thought was going to be part = of #2, my >> >>> thoughts were that #3 related to the transport system working out = what was >> >>> actually supported, and the mechanisms (tricks, protocols and = messages to >> >>> be exchanged) to complete this process determining a usable = transport. My >> >>> view is probably a fairly modular way of looking at the problem - = but it >> >>> would allow at least something to be built, and experimentally = deployed - >> >>> who knows, if the method works it would achieve the goal. >> >>> >> >>> That's not to say there isn't a chance for a richer "apps" = interaction, >> >>> i'd juts like a focus on what paths *support*. Putting more over = UDP >> >>> probably heightens the need to also do the apps part - but UDP = also has >> >>> its own set of path issues. My argument is that the TAPS #3 item = needs to >> >>> focus on finding a transport that can be used over the path - if = that >> >>> can't be fixed, then TAPS can't succeed. >> >>> >> >>> Gorry >> >>> >> >>>> Hi, >> >>>> >> >>>> I do not like "applications want to use". The application = requirements >> >>>> give input for the services to specify, but to say that we = should >> >>>> specify what applications want to use sounds strange to me. >> >>>> >> >>>> I think the current formulation is better and more clear. I am = also fine >> >>>> with the "implementing TAPS" addition that Aaron suggested. But = as Joe >> >>>> did not like "implementing", how about: >> >>>> >> >>>> "specify a set of transport services that end systems supporting = TAPS >> >>>> need to provide and provide guidance on choosing among available >> >>>> mechanisms and protocols to obtain a given transport service." >> >>>> >> >>>> Anna >> >>>> >> >>>> >> >>>> On 2014-06-03 00:13, Michael Welzl wrote: >> >>>>> other opinions? (myself, i'm neutral) >> >>>>> >> >>>>> Sent from my iPhone >> >>>>> >> >>>>> On 3. juni 2014, at 00:02, Aaron Falk > >>>>> > wrote: >> >>>>> >> >>>>>> Michael- >> >>>>>> >> >>>>>> I'm actually OK with Joe's proposed wording: >> >>>>>> >> >>>>>> On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (jhildebr) >> >>>>>> > wrote: >> >>>>>> >> >>>>>> On 5/30/14, 8:29 AM, "Aaron Falk" > >>>>>> > wrote: >> >>>>>> >> >>>>>>> My proposed wording change (which at least Gorry accepted) is >> >>>>>> not in the >> >>>>>>> current draft. Repeating: >> >>>>>>> >> >>>>>>> >> >>>>>>> Revise working group goal #2 to read "specify a set of = transport >> >>>>>> services >> >>>>>>> that end systems **implementing TAPS** need to provide and = provide >> >>>>>>> guidance on choosing among available mechanisms and protocols = to >> >>>>>> obtain a >> >>>>>>> given transport service." >> >>>>>> >> >>>>>> There's no protocol for TAPS yet, so nobody is going to >> >>>>>> "implement TAPS". >> >>>>>> Suggested change: "end systems need to provide" -> = "applications >> >>>>>> want to >> >>>>>> use". >> >>>>>> >> >>>>>> >> >>>>>> It allows the wg more flexibility which is probably = appropriate in >> >>>>>> this stage. >> >>>>>> >> >>>>>> --aaron >> >>>>>> >> >>>>>> >> >>>>>> On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl = > >>>>>> > wrote: >> >>>>>> >> >>>>>> Hi! >> >>>>>> >> >>>>>> Spencer, thank you very much for this update. Much = appreciated! >> >>>>>> >> >>>>>> Regarding the charter bit, let's try to figure out what >> >>>>>> specifically is needed. Here's the link to the >> >>>>>> always-most-up-to-date version: >> >>>>>> = https://sites.google.com/site/transportprotocolservices/charter-proposal >> >>>>>> >> >>>>>> You wrote: >> >>>>>> >> >>>>>>> I'd like to see an updated charter proposal that reflects = recent >> >>>>>>> mailing list discussion, including dropping the specifics = about >> >>>>>>> document category, so that the folks on the mailing list = can >> >>>>>>> check whether their concerns have been addressed. >> >>>>>> >> >>>>>> What exactly do you mean with "dropping the specifics about >> >>>>>> document category" - is the suggestion to change WG goal = #1, >> >>>>>> which now reads: >> >>>>>> "identify services provided by existing IETF transport = protocols >> >>>>>> and congestion control mechanisms, based on Standards-track = and >> >>>>>> Experimental RFCs." >> >>>>>> to >> >>>>>> ""identify services provided by existing IETF transport = protocols >> >>>>>> and congestion control mechanisms" ? >> >>>>>> >> >>>>>> >> >>>>>> For other changes, I'll try to recap the current state; = please, >> >>>>>> all, if you feel I'm misrepresenting things, 1) it's = definitely >> >>>>>> not intentionally, 2) by all means correct me! >> >>>>>> >> >>>>>> >> >>>>>> The way I see it, we have 2 issues to discuss. >> >>>>>> >> >>>>>> >> >>>>>> ISSUE 1: >> >>>>>> ------------ >> >>>>>> >> >>>>>> We had some consensus on the charter as it currently = stands; >> >>>>>> then, there was the comment by Aaron about a small wording = change >> >>>>>> that I had missed, in WG goal #2, which currently reads: >> >>>>>> >> >>>>>> "specify a set of transport services that end systems need = to >> >>>>>> provide and provide guidance on choosing among available >> >>>>>> mechanisms and protocols to obtain a given transport = service." >> >>>>>> >> >>>>>> Joe spoke against Aaron's change and offered an alternative >> >>>>>> proposal, which again Gorry didn't like, saying that it = seems to >> >>>>>> him to be a big change in what he's seen on the list. >> >>>>>> >> >>>>>> My question at this point is: can we keep the original text = of >> >>>>>> goal #2 as I quote it here, or does anybody have yet = another >> >>>>>> proposal that we all can live with? >> >>>>>> >> >>>>>> >> >>>>>> ISSUE 2: >> >>>>>> ------------ >> >>>>>> >> >>>>>> There were some arguments about the need for WG goal #3, >> >>>>>> mechanisms to discover the availability of protocols... - = and >> >>>>>> it seems that several of us want to keep it. Can we (with = the >> >>>>>> current text), or do we need to discuss this more? >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> Any other issues? Shoot, all :-) >> >>>>>> >> >>>>>> Cheers, >> >>>>>> Michael >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> 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 >> >> >> > >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >>=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_645B3E26-EEFD-4D06-A4C7-03D7FA4C2C9F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTjt09AAoJENt3nsOmbNJcIycH/1Q6lIvYvF/fE8vv+ctmtgmb 1beoXFHCvTUK4srtwNAhwnSyV7L7jvtuKVHMKYDWl/aH7dU1oJGuaoRuDIhLJl4X 9eu39trV0KWL9GcSPIoZYpZlM+Alv40SCWTy3REpEROkw7FdGm3rctL8clRWeiQI pFkVE/gLEnezG239/uCQfolt/a/irmkUc2/IPojlPaFTJWPr45t3MoqnxVPs8PMx P137o0feKK4cQ5qjJ8vfAksMAyIy8xgm1mNlqJSNqmSas5rZJV4jxCpIX3kZCACM hFIJCcSPtf9R0HMutYM6bp4qQ0hbRx68/c2/GAABq8fuLyRShJz4Shbda2yhCuc= =JelS -----END PGP SIGNATURE----- --Apple-Mail=_645B3E26-EEFD-4D06-A4C7-03D7FA4C2C9F-- From nobody Wed Jun 4 02:02:21 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35131A0132 for ; Wed, 4 Jun 2014 02:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 mcOGPlXGtDpc for ; Wed, 4 Jun 2014 02:02:17 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B11701A0126 for ; Wed, 4 Jun 2014 02:02:16 -0700 (PDT) X-AuditID: 1209190f-f790b6d000000c38-60-538ee091882b Received: from mailhub-2.mit.edu ( [18.7.62.30]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 33.60.03128.190EE835; Wed, 4 Jun 2014 05:02:09 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-1.mit.edu [18.9.28.12]) by mailhub-2.mit.edu (8.13.8/8.9.2) with ESMTP id s54927IW028302; Wed, 4 Jun 2014 05:02:08 -0400 Received: from webmail-10.mit.edu (webmail-10.mit.edu [18.9.23.20]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s549252x023462; Wed, 4 Jun 2014 05:02:06 -0400 Received: from webmail-10.mit.edu (webmail-10.mit.edu [127.0.0.1]) by webmail-10.mit.edu (8.13.8) with ESMTP id s54925Rg021437; Wed, 4 Jun 2014 05:02:05 -0400 Received: (from nobody@localhost) by webmail-10.mit.edu (8.13.8/8.13.8/Submit) id s54924OK021436; Wed, 4 Jun 2014 05:02:04 -0400 X-Authentication-Warning: webmail-10.mit.edu: nobody set sender to mariejo@mit.edu using -f Received: from hakea3.isae.fr (hakea3.isae.fr [193.54.120.34]) (User authenticated as mariejo@ATHENA.MIT.EDU) by webmail.mit.edu (Horde MIME library) with HTTP; Wed, 04 Jun 2014 05:02:04 -0400 Message-ID: <20140604050204.p5a00h7lusccggw8@webmail.mit.edu> Date: Wed, 04 Jun 2014 05:02:04 -0400 From: Marie-Jose Montpetit To: Brian Trammell References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> In-Reply-To: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrEKsWRmVeSWpSXmKPExsUixG4npzvxQV+wwbsufYuNLe/YLM7uOc5u 8ePsTlaLOzEOLB5Tfm9k9Viy5CeTx+rVD5k9nuyfyRLAEsVlk5Kak1mWWqRvl8CVcWrZCpaC heEVW5r2sjQw7nTtYuTkkBAwkeh+/pgFwhaTuHBvPVsXIxeHkMA0JonOP8+ZIZxljBKXFz1n gnDWMEosv3QWrEVIYAGjxNlvRRCJFqCqvYtZIWZFS6yfvo4FInGMUeJM6znGLkYODl4BW4k7 p9VBalgEVCXOdDWzgdhsAjoSnw5NBbNFgOLdjZfYQWxmgVSJ7iM7mEBsYQErieUfVzFCzNzF KHHwwTk2kJmcAvYSPRv5QGp4BQQlTs58wgLR6yjxt7cZrIRZQFpi+T8OiLC8xPa3c5hBbFEB c4kHe3cwTmAUm4WkexaS7lkI3bOQdC9gZFnFKJuSW6Wbm5iZU5yarFucnJiXl1qka6KXm1mi l5pSuokRFHWckvw7GL8dVDrEKMDBqMTDO+Fmb7AQa2JZcWXuIUZJDiYlUd6LR/uChfiS8lMq MxKLM+KLSnNSiw8xSnAwK4nwzrkBlONNSaysSi3Kh0lJc7AoifO+tbYKFhJITyxJzU5NLUgt gsnKcHAoSfDOvQ/UKFiUmp5akZaZU4KQZuLgBBnOAzT84D2Q4cUFibnFmekQ+VOMilLivD0g CQGQREZpHlwvLCm+YhQHekWY9xLICh5gQoXrfgU0mAlo8OaiXpDBJYkIKakGRuGqY1OX9iSf vmixZeOh6Bcxu5wZZd5emP+/1Z/FLOpq5q0OGdMyx9m24rv3nX+ksdaOOf3RL6U0I/9LnDOW 5k/hbolqfj8lt//VwQkzihoSzY/tSbKPnLThke/5OddTvJcdbLtSGP06exKX8i2/wJsdgq7f bFx/5v7qWhnLLiVewr5r3bafDkosxRmJhlrMRcWJAJfZRw9lAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/taps/DQ7evkzz41ZJTkhiuQZ5Ot8jHrY Cc: Joe Hildebrand , Michael Welzl , taps@ietf.org Subject: Re: [Taps] Fwd: So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 09:02:20 -0000 Yes to get more applications developers. I do have a problem with "what applicactions want". I think it should be "what applications require"? Quoting Brian Trammell : > hi Michael, all, > > I think the point Joe was trying to make here (please correct me, > Joe) is more that the supply-side does, at some point, need to match > up with services that applications that will actually use. Yes, we're > doing things from the supply-side in TAPS, but we will need > participation from application developers at the _very_ least as a > sanity check on the output of TAPS. > > That said, I'm personally happy with Anna's text here, since trying > to draw a boundary around "what applications want" within the charter > is probably a less productive way to do this IMO than just making > sure the app developers are paying attention _during_ discussions of > the milestones on the charter. The IAB "IP Stack Evolution" > program-in-formation (current name is still subject to change, > program scope to be published shortly) will have as one of its goals > working together with the chairs of TAPS and within the WG itself to > foster this cross-area coordination. > > Cheers, > > Brian > > On 04 Jun 2014, at 10:39, Michael Welzl wrote: > >> Hi Joe, >> >> I think I need you to say on the TAPS list whether you agree with >> this or not. >> >> It's about this text bit: >> ""specify a set of transport services that end systems supporting TAPS >> need to provide and provide guidance on choosing among available >> mechanisms and protocols to obtain a given transport service." >> >> (below, Anna spoke against your suggested text and suggested this >> alternative) >> >> My personal opinion: I'd go with Anna's suggestion - this whole >> "what do applications want" question is a never-ending story and >> doesn't seem to be necessary to me: as Brian called it, we start >> with the "support side" here, not the "demand side". TAPS is only >> the beginning. >> >> Cheers, >> Michael >> >> >> >> Begin forwarded message: >> >>> From: Aaron Falk >>> Subject: Re: [Taps] So, is this the -00 charter yet? >>> Date: 3. juni 2014 20:43:16 CEST >>> To: Michael Welzl >>> Cc: "taps@ietf.org" >>> >>> fine with me >>> >>> --aaron >>> >>> >>> On Tue, Jun 3, 2014 at 4:54 AM, Michael Welzl wrote: >>> Aaron? Joe? >>> >>> >>> On 3. juni 2014, at 10:46, Gorry Fairhurst wrote: >>> >>> > Sorry, "yes". >>> > >>> > Gorry >>> > >>> > >>> > On 03/06/2014 09:17, Michael Welzl wrote: >>> >> Anna talked about item #2, not item #3 (where no other wording >>> was proposed I think), so your response is confusing. Try again? >>> >> >>> >> Do you agree with Anna's proposed wording for item #2? I do. >>> >> >>> >> >>> >> On 3. juni 2014, at 09:31, gorry@erg.abdn.ac.uk wrote: >>> >> >>> >>> My original point was that I did not think this was the piece >>> about what >>> >>> applications wanted to use - that I thought was going to be >>> part of #2, my >>> >>> thoughts were that #3 related to the transport system working >>> out what was >>> >>> actually supported, and the mechanisms (tricks, protocols and >>> messages to >>> >>> be exchanged) to complete this process determining a usable >>> transport. My >>> >>> view is probably a fairly modular way of looking at the problem >>> - but it >>> >>> would allow at least something to be built, and experimentally >>> deployed - >>> >>> who knows, if the method works it would achieve the goal. >>> >>> >>> >>> That's not to say there isn't a chance for a richer "apps" interaction, >>> >>> i'd juts like a focus on what paths *support*. Putting more over UDP >>> >>> probably heightens the need to also do the apps part - but UDP also has >>> >>> its own set of path issues. My argument is that the TAPS #3 >>> item needs to >>> >>> focus on finding a transport that can be used over the path - if that >>> >>> can't be fixed, then TAPS can't succeed. >>> >>> >>> >>> Gorry >>> >>> >>> >>>> Hi, >>> >>>> >>> >>>> I do not like "applications want to use". The application requirements >>> >>>> give input for the services to specify, but to say that we should >>> >>>> specify what applications want to use sounds strange to me. >>> >>>> >>> >>>> I think the current formulation is better and more clear. I am >>> also fine >>> >>>> with the "implementing TAPS" addition that Aaron suggested. But as Joe >>> >>>> did not like "implementing", how about: >>> >>>> >>> >>>> "specify a set of transport services that end systems supporting TAPS >>> >>>> need to provide and provide guidance on choosing among available >>> >>>> mechanisms and protocols to obtain a given transport service." >>> >>>> >>> >>>> Anna >>> >>>> >>> >>>> >>> >>>> On 2014-06-03 00:13, Michael Welzl wrote: >>> >>>>> other opinions? (myself, i'm neutral) >>> >>>>> >>> >>>>> Sent from my iPhone >>> >>>>> >>> >>>>> On 3. juni 2014, at 00:02, Aaron Falk >> >>>>> > wrote: >>> >>>>> >>> >>>>>> Michael- >>> >>>>>> >>> >>>>>> I'm actually OK with Joe's proposed wording: >>> >>>>>> >>> >>>>>> On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (jhildebr) >>> >>>>>> > wrote: >>> >>>>>> >>> >>>>>> On 5/30/14, 8:29 AM, "Aaron Falk" >> >>>>>> > wrote: >>> >>>>>> >>> >>>>>>> My proposed wording change (which at least Gorry accepted) is >>> >>>>>> not in the >>> >>>>>>> current draft. Repeating: >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> Revise working group goal #2 to read "specify a set of transport >>> >>>>>> services >>> >>>>>>> that end systems **implementing TAPS** need to provide and provide >>> >>>>>>> guidance on choosing among available mechanisms and protocols to >>> >>>>>> obtain a >>> >>>>>>> given transport service." >>> >>>>>> >>> >>>>>> There's no protocol for TAPS yet, so nobody is going to >>> >>>>>> "implement TAPS". >>> >>>>>> Suggested change: "end systems need to provide" -> "applications >>> >>>>>> want to >>> >>>>>> use". >>> >>>>>> >>> >>>>>> >>> >>>>>> It allows the wg more flexibility which is probably appropriate in >>> >>>>>> this stage. >>> >>>>>> >>> >>>>>> --aaron >>> >>>>>> >>> >>>>>> >>> >>>>>> On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl >> >>>>>> > wrote: >>> >>>>>> >>> >>>>>> Hi! >>> >>>>>> >>> >>>>>> Spencer, thank you very much for this update. Much appreciated! >>> >>>>>> >>> >>>>>> Regarding the charter bit, let's try to figure out what >>> >>>>>> specifically is needed. Here's the link to the >>> >>>>>> always-most-up-to-date version: >>> >>>>>> >>> https://sites.google.com/site/transportprotocolservices/charter-proposal >>> >>>>>> >>> >>>>>> You wrote: >>> >>>>>> >>> >>>>>>> I'd like to see an updated charter proposal that reflects recent >>> >>>>>>> mailing list discussion, including dropping the specifics about >>> >>>>>>> document category, so that the folks on the mailing list can >>> >>>>>>> check whether their concerns have been addressed. >>> >>>>>> >>> >>>>>> What exactly do you mean with "dropping the specifics about >>> >>>>>> document category" - is the suggestion to change WG goal #1, >>> >>>>>> which now reads: >>> >>>>>> "identify services provided by existing IETF transport protocols >>> >>>>>> and congestion control mechanisms, based on Standards-track and >>> >>>>>> Experimental RFCs." >>> >>>>>> to >>> >>>>>> ""identify services provided by existing IETF transport protocols >>> >>>>>> and congestion control mechanisms" ? >>> >>>>>> >>> >>>>>> >>> >>>>>> For other changes, I'll try to recap the current state; please, >>> >>>>>> all, if you feel I'm misrepresenting things, 1) it's definitely >>> >>>>>> not intentionally, 2) by all means correct me! >>> >>>>>> >>> >>>>>> >>> >>>>>> The way I see it, we have 2 issues to discuss. >>> >>>>>> >>> >>>>>> >>> >>>>>> ISSUE 1: >>> >>>>>> ------------ >>> >>>>>> >>> >>>>>> We had some consensus on the charter as it currently stands; >>> >>>>>> then, there was the comment by Aaron about a small wording change >>> >>>>>> that I had missed, in WG goal #2, which currently reads: >>> >>>>>> >>> >>>>>> "specify a set of transport services that end systems need to >>> >>>>>> provide and provide guidance on choosing among available >>> >>>>>> mechanisms and protocols to obtain a given transport service." >>> >>>>>> >>> >>>>>> Joe spoke against Aaron's change and offered an alternative >>> >>>>>> proposal, which again Gorry didn't like, saying that it seems to >>> >>>>>> him to be a big change in what he's seen on the list. >>> >>>>>> >>> >>>>>> My question at this point is: can we keep the original text of >>> >>>>>> goal #2 as I quote it here, or does anybody have yet another >>> >>>>>> proposal that we all can live with? >>> >>>>>> >>> >>>>>> >>> >>>>>> ISSUE 2: >>> >>>>>> ------------ >>> >>>>>> >>> >>>>>> There were some arguments about the need for WG goal #3, >>> >>>>>> mechanisms to discover the availability of protocols... - and >>> >>>>>> it seems that several of us want to keep it. Can we (with the >>> >>>>>> current text), or do we need to discuss this more? >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> Any other issues? Shoot, all :-) >>> >>>>>> >>> >>>>>> Cheers, >>> >>>>>> Michael >>> >>>>>> >>> >>>>>> >>> >>>>>> _______________________________________________ >>> >>>>>> 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 >>> >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > From nobody Wed Jun 4 02:04:19 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F20411A0132 for ; Wed, 4 Jun 2014 02:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 qKXUnt60pPCq for ; Wed, 4 Jun 2014 02:04:16 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955121A0126 for ; Wed, 4 Jun 2014 02:04:15 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Ws777-0006gz-Hn; Wed, 04 Jun 2014 11:04:05 +0200 Received: from dhcp-064120.wlan.ntnu.no ([78.91.64.120]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Ws776-0003Xq-Jf; Wed, 04 Jun 2014 11:04:05 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> Date: Wed, 4 Jun 2014 11:04:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2CF5E619-D270-48F2-B84A-6684F3A8E7E6@ifi.uio.no> References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 7 sum msgs/h 4 total rcpts 17257 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 93BCC27999F0DDBB7479C6286602C19F4E53BDC6 X-UiO-SPAM-Test: remote_host: 78.91.64.120 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 9 max/h 6 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/SFA_Z--s47TKS7J0JoV1brVITBo Cc: Joe Hildebrand , taps@ietf.org Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 09:04:19 -0000 ... and I should have been clearer about what I meant when I said: "this whole 'what do applications want' question is a never-ending story=20= =3D> I should have really phrased it as: the "should our charter include text, and if so, how, about 'what do = applications want' ?" - question is a never-ending story. The focus is really on charter text now. Glad to hear that you're happy = with Anna's text. I think once we get a similar statement from Joe we = can consider this one agreed upon. I have now applied Anna's text to the charter at: https://sites.google.com/site/transportprotocolservices/charter-proposal and also done the other change that Spencer requested. He wrote: = "...dropping the specifics about document category", with which he can = only have meant this text: "identify services provided by existing IETF transport protocols and = congestion control mechanisms, based on Standards-track and Experimental = RFCs." which I now changed to: "identify services provided by existing IETF transport protocols and = congestion control mechanisms" So, I think if we get an ok from Joe on this change, I can probably hand = this charter over to Spencer... Cheers, Michael On 4. juni 2014, at 10:47, Brian Trammell wrote: > hi Michael, all, >=20 > I think the point Joe was trying to make here (please correct me, Joe) = is more that the supply-side does, at some point, need to match up with = services that applications that will actually use. Yes, we're doing = things from the supply-side in TAPS, but we will need participation from = application developers at the _very_ least as a sanity check on the = output of TAPS.=20 >=20 > That said, I'm personally happy with Anna's text here, since trying to = draw a boundary around "what applications want" within the charter is = probably a less productive way to do this IMO than just making sure the = app developers are paying attention _during_ discussions of the = milestones on the charter. The IAB "IP Stack Evolution" = program-in-formation (current name is still subject to change, program = scope to be published shortly) will have as one of its goals working = together with the chairs of TAPS and within the WG itself to foster this = cross-area coordination. >=20 > Cheers, >=20 > Brian >=20 > On 04 Jun 2014, at 10:39, Michael Welzl wrote: >=20 >> Hi Joe, >>=20 >> I think I need you to say on the TAPS list whether you agree with = this or not. >>=20 >> It's about this text bit: >> ""specify a set of transport services that end systems supporting = TAPS >> need to provide and provide guidance on choosing among available >> mechanisms and protocols to obtain a given transport service." >>=20 >> (below, Anna spoke against your suggested text and suggested this = alternative) >>=20 >> My personal opinion: I'd go with Anna's suggestion - this whole "what = do applications want" question is a never-ending story and doesn't seem = to be necessary to me: as Brian called it, we start with the "support = side" here, not the "demand side". TAPS is only the beginning. >>=20 >> Cheers, >> Michael >>=20 >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: Aaron Falk >>> Subject: Re: [Taps] So, is this the -00 charter yet? >>> Date: 3. juni 2014 20:43:16 CEST >>> To: Michael Welzl >>> Cc: "taps@ietf.org" >>>=20 >>> fine with me >>>=20 >>> --aaron >>>=20 >>>=20 >>> On Tue, Jun 3, 2014 at 4:54 AM, Michael Welzl = wrote: >>> Aaron? Joe? >>>=20 >>>=20 >>> On 3. juni 2014, at 10:46, Gorry Fairhurst = wrote: >>>=20 >>>> Sorry, "yes". >>>>=20 >>>> Gorry >>>>=20 >>>>=20 >>>> On 03/06/2014 09:17, Michael Welzl wrote: >>>>> Anna talked about item #2, not item #3 (where no other wording was = proposed I think), so your response is confusing. Try again? >>>>>=20 >>>>> Do you agree with Anna's proposed wording for item #2? I do. >>>>>=20 >>>>>=20 >>>>> On 3. juni 2014, at 09:31, gorry@erg.abdn.ac.uk wrote: >>>>>=20 >>>>>> My original point was that I did not think this was the piece = about what >>>>>> applications wanted to use - that I thought was going to be part = of #2, my >>>>>> thoughts were that #3 related to the transport system working out = what was >>>>>> actually supported, and the mechanisms (tricks, protocols and = messages to >>>>>> be exchanged) to complete this process determining a usable = transport. My >>>>>> view is probably a fairly modular way of looking at the problem - = but it >>>>>> would allow at least something to be built, and experimentally = deployed - >>>>>> who knows, if the method works it would achieve the goal. >>>>>>=20 >>>>>> That's not to say there isn't a chance for a richer "apps" = interaction, >>>>>> i'd juts like a focus on what paths *support*. Putting more over = UDP >>>>>> probably heightens the need to also do the apps part - but UDP = also has >>>>>> its own set of path issues. My argument is that the TAPS #3 item = needs to >>>>>> focus on finding a transport that can be used over the path - if = that >>>>>> can't be fixed, then TAPS can't succeed. >>>>>>=20 >>>>>> Gorry >>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> I do not like "applications want to use". The application = requirements >>>>>>> give input for the services to specify, but to say that we = should >>>>>>> specify what applications want to use sounds strange to me. >>>>>>>=20 >>>>>>> I think the current formulation is better and more clear. I am = also fine >>>>>>> with the "implementing TAPS" addition that Aaron suggested. But = as Joe >>>>>>> did not like "implementing", how about: >>>>>>>=20 >>>>>>> "specify a set of transport services that end systems supporting = TAPS >>>>>>> need to provide and provide guidance on choosing among available >>>>>>> mechanisms and protocols to obtain a given transport service." >>>>>>>=20 >>>>>>> Anna >>>>>>>=20 >>>>>>>=20 >>>>>>> On 2014-06-03 00:13, Michael Welzl wrote: >>>>>>>> other opinions? (myself, i'm neutral) >>>>>>>>=20 >>>>>>>> Sent from my iPhone >>>>>>>>=20 >>>>>>>> On 3. juni 2014, at 00:02, Aaron Falk >>>>>>> > wrote: >>>>>>>>=20 >>>>>>>>> Michael- >>>>>>>>>=20 >>>>>>>>> I'm actually OK with Joe's proposed wording: >>>>>>>>>=20 >>>>>>>>> On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (jhildebr) >>>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>> On 5/30/14, 8:29 AM, "Aaron Falk" >>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>>> My proposed wording change (which at least Gorry accepted) is >>>>>>>>> not in the >>>>>>>>>> current draft. Repeating: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Revise working group goal #2 to read "specify a set of = transport >>>>>>>>> services >>>>>>>>>> that end systems **implementing TAPS** need to provide and = provide >>>>>>>>>> guidance on choosing among available mechanisms and protocols = to >>>>>>>>> obtain a >>>>>>>>>> given transport service." >>>>>>>>>=20 >>>>>>>>> There's no protocol for TAPS yet, so nobody is going to >>>>>>>>> "implement TAPS". >>>>>>>>> Suggested change: "end systems need to provide" -> = "applications >>>>>>>>> want to >>>>>>>>> use". >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> It allows the wg more flexibility which is probably = appropriate in >>>>>>>>> this stage. >>>>>>>>>=20 >>>>>>>>> --aaron >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl = >>>>>>>> > wrote: >>>>>>>>>=20 >>>>>>>>> Hi! >>>>>>>>>=20 >>>>>>>>> Spencer, thank you very much for this update. Much = appreciated! >>>>>>>>>=20 >>>>>>>>> Regarding the charter bit, let's try to figure out what >>>>>>>>> specifically is needed. Here's the link to the >>>>>>>>> always-most-up-to-date version: >>>>>>>>> = https://sites.google.com/site/transportprotocolservices/charter-proposal >>>>>>>>>=20 >>>>>>>>> You wrote: >>>>>>>>>=20 >>>>>>>>>> I'd like to see an updated charter proposal that reflects = recent >>>>>>>>>> mailing list discussion, including dropping the specifics = about >>>>>>>>>> document category, so that the folks on the mailing list = can >>>>>>>>>> check whether their concerns have been addressed. >>>>>>>>>=20 >>>>>>>>> What exactly do you mean with "dropping the specifics about >>>>>>>>> document category" - is the suggestion to change WG goal #1, >>>>>>>>> which now reads: >>>>>>>>> "identify services provided by existing IETF transport = protocols >>>>>>>>> and congestion control mechanisms, based on Standards-track = and >>>>>>>>> Experimental RFCs." >>>>>>>>> to >>>>>>>>> ""identify services provided by existing IETF transport = protocols >>>>>>>>> and congestion control mechanisms" ? >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> For other changes, I'll try to recap the current state; = please, >>>>>>>>> all, if you feel I'm misrepresenting things, 1) it's = definitely >>>>>>>>> not intentionally, 2) by all means correct me! >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> The way I see it, we have 2 issues to discuss. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> ISSUE 1: >>>>>>>>> ------------ >>>>>>>>>=20 >>>>>>>>> We had some consensus on the charter as it currently stands; >>>>>>>>> then, there was the comment by Aaron about a small wording = change >>>>>>>>> that I had missed, in WG goal #2, which currently reads: >>>>>>>>>=20 >>>>>>>>> "specify a set of transport services that end systems need = to >>>>>>>>> provide and provide guidance on choosing among available >>>>>>>>> mechanisms and protocols to obtain a given transport = service." >>>>>>>>>=20 >>>>>>>>> Joe spoke against Aaron's change and offered an alternative >>>>>>>>> proposal, which again Gorry didn't like, saying that it = seems to >>>>>>>>> him to be a big change in what he's seen on the list. >>>>>>>>>=20 >>>>>>>>> My question at this point is: can we keep the original text = of >>>>>>>>> goal #2 as I quote it here, or does anybody have yet another >>>>>>>>> proposal that we all can live with? >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> ISSUE 2: >>>>>>>>> ------------ >>>>>>>>>=20 >>>>>>>>> There were some arguments about the need for WG goal #3, >>>>>>>>> mechanisms to discover the availability of protocols... - = and >>>>>>>>> it seems that several of us want to keep it. Can we (with = the >>>>>>>>> current text), or do we need to discuss this more? >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Any other issues? Shoot, all :-) >>>>>>>>>=20 >>>>>>>>> Cheers, >>>>>>>>> Michael >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> Taps mailing list >>>>>>>>> Taps@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Taps mailing list >>>>>>>> Taps@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Taps mailing list >>>>>>> Taps@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Taps mailing list >>>>>> Taps@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Taps mailing list >>>>> Taps@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>>=20 >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 From nobody Wed Jun 4 02:06:11 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4F81A0162 for ; Wed, 4 Jun 2014 02:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 kBqsly5l5E0i for ; Wed, 4 Jun 2014 02:06:07 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 4029E1A0159 for ; Wed, 4 Jun 2014 02:06:07 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Ws78t-0003rf-Ic; Wed, 04 Jun 2014 11:05:55 +0200 Received: from dhcp-064120.wlan.ntnu.no ([78.91.64.120]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Ws78s-00033X-HJ; Wed, 04 Jun 2014 11:05:55 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <20140604050204.p5a00h7lusccggw8@webmail.mit.edu> Date: Wed, 4 Jun 2014 11:05:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <241DE014-895E-4A2F-ABF7-0CB406416F65@ifi.uio.no> References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> <20140604050204.p5a00h7lusccggw8@webmail.mit.edu> To: Marie-Jose Montpetit X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 2 sum rcpts/h 11 sum msgs/h 5 total rcpts 17261 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 284325F1643747C18CBFC15D8ACA6BB69EBE0B90 X-UiO-SPAM-Test: remote_host: 78.91.64.120 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 10 max/h 6 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/K8Rt-z21WYO0uMUwZ3Ylw4uaNcs Cc: Brian Trammell , Joe Hildebrand , taps@ietf.org Subject: Re: [Taps] Fwd: So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 09:06:10 -0000 On 4. juni 2014, at 11:02, Marie-Jose Montpetit wrote: > Yes to get more applications developers. >=20 > I do have a problem with "what applicactions want". I think it should = be "what > applications require"? That text is already removed in the most recent version (which uses = Anna's proposal instead). Cheers, Michael > Quoting Brian Trammell : >=20 >> hi Michael, all, >>=20 >> I think the point Joe was trying to make here (please correct me, = Joe) is more that the supply-side does, at some point, need to match up = with services that applications that will actually use. Yes, we're doing = things from the supply-side in TAPS, but we will need participation from = application developers at the _very_ least as a sanity check on the = output of TAPS. >>=20 >> That said, I'm personally happy with Anna's text here, since trying = to draw a boundary around "what applications want" within the charter is = probably a less productive way to do this IMO than just making sure the = app developers are paying attention _during_ discussions of the = milestones on the charter. The IAB "IP Stack Evolution" = program-in-formation (current name is still subject to change, program = scope to be published shortly) will have as one of its goals working = together with the chairs of TAPS and within the WG itself to foster this = cross-area coordination. >>=20 >> Cheers, >>=20 >> Brian >>=20 >> On 04 Jun 2014, at 10:39, Michael Welzl wrote: >>=20 >>> Hi Joe, >>>=20 >>> I think I need you to say on the TAPS list whether you agree with = this or not. >>>=20 >>> It's about this text bit: >>> ""specify a set of transport services that end systems supporting = TAPS >>> need to provide and provide guidance on choosing among available >>> mechanisms and protocols to obtain a given transport service." >>>=20 >>> (below, Anna spoke against your suggested text and suggested this = alternative) >>>=20 >>> My personal opinion: I'd go with Anna's suggestion - this whole = "what do applications want" question is a never-ending story and doesn't = seem to be necessary to me: as Brian called it, we start with the = "support side" here, not the "demand side". TAPS is only the beginning. >>>=20 >>> Cheers, >>> Michael >>>=20 >>>=20 >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: Aaron Falk >>>> Subject: Re: [Taps] So, is this the -00 charter yet? >>>> Date: 3. juni 2014 20:43:16 CEST >>>> To: Michael Welzl >>>> Cc: "taps@ietf.org" >>>>=20 >>>> fine with me >>>>=20 >>>> --aaron >>>>=20 >>>>=20 >>>> On Tue, Jun 3, 2014 at 4:54 AM, Michael Welzl = wrote: >>>> Aaron? Joe? >>>>=20 >>>>=20 >>>> On 3. juni 2014, at 10:46, Gorry Fairhurst = wrote: >>>>=20 >>>> > Sorry, "yes". >>>> > >>>> > Gorry >>>> > >>>> > >>>> > On 03/06/2014 09:17, Michael Welzl wrote: >>>> >> Anna talked about item #2, not item #3 (where no other wording = was proposed I think), so your response is confusing. Try again? >>>> >> >>>> >> Do you agree with Anna's proposed wording for item #2? I do. >>>> >> >>>> >> >>>> >> On 3. juni 2014, at 09:31, gorry@erg.abdn.ac.uk wrote: >>>> >> >>>> >>> My original point was that I did not think this was the piece = about what >>>> >>> applications wanted to use - that I thought was going to be = part of #2, my >>>> >>> thoughts were that #3 related to the transport system working = out what was >>>> >>> actually supported, and the mechanisms (tricks, protocols and = messages to >>>> >>> be exchanged) to complete this process determining a usable = transport. My >>>> >>> view is probably a fairly modular way of looking at the problem = - but it >>>> >>> would allow at least something to be built, and experimentally = deployed - >>>> >>> who knows, if the method works it would achieve the goal. >>>> >>> >>>> >>> That's not to say there isn't a chance for a richer "apps" = interaction, >>>> >>> i'd juts like a focus on what paths *support*. Putting more = over UDP >>>> >>> probably heightens the need to also do the apps part - but UDP = also has >>>> >>> its own set of path issues. My argument is that the TAPS #3 = item needs to >>>> >>> focus on finding a transport that can be used over the path - = if that >>>> >>> can't be fixed, then TAPS can't succeed. >>>> >>> >>>> >>> Gorry >>>> >>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> I do not like "applications want to use". The application = requirements >>>> >>>> give input for the services to specify, but to say that we = should >>>> >>>> specify what applications want to use sounds strange to me. >>>> >>>> >>>> >>>> I think the current formulation is better and more clear. I am = also fine >>>> >>>> with the "implementing TAPS" addition that Aaron suggested. = But as Joe >>>> >>>> did not like "implementing", how about: >>>> >>>> >>>> >>>> "specify a set of transport services that end systems = supporting TAPS >>>> >>>> need to provide and provide guidance on choosing among = available >>>> >>>> mechanisms and protocols to obtain a given transport service." >>>> >>>> >>>> >>>> Anna >>>> >>>> >>>> >>>> >>>> >>>> On 2014-06-03 00:13, Michael Welzl wrote: >>>> >>>>> other opinions? (myself, i'm neutral) >>>> >>>>> >>>> >>>>> Sent from my iPhone >>>> >>>>> >>>> >>>>> On 3. juni 2014, at 00:02, Aaron Falk >>> >>>>> > wrote: >>>> >>>>> >>>> >>>>>> Michael- >>>> >>>>>> >>>> >>>>>> I'm actually OK with Joe's proposed wording: >>>> >>>>>> >>>> >>>>>> On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (jhildebr) >>>> >>>>>> > wrote: >>>> >>>>>> >>>> >>>>>> On 5/30/14, 8:29 AM, "Aaron Falk" >>> >>>>>> > wrote: >>>> >>>>>> >>>> >>>>>>> My proposed wording change (which at least Gorry accepted) = is >>>> >>>>>> not in the >>>> >>>>>>> current draft. Repeating: >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> Revise working group goal #2 to read "specify a set of = transport >>>> >>>>>> services >>>> >>>>>>> that end systems **implementing TAPS** need to provide and = provide >>>> >>>>>>> guidance on choosing among available mechanisms and = protocols to >>>> >>>>>> obtain a >>>> >>>>>>> given transport service." >>>> >>>>>> >>>> >>>>>> There's no protocol for TAPS yet, so nobody is going to >>>> >>>>>> "implement TAPS". >>>> >>>>>> Suggested change: "end systems need to provide" -> = "applications >>>> >>>>>> want to >>>> >>>>>> use". >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> It allows the wg more flexibility which is probably = appropriate in >>>> >>>>>> this stage. >>>> >>>>>> >>>> >>>>>> --aaron >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl = >>> >>>>>> > wrote: >>>> >>>>>> >>>> >>>>>> Hi! >>>> >>>>>> >>>> >>>>>> Spencer, thank you very much for this update. Much = appreciated! >>>> >>>>>> >>>> >>>>>> Regarding the charter bit, let's try to figure out what >>>> >>>>>> specifically is needed. Here's the link to the >>>> >>>>>> always-most-up-to-date version: >>>> >>>>>> = https://sites.google.com/site/transportprotocolservices/charter-proposal >>>> >>>>>> >>>> >>>>>> You wrote: >>>> >>>>>> >>>> >>>>>>> I'd like to see an updated charter proposal that = reflects recent >>>> >>>>>>> mailing list discussion, including dropping the = specifics about >>>> >>>>>>> document category, so that the folks on the mailing list = can >>>> >>>>>>> check whether their concerns have been addressed. >>>> >>>>>> >>>> >>>>>> What exactly do you mean with "dropping the specifics = about >>>> >>>>>> document category" - is the suggestion to change WG goal = #1, >>>> >>>>>> which now reads: >>>> >>>>>> "identify services provided by existing IETF transport = protocols >>>> >>>>>> and congestion control mechanisms, based on = Standards-track and >>>> >>>>>> Experimental RFCs." >>>> >>>>>> to >>>> >>>>>> ""identify services provided by existing IETF transport = protocols >>>> >>>>>> and congestion control mechanisms" ? >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> For other changes, I'll try to recap the current state; = please, >>>> >>>>>> all, if you feel I'm misrepresenting things, 1) it's = definitely >>>> >>>>>> not intentionally, 2) by all means correct me! >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> The way I see it, we have 2 issues to discuss. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> ISSUE 1: >>>> >>>>>> ------------ >>>> >>>>>> >>>> >>>>>> We had some consensus on the charter as it currently = stands; >>>> >>>>>> then, there was the comment by Aaron about a small = wording change >>>> >>>>>> that I had missed, in WG goal #2, which currently reads: >>>> >>>>>> >>>> >>>>>> "specify a set of transport services that end systems = need to >>>> >>>>>> provide and provide guidance on choosing among available >>>> >>>>>> mechanisms and protocols to obtain a given transport = service." >>>> >>>>>> >>>> >>>>>> Joe spoke against Aaron's change and offered an = alternative >>>> >>>>>> proposal, which again Gorry didn't like, saying that it = seems to >>>> >>>>>> him to be a big change in what he's seen on the list. >>>> >>>>>> >>>> >>>>>> My question at this point is: can we keep the original = text of >>>> >>>>>> goal #2 as I quote it here, or does anybody have yet = another >>>> >>>>>> proposal that we all can live with? >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> ISSUE 2: >>>> >>>>>> ------------ >>>> >>>>>> >>>> >>>>>> There were some arguments about the need for WG goal #3, >>>> >>>>>> mechanisms to discover the availability of protocols... = - and >>>> >>>>>> it seems that several of us want to keep it. Can we (with = the >>>> >>>>>> current text), or do we need to discuss this more? >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Any other issues? Shoot, all :-) >>>> >>>>>> >>>> >>>>>> Cheers, >>>> >>>>>> Michael >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> 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 >>>> >> >>>> > >>>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>>=20 >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >>=20 >=20 >=20 From nobody Wed Jun 4 02:08:06 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8581A0132 for ; Wed, 4 Jun 2014 02:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 WeY7nN9Uje5F for ; Wed, 4 Jun 2014 02:08:02 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0C31A0126 for ; Wed, 4 Jun 2014 02:08:01 -0700 (PDT) Received: from [IPv6:2001:67c:10ec:2a49:8000::8] (unknown [IPv6:2001:67c:10ec:2a49:8000::8]) by trammell.ch (Postfix) with ESMTPSA id CC7151A0A43; Wed, 4 Jun 2014 11:07:54 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_8EB8D805-3132-4769-BE0E-A136386AE3B5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Brian Trammell In-Reply-To: <20140604050204.p5a00h7lusccggw8@webmail.mit.edu> Date: Wed, 4 Jun 2014 11:07:55 +0200 Message-Id: References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> <20140604050204.p5a00h7lusccggw8@webmail.mit.edu> To: Marie-Jose Montpetit X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/9y2gLg6uYrFya6ibvO0gbuYwYtc Cc: Joe Hildebrand , Michael Welzl , taps@ietf.org Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 09:08:05 -0000 --Apple-Mail=_8EB8D805-3132-4769-BE0E-A136386AE3B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 04 Jun 2014, at 11:02, Marie-Jose Montpetit wrote: > Yes to get more applications developers. >=20 > I do have a problem with "what applicactions want". I think it should = be "what > applications require"? (This is a bit of a side conversation, because I think it's okay to = remove mention of application requirements from the charter = altogether... but...) There's a little bit of a mismatch between the demand- and supply-side = here; applications have requirements and will do what is necessary with = available transports to meet those requirements. Usually this means they = use some API provided by their platform that somewhere along the line = maps down to something-over-TCP (XmlHttpSocket, for example). Sometimes = this means application developers roll their own transports over UDP = (QUIC, Mosh).=20 Given this pragmatism, there is, I think, value in providing services = from the transport layer that the application development community = doesn't know it needs yet. Simply reacting to requirements expressed in = terms of the present situation is unlikely to lead to much innovation. = :) Cheers, Brian > Quoting Brian Trammell : >=20 >> hi Michael, all, >>=20 >> I think the point Joe was trying to make here (please correct me, = Joe) is more that the supply-side does, at some point, need to match up = with services that applications that will actually use. Yes, we're doing = things from the supply-side in TAPS, but we will need participation from = application developers at the _very_ least as a sanity check on the = output of TAPS. >>=20 >> That said, I'm personally happy with Anna's text here, since trying = to draw a boundary around "what applications want" within the charter is = probably a less productive way to do this IMO than just making sure the = app developers are paying attention _during_ discussions of the = milestones on the charter. The IAB "IP Stack Evolution" = program-in-formation (current name is still subject to change, program = scope to be published shortly) will have as one of its goals working = together with the chairs of TAPS and within the WG itself to foster this = cross-area coordination. >>=20 >> Cheers, >>=20 >> Brian >>=20 >> On 04 Jun 2014, at 10:39, Michael Welzl wrote: >>=20 >>> Hi Joe, >>>=20 >>> I think I need you to say on the TAPS list whether you agree with = this or not. >>>=20 >>> It's about this text bit: >>> ""specify a set of transport services that end systems supporting = TAPS >>> need to provide and provide guidance on choosing among available >>> mechanisms and protocols to obtain a given transport service." >>>=20 >>> (below, Anna spoke against your suggested text and suggested this = alternative) >>>=20 >>> My personal opinion: I'd go with Anna's suggestion - this whole = "what do applications want" question is a never-ending story and doesn't = seem to be necessary to me: as Brian called it, we start with the = "support side" here, not the "demand side". TAPS is only the beginning. >>>=20 >>> Cheers, >>> Michael >>>=20 >>>=20 >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: Aaron Falk >>>> Subject: Re: [Taps] So, is this the -00 charter yet? >>>> Date: 3. juni 2014 20:43:16 CEST >>>> To: Michael Welzl >>>> Cc: "taps@ietf.org" >>>>=20 >>>> fine with me >>>>=20 >>>> --aaron >>>>=20 >>>>=20 >>>> On Tue, Jun 3, 2014 at 4:54 AM, Michael Welzl = wrote: >>>> Aaron? Joe? >>>>=20 >>>>=20 >>>> On 3. juni 2014, at 10:46, Gorry Fairhurst = wrote: >>>>=20 >>>> > Sorry, "yes". >>>> > >>>> > Gorry >>>> > >>>> > >>>> > On 03/06/2014 09:17, Michael Welzl wrote: >>>> >> Anna talked about item #2, not item #3 (where no other wording = was proposed I think), so your response is confusing. Try again? >>>> >> >>>> >> Do you agree with Anna's proposed wording for item #2? I do. >>>> >> >>>> >> >>>> >> On 3. juni 2014, at 09:31, gorry@erg.abdn.ac.uk wrote: >>>> >> >>>> >>> My original point was that I did not think this was the piece = about what >>>> >>> applications wanted to use - that I thought was going to be = part of #2, my >>>> >>> thoughts were that #3 related to the transport system working = out what was >>>> >>> actually supported, and the mechanisms (tricks, protocols and = messages to >>>> >>> be exchanged) to complete this process determining a usable = transport. My >>>> >>> view is probably a fairly modular way of looking at the problem = - but it >>>> >>> would allow at least something to be built, and experimentally = deployed - >>>> >>> who knows, if the method works it would achieve the goal. >>>> >>> >>>> >>> That's not to say there isn't a chance for a richer "apps" = interaction, >>>> >>> i'd juts like a focus on what paths *support*. Putting more = over UDP >>>> >>> probably heightens the need to also do the apps part - but UDP = also has >>>> >>> its own set of path issues. My argument is that the TAPS #3 = item needs to >>>> >>> focus on finding a transport that can be used over the path - = if that >>>> >>> can't be fixed, then TAPS can't succeed. >>>> >>> >>>> >>> Gorry >>>> >>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> I do not like "applications want to use". The application = requirements >>>> >>>> give input for the services to specify, but to say that we = should >>>> >>>> specify what applications want to use sounds strange to me. >>>> >>>> >>>> >>>> I think the current formulation is better and more clear. I am = also fine >>>> >>>> with the "implementing TAPS" addition that Aaron suggested. = But as Joe >>>> >>>> did not like "implementing", how about: >>>> >>>> >>>> >>>> "specify a set of transport services that end systems = supporting TAPS >>>> >>>> need to provide and provide guidance on choosing among = available >>>> >>>> mechanisms and protocols to obtain a given transport service." >>>> >>>> >>>> >>>> Anna >>>> >>>> >>>> >>>> >>>> >>>> On 2014-06-03 00:13, Michael Welzl wrote: >>>> >>>>> other opinions? (myself, i'm neutral) >>>> >>>>> >>>> >>>>> Sent from my iPhone >>>> >>>>> >>>> >>>>> On 3. juni 2014, at 00:02, Aaron Falk >>> >>>>> > wrote: >>>> >>>>> >>>> >>>>>> Michael- >>>> >>>>>> >>>> >>>>>> I'm actually OK with Joe's proposed wording: >>>> >>>>>> >>>> >>>>>> On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (jhildebr) >>>> >>>>>> > wrote: >>>> >>>>>> >>>> >>>>>> On 5/30/14, 8:29 AM, "Aaron Falk" >>> >>>>>> > wrote: >>>> >>>>>> >>>> >>>>>>> My proposed wording change (which at least Gorry accepted) = is >>>> >>>>>> not in the >>>> >>>>>>> current draft. Repeating: >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> Revise working group goal #2 to read "specify a set of = transport >>>> >>>>>> services >>>> >>>>>>> that end systems **implementing TAPS** need to provide and = provide >>>> >>>>>>> guidance on choosing among available mechanisms and = protocols to >>>> >>>>>> obtain a >>>> >>>>>>> given transport service." >>>> >>>>>> >>>> >>>>>> There's no protocol for TAPS yet, so nobody is going to >>>> >>>>>> "implement TAPS". >>>> >>>>>> Suggested change: "end systems need to provide" -> = "applications >>>> >>>>>> want to >>>> >>>>>> use". >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> It allows the wg more flexibility which is probably = appropriate in >>>> >>>>>> this stage. >>>> >>>>>> >>>> >>>>>> --aaron >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl = >>> >>>>>> > wrote: >>>> >>>>>> >>>> >>>>>> Hi! >>>> >>>>>> >>>> >>>>>> Spencer, thank you very much for this update. Much = appreciated! >>>> >>>>>> >>>> >>>>>> Regarding the charter bit, let's try to figure out what >>>> >>>>>> specifically is needed. Here's the link to the >>>> >>>>>> always-most-up-to-date version: >>>> >>>>>> = https://sites.google.com/site/transportprotocolservices/charter-proposal >>>> >>>>>> >>>> >>>>>> You wrote: >>>> >>>>>> >>>> >>>>>>> I'd like to see an updated charter proposal that = reflects recent >>>> >>>>>>> mailing list discussion, including dropping the = specifics about >>>> >>>>>>> document category, so that the folks on the mailing list = can >>>> >>>>>>> check whether their concerns have been addressed. >>>> >>>>>> >>>> >>>>>> What exactly do you mean with "dropping the specifics = about >>>> >>>>>> document category" - is the suggestion to change WG goal = #1, >>>> >>>>>> which now reads: >>>> >>>>>> "identify services provided by existing IETF transport = protocols >>>> >>>>>> and congestion control mechanisms, based on = Standards-track and >>>> >>>>>> Experimental RFCs." >>>> >>>>>> to >>>> >>>>>> ""identify services provided by existing IETF transport = protocols >>>> >>>>>> and congestion control mechanisms" ? >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> For other changes, I'll try to recap the current state; = please, >>>> >>>>>> all, if you feel I'm misrepresenting things, 1) it's = definitely >>>> >>>>>> not intentionally, 2) by all means correct me! >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> The way I see it, we have 2 issues to discuss. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> ISSUE 1: >>>> >>>>>> ------------ >>>> >>>>>> >>>> >>>>>> We had some consensus on the charter as it currently = stands; >>>> >>>>>> then, there was the comment by Aaron about a small = wording change >>>> >>>>>> that I had missed, in WG goal #2, which currently reads: >>>> >>>>>> >>>> >>>>>> "specify a set of transport services that end systems = need to >>>> >>>>>> provide and provide guidance on choosing among available >>>> >>>>>> mechanisms and protocols to obtain a given transport = service." >>>> >>>>>> >>>> >>>>>> Joe spoke against Aaron's change and offered an = alternative >>>> >>>>>> proposal, which again Gorry didn't like, saying that it = seems to >>>> >>>>>> him to be a big change in what he's seen on the list. >>>> >>>>>> >>>> >>>>>> My question at this point is: can we keep the original = text of >>>> >>>>>> goal #2 as I quote it here, or does anybody have yet = another >>>> >>>>>> proposal that we all can live with? >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> ISSUE 2: >>>> >>>>>> ------------ >>>> >>>>>> >>>> >>>>>> There were some arguments about the need for WG goal #3, >>>> >>>>>> mechanisms to discover the availability of protocols... = - and >>>> >>>>>> it seems that several of us want to keep it. Can we (with = the >>>> >>>>>> current text), or do we need to discuss this more? >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Any other issues? Shoot, all :-) >>>> >>>>>> >>>> >>>>>> Cheers, >>>> >>>>>> Michael >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> 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 >>>> >> >>>> > >>>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>>=20 >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >>=20 >=20 >=20 --Apple-Mail=_8EB8D805-3132-4769-BE0E-A136386AE3B5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTjuHrAAoJENt3nsOmbNJcKNYIAKtsbyhj6ZSKTNrqMKwtSECF 3ki+od09b44qka0tDbYrkDh1FXX064HrF+eEeAfrruuAq5rZytFyWj6enYjNTYor OhwwveumjogDlV3P4eQxNCiO4PqS6577GzmhjVFZmfRyOuvWlIuI4mtbTNs0buuz 5Ciyq8mn3IxHA5jHWacRBtFIj3Lwq3c6rsMfPl3GjKhSRegk3+F3hWtDK6+lwBmL 3iOHlEpeQKOhpNS0UiKcK5P/yXwubJMEX2oz9zV/Yip9rmBZE8EvkBfQD3wwNLYO bqDzGjH9uyvRz2IxnvTRQo4Q+pgEe+rgasO+sIk9QDqhq5DPE6Gov7MxW7iAQIc= =zPWl -----END PGP SIGNATURE----- --Apple-Mail=_8EB8D805-3132-4769-BE0E-A136386AE3B5-- From nobody Wed Jun 4 08:51:31 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08621A0227 for ; Wed, 4 Jun 2014 08:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 ZIgDASoVur_I for ; Wed, 4 Jun 2014 08:51:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A97F31A02DA for ; Wed, 4 Jun 2014 08:51:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHV49519; Wed, 04 Jun 2014 15:51:05 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Jun 2014 16:50:16 +0100 Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 4 Jun 2014 16:51:04 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml704-chm.china.huawei.com ([169.254.6.5]) with mapi id 14.03.0158.001; Wed, 4 Jun 2014 08:50:57 -0700 From: Linda Dunbar To: Brian Trammell , Marie-Jose Montpetit Thread-Topic: [Taps] So, is this the -00 charter yet? Thread-Index: AQHPf9SJF25u7WSxu0KQdH9XkzfQapthGFAA Date: Wed, 4 Jun 2014 15:50:56 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D2DE6D@dfweml701-chm.china.huawei.com> References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> <20140604050204.p5a00h7lusccggw8@webmail.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.155.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/taps/K0n2pHfUkFexIhgvTsFMtZ1gvZM Cc: Michael Welzl , Joe Hildebrand , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 15:51:25 -0000 All the transport protocols listed in the first paragraph are protocols bet= ween applications (SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT).=20 With layers of layers aggregations (or tunnels) in today's network, the hos= ts (applications) level transport layers information get buried. That means= those application level transport protocols are not visible to network ele= ments. Therefore, the gained benefits are very limited even with relentless= effort (of IETF) to fine tune the transport protocols between applications= .=20 It is much more effective to have transport protocols between applications = <-> networks. =20 Therefore, I am suggesting following wording changes to the charter descrip= tion: -------------------------------- Description of Working Group Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and the= LEDBAT congestion control mechanism extend the number of transport service= s to applications in addition to the long-standing two services provided by= TCP and UDP. All those transport protocols are protocols between hosts (o= r applications).=20 With layers of layers aggregations (or tunnels) in today's network, the hos= ts (applications) level transport layers information get buried. That means= those application level transport protocols are not visible to network ele= ments. Therefore, the gained benefits are very limited even with relentless= effort to fine tune the transport protocols between applications.=20 It is much more effective to have transport protocols between applications = <-> networks. =20 For an application programmer, it is hard to use protocols other than TCP o= r UDP: not all protocols are available everywhere, hence a fall-back soluti= on to e.g. TCP or UDP must be implemented. Some protocols provide the same = services in different ways. Layering decisions must be made (e.g. should a = protocol be used natively or over UDP?). Because of these complications, pr= ogrammers often resort to either using TCP or implementing their own custom= ized solution over UDP, and chances of benefiting from other transport prot= ocols are lost. There are many ways in which this problem could be addressed; while it may = not yet be clear what the best way forward could be, any approach to provid= e a richer set of transport services to applications will have to begin wit= h the identification of the services that current transport protocols provi= de. Linda Dunbar -----Original Message----- From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Brian Trammell Sent: Wednesday, June 04, 2014 4:08 AM To: Marie-Jose Montpetit Cc: Joe Hildebrand; Michael Welzl; taps@ietf.org Subject: Re: [Taps] So, is this the -00 charter yet? On 04 Jun 2014, at 11:02, Marie-Jose Montpetit wrote: > Yes to get more applications developers. >=20 > I do have a problem with "what applicactions want". I think it should=20 > be "what applications require"? (This is a bit of a side conversation, because I think it's okay to remove = mention of application requirements from the charter altogether... but...) There's a little bit of a mismatch between the demand- and supply-side here= ; applications have requirements and will do what is necessary with availab= le transports to meet those requirements. Usually this means they use some = API provided by their platform that somewhere along the line maps down to s= omething-over-TCP (XmlHttpSocket, for example). Sometimes this means applic= ation developers roll their own transports over UDP (QUIC, Mosh).=20 Given this pragmatism, there is, I think, value in providing services from = the transport layer that the application development community doesn't know= it needs yet. Simply reacting to requirements expressed in terms of the pr= esent situation is unlikely to lead to much innovation. :) Cheers, Brian > Quoting Brian Trammell : >=20 >> hi Michael, all, >>=20 >> I think the point Joe was trying to make here (please correct me, Joe) i= s more that the supply-side does, at some point, need to match up with serv= ices that applications that will actually use. Yes, we're doing things from= the supply-side in TAPS, but we will need participation from application d= evelopers at the _very_ least as a sanity check on the output of TAPS. >>=20 >> That said, I'm personally happy with Anna's text here, since trying to d= raw a boundary around "what applications want" within the charter is probab= ly a less productive way to do this IMO than just making sure the app devel= opers are paying attention _during_ discussions of the milestones on the ch= arter. The IAB "IP Stack Evolution" program-in-formation (current name is s= till subject to change, program scope to be published shortly) will have as= one of its goals working together with the chairs of TAPS and within the W= G itself to foster this cross-area coordination. >>=20 >> Cheers, >>=20 >> Brian >>=20 >> On 04 Jun 2014, at 10:39, Michael Welzl wrote: >>=20 >>> Hi Joe, >>>=20 >>> I think I need you to say on the TAPS list whether you agree with this = or not. >>>=20 >>> It's about this text bit: >>> ""specify a set of transport services that end systems supporting=20 >>> TAPS need to provide and provide guidance on choosing among=20 >>> available mechanisms and protocols to obtain a given transport service.= " >>>=20 >>> (below, Anna spoke against your suggested text and suggested this=20 >>> alternative) >>>=20 >>> My personal opinion: I'd go with Anna's suggestion - this whole "what d= o applications want" question is a never-ending story and doesn't seem to b= e necessary to me: as Brian called it, we start with the "support side" her= e, not the "demand side". TAPS is only the beginning. >>>=20 >>> Cheers, >>> Michael >>>=20 >>>=20 >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: Aaron Falk >>>> Subject: Re: [Taps] So, is this the -00 charter yet? >>>> Date: 3. juni 2014 20:43:16 CEST >>>> To: Michael Welzl >>>> Cc: "taps@ietf.org" >>>>=20 >>>> fine with me >>>>=20 >>>> --aaron >>>>=20 >>>>=20 >>>> On Tue, Jun 3, 2014 at 4:54 AM, Michael Welzl wro= te: >>>> Aaron? Joe? >>>>=20 >>>>=20 >>>> On 3. juni 2014, at 10:46, Gorry Fairhurst wrot= e: >>>>=20 >>>> > Sorry, "yes". >>>> > >>>> > Gorry >>>> > >>>> > >>>> > On 03/06/2014 09:17, Michael Welzl wrote: >>>> >> Anna talked about item #2, not item #3 (where no other wording was = proposed I think), so your response is confusing. Try again? >>>> >> >>>> >> Do you agree with Anna's proposed wording for item #2? I do. >>>> >> >>>> >> >>>> >> On 3. juni 2014, at 09:31, gorry@erg.abdn.ac.uk wrote: >>>> >> >>>> >>> My original point was that I did not think this was the piece=20 >>>> >>> about what applications wanted to use - that I thought was=20 >>>> >>> going to be part of #2, my thoughts were that #3 related to the=20 >>>> >>> transport system working out what was actually supported, and=20 >>>> >>> the mechanisms (tricks, protocols and messages to be exchanged)=20 >>>> >>> to complete this process determining a usable transport. My=20 >>>> >>> view is probably a fairly modular way of looking at the problem=20 >>>> >>> - but it would allow at least something to be built, and experimen= tally deployed - who knows, if the method works it would achieve the goal. >>>> >>> >>>> >>> That's not to say there isn't a chance for a richer "apps"=20 >>>> >>> interaction, i'd juts like a focus on what paths *support*. =20 >>>> >>> Putting more over UDP probably heightens the need to also do=20 >>>> >>> the apps part - but UDP also has its own set of path issues. My=20 >>>> >>> argument is that the TAPS #3 item needs to focus on finding a=20 >>>> >>> transport that can be used over the path - if that can't be fixed,= then TAPS can't succeed. >>>> >>> >>>> >>> Gorry >>>> >>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> I do not like "applications want to use". The application=20 >>>> >>>> requirements give input for the services to specify, but to=20 >>>> >>>> say that we should specify what applications want to use sounds s= trange to me. >>>> >>>> >>>> >>>> I think the current formulation is better and more clear. I am=20 >>>> >>>> also fine with the "implementing TAPS" addition that Aaron=20 >>>> >>>> suggested. But as Joe did not like "implementing", how about: >>>> >>>> >>>> >>>> "specify a set of transport services that end systems=20 >>>> >>>> supporting TAPS need to provide and provide guidance on=20 >>>> >>>> choosing among available mechanisms and protocols to obtain a giv= en transport service." >>>> >>>> >>>> >>>> Anna >>>> >>>> >>>> >>>> >>>> >>>> On 2014-06-03 00:13, Michael Welzl wrote: >>>> >>>>> other opinions? (myself, i'm neutral) >>>> >>>>> >>>> >>>>> Sent from my iPhone >>>> >>>>> >>>> >>>>> On 3. juni 2014, at 00:02, Aaron Falk >>> >>>>> > wrote: >>>> >>>>> >>>> >>>>>> Michael- >>>> >>>>>> >>>> >>>>>> I'm actually OK with Joe's proposed wording: >>>> >>>>>> >>>> >>>>>> On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (jhildebr)=20 >>>> >>>>>> > wrote: >>>> >>>>>> >>>> >>>>>> On 5/30/14, 8:29 AM, "Aaron Falk" >>> >>>>>> > wrote: >>>> >>>>>> >>>> >>>>>>> My proposed wording change (which at least Gorry accepted)=20 >>>> >>>>>>> is >>>> >>>>>> not in the >>>> >>>>>>> current draft. Repeating: >>>> >>>>>>> >>>> >>>>>>> >>>> >>>>>>> Revise working group goal #2 to read "specify a set of=20 >>>> >>>>>>> transport >>>> >>>>>> services >>>> >>>>>>> that end systems **implementing TAPS** need to provide and=20 >>>> >>>>>>> provide guidance on choosing among available mechanisms and=20 >>>> >>>>>>> protocols to >>>> >>>>>> obtain a >>>> >>>>>>> given transport service." >>>> >>>>>> >>>> >>>>>> There's no protocol for TAPS yet, so nobody is going to >>>> >>>>>> "implement TAPS". >>>> >>>>>> Suggested change: "end systems need to provide" -> "applicat= ions >>>> >>>>>> want to >>>> >>>>>> use". >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> It allows the wg more flexibility which is probably=20 >>>> >>>>>> appropriate in this stage. >>>> >>>>>> >>>> >>>>>> --aaron >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl=20 >>>> >>>>>> > wrote: >>>> >>>>>> >>>> >>>>>> Hi! >>>> >>>>>> >>>> >>>>>> Spencer, thank you very much for this update. Much appreciat= ed! >>>> >>>>>> >>>> >>>>>> Regarding the charter bit, let's try to figure out what >>>> >>>>>> specifically is needed. Here's the link to the >>>> >>>>>> always-most-up-to-date version: >>>> >>>>>> =20 >>>> >>>>>> https://sites.google.com/site/transportprotocolservices/char >>>> >>>>>> ter-proposal >>>> >>>>>> >>>> >>>>>> You wrote: >>>> >>>>>> >>>> >>>>>>> I'd like to see an updated charter proposal that reflects r= ecent >>>> >>>>>>> mailing list discussion, including dropping the specifics a= bout >>>> >>>>>>> document category, so that the folks on the mailing list ca= n >>>> >>>>>>> check whether their concerns have been addressed. >>>> >>>>>> >>>> >>>>>> What exactly do you mean with "dropping the specifics about >>>> >>>>>> document category" - is the suggestion to change WG goal #1, >>>> >>>>>> which now reads: >>>> >>>>>> "identify services provided by existing IETF transport proto= cols >>>> >>>>>> and congestion control mechanisms, based on Standards-track = and >>>> >>>>>> Experimental RFCs." >>>> >>>>>> to >>>> >>>>>> ""identify services provided by existing IETF transport prot= ocols >>>> >>>>>> and congestion control mechanisms" ? >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> For other changes, I'll try to recap the current state; plea= se, >>>> >>>>>> all, if you feel I'm misrepresenting things, 1) it's definit= ely >>>> >>>>>> not intentionally, 2) by all means correct me! >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> The way I see it, we have 2 issues to discuss. >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> ISSUE 1: >>>> >>>>>> ------------ >>>> >>>>>> >>>> >>>>>> We had some consensus on the charter as it currently stands; >>>> >>>>>> then, there was the comment by Aaron about a small wording c= hange >>>> >>>>>> that I had missed, in WG goal #2, which currently reads: >>>> >>>>>> >>>> >>>>>> "specify a set of transport services that end systems need t= o >>>> >>>>>> provide and provide guidance on choosing among available >>>> >>>>>> mechanisms and protocols to obtain a given transport service= ." >>>> >>>>>> >>>> >>>>>> Joe spoke against Aaron's change and offered an alternative >>>> >>>>>> proposal, which again Gorry didn't like, saying that it seem= s to >>>> >>>>>> him to be a big change in what he's seen on the list. >>>> >>>>>> >>>> >>>>>> My question at this point is: can we keep the original text = of >>>> >>>>>> goal #2 as I quote it here, or does anybody have yet another >>>> >>>>>> proposal that we all can live with? >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> ISSUE 2: >>>> >>>>>> ------------ >>>> >>>>>> >>>> >>>>>> There were some arguments about the need for WG goal #3, >>>> >>>>>> mechanisms to discover the availability of protocols... - = and >>>> >>>>>> it seems that several of us want to keep it. Can we (with th= e >>>> >>>>>> current text), or do we need to discuss this more? >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> Any other issues? Shoot, all :-) >>>> >>>>>> >>>> >>>>>> Cheers, >>>> >>>>>> Michael >>>> >>>>>> >>>> >>>>>> >>>> >>>>>> _______________________________________________ >>>> >>>>>> 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 >>>> >> >>>> > >>>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>>=20 >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >>=20 >=20 >=20 From nobody Wed Jun 4 09:13:56 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4169B1A0270 for ; Wed, 4 Jun 2014 09:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 xUSqXPzsDI_u for ; Wed, 4 Jun 2014 09:13:52 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D7681A03BA for ; Wed, 4 Jun 2014 09:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13672; q=dns/txt; s=iport; t=1401898422; x=1403108022; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=D+PRui50atEl7mNlBf5gaJJhLc6M+sgv9JvfgygaGc8=; b=TM6R7F2uQ+f463cqvN5UMk/U6jO3hk97j9UIwoLYdMQ+6scxuVSF1TbJ TRQfeHNkBSDGm0OUOyVGdCUVgXo7ubIFw6ZBrKqFV0J7kRdANme1jlqpO 54r4bsovqtWYWYEAFStE/2H7O55SMLbY+UGIWzUNGhs68Wmoly+DFRZk3 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskLACNFj1OtJA2F/2dsb2JhbABPCoMHUliCbKdWAQEBAQEFAZBuhzkBGXMWdIIlAQEBBAEBASAEDToGBRACAQgOAwMBAgECAiMDAgICJQsUAQgIAgQOBYhCDawzpW8TBIEqhCuIISkYGwcGgm+BSwEDhGAClTGTOYM4gi8 X-IronPort-AV: E=Sophos;i="4.98,973,1392163200"; d="scan'208";a="330534664" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-3.cisco.com with ESMTP; 04 Jun 2014 16:13:40 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s54GDefn020392 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Jun 2014 16:13:40 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Wed, 4 Jun 2014 11:13:40 -0500 From: "Joe Hildebrand (jhildebr)" To: Michael Welzl Thread-Topic: [Taps] So, is this the -00 charter yet? Thread-Index: AQHPe5Sc/jue/Kq5GUeSg8bXP9PSQJtZN92AgABpiID//53yAIAAafGA//+cGACAALipAIAD2R+AgAB2JoCAAFr0gIAADNsAgAAEQYCAAALvgIAACMOAgACTK4CAAA0NAIAAB/2AgAACHYCAAKSjAIAAldZCgABuGYA= Date: Wed, 4 Jun 2014 16:13:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.2.140509 x-originating-ip: [10.21.66.169] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/L381U94XPBhCG_ywB4Z9JRBKYM0 Cc: "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 16:13:54 -0000 SSB3b24ndCBzdGFuZCBpbiB0aGUgd2F5IG9mIHRoYXQgdGV4dCwgYnV0IEknbGwgcmVwZWF0IGZv ciB0aGUgZm9sa3MgdGhhdA0KaGF2ZW4ndCBoZWFyZCBtZSBzYXkgdGhpczoNCg0KSWYgdGhlIFRB UFMgd2cgZG9lc24ndCBoYXZlIGFkZXF1YXRlIHJlcHJlc2VudGF0aW9uIGZyb20gdGhlIGFwcGxp Y2F0aW9uDQpsYXllciBmb2xrcywgeW91IHdpbGwgcHJvZHVjZSBzb21ldGhpbmcgdGhhdCB3b24n dCBiZSBjb25zdW1lZC4gIFNheWluZw0KdGhpbmdzIGxpa2UgIndlJ3JlIGp1c3QgdGhlIHN1cHBv cnQgc2lkZSIgaXMgbGlhYmxlIHRvIG1ha2UgdGhlDQphcHBzLWZvY3VzZWQgcGVvcGxlIGFzc3Vt ZSB0aGF0IHRoaXMgaXMgeWV0IGFub3RoZXIgVFNWIHRoaW5nIHRoZXkgY2FuDQpzYWZlbHkgaWdu b3JlLg0KDQoiV2hhdCBhcHBzIHdhbnQiIGlzICpub3QqIGFuIHVuZW5kaW5nIHN0b3J5LiAgVGhl eSB3YW50IHRvIGJlIGFibGUgdG8NCmRlcGxveSBzb21ldGhpbmcgbW9yZSBmbGV4aWJsZSB0aGFu IFRDUCBvbiB0b3Agb2YgdG9kYXkncyBJbnRlcm5ldCwNCndpdGhvdXQgcmVxdWlyaW5nIGV2ZXJ5 b25lIHRvIHVwZGF0ZSB0aGVpciBPUyBrZXJuZWxzLCBhbmQgd2l0aG91dA0KcmVxdWlyaW5nIGFk bWluaXN0cmF0b3IgcHJpdmlsZWdlcyBhdCBhbnkgcG9pbnQuICBUcmVhdGluZyB0aGF0IHNldCBv Zg0KcmVxdWlyZW1lbnRzIGFzIHJvY2tldCBzY2llbmNlIHdvbid0IGhlbHAgeW91ciBvdXRwdXQg dG8gZ2V0IGRlcGxveWVkLg0KDQoNCk9uIDYvNC8xNCwgMjozOSBBTSwgIk1pY2hhZWwgV2Vsemwi IDxtaWNoYXdlQGlmaS51aW8ubm8+IHdyb3RlOg0KDQo+SGkgSm9lLA0KPg0KPg0KPkkgdGhpbmsg SSBuZWVkIHlvdSB0byBzYXkgb24gdGhlIFRBUFMgbGlzdCB3aGV0aGVyIHlvdSBhZ3JlZSB3aXRo IHRoaXMgb3INCj5ub3QuDQo+DQo+DQo+SXQncyBhYm91dCB0aGlzIHRleHQgYml0Og0KPiIic3Bl Y2lmeSBhIHNldCBvZiB0cmFuc3BvcnQgc2VydmljZXMgdGhhdCBlbmQgc3lzdGVtcyBzdXBwb3J0 aW5nIFRBUFMNCj5uZWVkIHRvIHByb3ZpZGUgYW5kIHByb3ZpZGUgZ3VpZGFuY2Ugb24gY2hvb3Np bmcgYW1vbmcgYXZhaWxhYmxlDQo+bWVjaGFuaXNtcyBhbmQgcHJvdG9jb2xzIHRvIG9idGFpbiBh IGdpdmVuIHRyYW5zcG9ydCBzZXJ2aWNlLiINCj4NCj4NCj4oYmVsb3csIEFubmEgc3Bva2UgYWdh aW5zdCB5b3VyIHN1Z2dlc3RlZCB0ZXh0IGFuZCBzdWdnZXN0ZWQgdGhpcw0KPmFsdGVybmF0aXZl KQ0KPg0KPg0KPk15IHBlcnNvbmFsIG9waW5pb246IEknZCBnbyB3aXRoIEFubmEncyBzdWdnZXN0 aW9uIC0gdGhpcyB3aG9sZSAid2hhdCBkbw0KPmFwcGxpY2F0aW9ucyB3YW50IiBxdWVzdGlvbiBp cyBhIG5ldmVyLWVuZGluZyBzdG9yeSBhbmQgZG9lc24ndCBzZWVtIHRvDQo+YmUgbmVjZXNzYXJ5 IHRvIG1lOiBhcyBCcmlhbiBjYWxsZWQgaXQsIHdlIHN0YXJ0IHdpdGggdGhlICJzdXBwb3J0IHNp ZGUiDQo+aGVyZSwgbm90IHRoZSAiZGVtYW5kIHNpZGUiLiBUQVBTDQo+IGlzIG9ubHkgdGhlIGJl Z2lubmluZy4NCj4NCj4NCj5DaGVlcnMsDQo+TWljaGFlbA0KPg0KPg0KPg0KPg0KPg0KPkJlZ2lu IGZvcndhcmRlZCBtZXNzYWdlOg0KPg0KPg0KPkZyb206IEFhcm9uIEZhbGsgPGZhbGstaWV0ZkBk Z2Z0ZWNoLmNvbT4NCj4NCj5TdWJqZWN0OiBSZTogW1RhcHNdIFNvLCBpcyB0aGlzIHRoZSAtMDAg Y2hhcnRlciB5ZXQ/DQo+DQo+RGF0ZTogMy4ganVuaSAyMDE0IDIwOjQzOjE2IENFU1QNCj4NCj5U bzogTWljaGFlbCBXZWx6bCA8bWljaGF3ZUBpZmkudWlvLm5vPg0KPg0KPkNjOiAidGFwc0BpZXRm Lm9yZyIgPHRhcHNAaWV0Zi5vcmc+DQo+DQo+DQo+ZmluZSB3aXRoIG1lDQo+DQo+DQo+LS1hYXJv bg0KPg0KPg0KPg0KPk9uIFR1ZSwgSnVuIDMsIDIwMTQgYXQgNDo1NCBBTSwgTWljaGFlbCBXZWx6 bA0KPjxtaWNoYXdlQGlmaS51aW8ubm8+IHdyb3RlOg0KPg0KPkFhcm9uPyAgSm9lPw0KPg0KPg0K Pk9uIDMuIGp1bmkgMjAxNCwgYXQgMTA6NDYsIEdvcnJ5IEZhaXJodXJzdCA8Z29ycnlAZXJnLmFi ZG4uYWMudWs+IHdyb3RlOg0KPg0KPj4gU29ycnksICJ5ZXMiLg0KPj4NCj4+IEdvcnJ5DQo+Pg0K Pj4NCj4+IE9uIDAzLzA2LzIwMTQgMDk6MTcsIE1pY2hhZWwgV2Vsemwgd3JvdGU6DQo+Pj4gQW5u YSB0YWxrZWQgYWJvdXQgaXRlbSAjMiwgbm90IGl0ZW0gIzMgKHdoZXJlIG5vIG90aGVyIHdvcmRp bmcgd2FzDQo+Pj5wcm9wb3NlZCBJIHRoaW5rKSwgc28geW91ciByZXNwb25zZSBpcyBjb25mdXNp bmcuIFRyeSBhZ2Fpbj8NCj4+Pg0KPj4+IERvIHlvdSBhZ3JlZSB3aXRoIEFubmEncyBwcm9wb3Nl ZCB3b3JkaW5nIGZvciBpdGVtICMyPyAgSSBkby4NCj4+Pg0KPj4+DQo+Pj4gT24gMy4ganVuaSAy MDE0LCBhdCAwOTozMSwgZ29ycnlAZXJnLmFiZG4uYWMudWsgd3JvdGU6DQo+Pj4NCj4+Pj4gTXkg b3JpZ2luYWwgcG9pbnQgd2FzIHRoYXQgSSBkaWQgbm90IHRoaW5rIHRoaXMgd2FzIHRoZSBwaWVj ZSBhYm91dA0KPj4+PndoYXQNCj4+Pj4gYXBwbGljYXRpb25zIHdhbnRlZCB0byB1c2UgLSB0aGF0 IEkgdGhvdWdodCB3YXMgZ29pbmcgdG8gYmUgcGFydCBvZg0KPj4+PiMyLCBteQ0KPj4+PiB0aG91 Z2h0cyB3ZXJlIHRoYXQgIzMgcmVsYXRlZCB0byB0aGUgdHJhbnNwb3J0IHN5c3RlbSB3b3JraW5n IG91dA0KPj4+PndoYXQgd2FzDQo+Pj4+IGFjdHVhbGx5IHN1cHBvcnRlZCwgYW5kIHRoZSBtZWNo YW5pc21zICh0cmlja3MsIHByb3RvY29scyBhbmQNCj4+Pj5tZXNzYWdlcyB0bw0KPj4+PiBiZSBl eGNoYW5nZWQpIHRvIGNvbXBsZXRlIHRoaXMgcHJvY2VzcyBkZXRlcm1pbmluZyBhIHVzYWJsZQ0K Pj4+PnRyYW5zcG9ydC4gIE15DQo+Pj4+IHZpZXcgaXMgcHJvYmFibHkgYSBmYWlybHkgbW9kdWxh ciB3YXkgb2YgbG9va2luZyBhdCB0aGUgcHJvYmxlbSAtIGJ1dA0KPj4+Pml0DQo+Pj4+IHdvdWxk IGFsbG93IGF0IGxlYXN0IHNvbWV0aGluZyB0byBiZSBidWlsdCwgYW5kIGV4cGVyaW1lbnRhbGx5 DQo+Pj4+ZGVwbG95ZWQgLQ0KPj4+PiB3aG8ga25vd3MsIGlmIHRoZSBtZXRob2Qgd29ya3MgaXQg d291bGQgYWNoaWV2ZSB0aGUgZ29hbC4NCj4+Pj4NCj4+Pj4gVGhhdCdzIG5vdCB0byBzYXkgdGhl cmUgaXNuJ3QgYSBjaGFuY2UgZm9yIGEgcmljaGVyICJhcHBzIg0KPj4+PmludGVyYWN0aW9uLA0K Pj4+PiBpJ2QganV0cyBsaWtlIGEgZm9jdXMgb24gd2hhdCBwYXRocyAqc3VwcG9ydCouICBQdXR0 aW5nIG1vcmUgb3ZlciBVRFANCj4+Pj4gcHJvYmFibHkgaGVpZ2h0ZW5zIHRoZSBuZWVkIHRvIGFs c28gZG8gdGhlIGFwcHMgcGFydCAtIGJ1dCBVRFAgYWxzbw0KPj4+Pmhhcw0KPj4+PiBpdHMgb3du IHNldCBvZiBwYXRoIGlzc3Vlcy4gTXkgYXJndW1lbnQgaXMgdGhhdCB0aGUgVEFQUyAjMyBpdGVt DQo+Pj4+bmVlZHMgdG8NCj4+Pj4gZm9jdXMgb24gZmluZGluZyBhIHRyYW5zcG9ydCB0aGF0IGNh biBiZSB1c2VkIG92ZXIgdGhlIHBhdGggLSBpZiB0aGF0DQo+Pj4+IGNhbid0IGJlIGZpeGVkLCB0 aGVuIFRBUFMgY2FuJ3Qgc3VjY2VlZC4NCj4+Pj4NCj4+Pj4gR29ycnkNCj4+Pj4NCj4+Pj4+IEhp LA0KPj4+Pj4NCj4+Pj4+IEkgZG8gbm90IGxpa2UgImFwcGxpY2F0aW9ucyB3YW50IHRvIHVzZSIu IFRoZSBhcHBsaWNhdGlvbg0KPj4+Pj5yZXF1aXJlbWVudHMNCj4+Pj4+IGdpdmUgaW5wdXQgZm9y IHRoZSBzZXJ2aWNlcyB0byBzcGVjaWZ5LCBidXQgdG8gc2F5IHRoYXQgd2Ugc2hvdWxkDQo+Pj4+ PiBzcGVjaWZ5IHdoYXQgYXBwbGljYXRpb25zIHdhbnQgdG8gdXNlIHNvdW5kcyBzdHJhbmdlIHRv IG1lLg0KPj4+Pj4NCj4+Pj4+IEkgdGhpbmsgdGhlIGN1cnJlbnQgZm9ybXVsYXRpb24gaXMgYmV0 dGVyIGFuZCBtb3JlIGNsZWFyLiBJIGFtIGFsc28NCj4+Pj4+ZmluZQ0KPj4+Pj4gd2l0aCB0aGUg ImltcGxlbWVudGluZyBUQVBTIiBhZGRpdGlvbiB0aGF0IEFhcm9uIHN1Z2dlc3RlZC4gQnV0IGFz DQo+Pj4+PkpvZQ0KPj4+Pj4gZGlkIG5vdCBsaWtlICJpbXBsZW1lbnRpbmciLCBob3cgYWJvdXQ6 DQo+Pj4+Pg0KPj4+Pj4gInNwZWNpZnkgYSBzZXQgb2YgdHJhbnNwb3J0IHNlcnZpY2VzIHRoYXQg ZW5kIHN5c3RlbXMgc3VwcG9ydGluZyBUQVBTDQo+Pj4+PiBuZWVkIHRvIHByb3ZpZGUgYW5kIHBy b3ZpZGUgZ3VpZGFuY2Ugb24gY2hvb3NpbmcgYW1vbmcgYXZhaWxhYmxlDQo+Pj4+PiBtZWNoYW5p c21zIGFuZCBwcm90b2NvbHMgdG8gb2J0YWluIGEgZ2l2ZW4gdHJhbnNwb3J0IHNlcnZpY2UuIg0K Pj4+Pj4NCj4+Pj4+IEFubmENCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gT24gMjAxNC0wNi0wMyAwMDox MywgTWljaGFlbCBXZWx6bCB3cm90ZToNCj4+Pj4+PiBvdGhlciBvcGluaW9ucz8gKG15c2VsZiwg aSdtIG5ldXRyYWwpDQo+Pj4+Pj4NCj4+Pj4+PiBTZW50IGZyb20gbXkgaVBob25lDQo+Pj4+Pj4N Cj4+Pj4+PiBPbiAzLiBqdW5pIDIwMTQsIGF0IDAwOjAyLCBBYXJvbiBGYWxrIDxmYWxrLWlldGZA ZGdmdGVjaC5jb20NCj4+Pj4+PiA8bWFpbHRvOmZhbGstaWV0ZkBkZ2Z0ZWNoLmNvbT4+IHdyb3Rl Og0KPj4+Pj4+DQo+Pj4+Pj4+IE1pY2hhZWwtDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEknbSBhY3R1YWxs eSBPSyB3aXRoIEpvZSdzIHByb3Bvc2VkIHdvcmRpbmc6DQo+Pj4+Pj4+DQo+Pj4+Pj4+IE9uIEZy aSwgTWF5IDMwLCAyMDE0IGF0IDExOjU1IEFNLCBKb2UgSGlsZGVicmFuZCAoamhpbGRlYnIpDQo+ Pj4+Pj4+IDxqaGlsZGVickBjaXNjby5jb20gPG1haWx0bzpqaGlsZGVickBjaXNjby5jb20+PiB3 cm90ZToNCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgT24gNS8zMC8xNCwgODoyOSBBTSwgIkFhcm9uIEZh bGsiIDxmYWxrLWlldGZAZGdmdGVjaC5jb20NCj4+Pj4+Pj4gICAgPG1haWx0bzpmYWxrLWlldGZA ZGdmdGVjaC5jb20+PiB3cm90ZToNCj4+Pj4+Pj4NCj4+Pj4+Pj4+IE15IHByb3Bvc2VkIHdvcmRp bmcgY2hhbmdlICh3aGljaCBhdCBsZWFzdCBHb3JyeSBhY2NlcHRlZCkgaXMNCj4+Pj4+Pj4gICAg bm90IGluIHRoZQ0KPj4+Pj4+Pj4gY3VycmVudCBkcmFmdC4gIFJlcGVhdGluZzoNCj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gUmV2aXNlIHdvcmtpbmcgZ3JvdXAgZ29hbCAjMiB0byByZWFk ICJzcGVjaWZ5IGEgc2V0IG9mIHRyYW5zcG9ydA0KPj4+Pj4+PiAgICBzZXJ2aWNlcw0KPj4+Pj4+ Pj4gdGhhdCBlbmQgc3lzdGVtcyAqKmltcGxlbWVudGluZyBUQVBTKiogbmVlZCB0byBwcm92aWRl IGFuZCBwcm92aWRlDQo+Pj4+Pj4+PiBndWlkYW5jZSBvbiBjaG9vc2luZyBhbW9uZyBhdmFpbGFi bGUgbWVjaGFuaXNtcyBhbmQgcHJvdG9jb2xzIHRvDQo+Pj4+Pj4+ICAgIG9idGFpbiBhDQo+Pj4+ Pj4+PiBnaXZlbiB0cmFuc3BvcnQgc2VydmljZS4iDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgIFRoZXJl J3Mgbm8gcHJvdG9jb2wgZm9yIFRBUFMgeWV0LCBzbyBub2JvZHkgaXMgZ29pbmcgdG8NCj4+Pj4+ Pj4gICAgImltcGxlbWVudCBUQVBTIi4NCj4+Pj4+Pj4gICAgU3VnZ2VzdGVkIGNoYW5nZTogImVu ZCBzeXN0ZW1zIG5lZWQgdG8gcHJvdmlkZSIgLT4gImFwcGxpY2F0aW9ucw0KPj4+Pj4+PiAgICB3 YW50IHRvDQo+Pj4+Pj4+ICAgIHVzZSIuDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEl0IGFs bG93cyB0aGUgd2cgbW9yZSBmbGV4aWJpbGl0eSB3aGljaCBpcyBwcm9iYWJseSBhcHByb3ByaWF0 ZSBpbg0KPj4+Pj4+PiB0aGlzIHN0YWdlLg0KPj4+Pj4+Pg0KPj4+Pj4+PiAtLWFhcm9uDQo+Pj4+ Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IE9uIE1vbiwgSnVuIDIsIDIwMTQgYXQgNTo0NyBQTSwgTWlj aGFlbCBXZWx6bCA8bWljaGF3ZUBpZmkudWlvLm5vDQo+Pj4+Pj4+IDxtYWlsdG86bWljaGF3ZUBp ZmkudWlvLm5vPj4gd3JvdGU6DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgIEhpIQ0KPj4+Pj4+Pg0KPj4+ Pj4+PiAgICBTcGVuY2VyLCB0aGFuayB5b3UgdmVyeSBtdWNoIGZvciB0aGlzIHVwZGF0ZS4gTXVj aCBhcHByZWNpYXRlZCENCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgUmVnYXJkaW5nIHRoZSBjaGFydGVy IGJpdCwgbGV0J3MgdHJ5IHRvIGZpZ3VyZSBvdXQgd2hhdA0KPj4+Pj4+PiAgICBzcGVjaWZpY2Fs bHkgaXMgbmVlZGVkLiBIZXJlJ3MgdGhlIGxpbmsgdG8gdGhlDQo+Pj4+Pj4+ICAgIGFsd2F5cy1t b3N0LXVwLXRvLWRhdGUgdmVyc2lvbjoNCj4+Pj4+Pj4gICAgDQo+Pj4+Pj4+aHR0cHM6Ly9zaXRl cy5nb29nbGUuY29tL3NpdGUvdHJhbnNwb3J0cHJvdG9jb2xzZXJ2aWNlcy9jaGFydGVyLXByb3AN Cj4+Pj4+Pj5vc2FsDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgIFlvdSB3cm90ZToNCj4+Pj4+Pj4NCj4+ Pj4+Pj4+ICAgIEknZCBsaWtlIHRvIHNlZSBhbiB1cGRhdGVkIGNoYXJ0ZXIgcHJvcG9zYWwgdGhh dCByZWZsZWN0cw0KPj4+Pj4+Pj5yZWNlbnQNCj4+Pj4+Pj4+ICAgIG1haWxpbmcgbGlzdCBkaXNj dXNzaW9uLCBpbmNsdWRpbmcgZHJvcHBpbmcgdGhlIHNwZWNpZmljcyBhYm91dA0KPj4+Pj4+Pj4g ICAgZG9jdW1lbnQgY2F0ZWdvcnksIHNvIHRoYXQgdGhlIGZvbGtzIG9uIHRoZSBtYWlsaW5nIGxp c3QgY2FuDQo+Pj4+Pj4+PiAgICBjaGVjayB3aGV0aGVyIHRoZWlyIGNvbmNlcm5zIGhhdmUgYmVl biBhZGRyZXNzZWQuDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgIFdoYXQgZXhhY3RseSBkbyB5b3UgbWVh biB3aXRoICJkcm9wcGluZyB0aGUgc3BlY2lmaWNzIGFib3V0DQo+Pj4+Pj4+ICAgIGRvY3VtZW50 IGNhdGVnb3J5IiAtIGlzIHRoZSBzdWdnZXN0aW9uIHRvIGNoYW5nZSBXRyBnb2FsICMxLA0KPj4+ Pj4+PiAgICB3aGljaCBub3cgcmVhZHM6DQo+Pj4+Pj4+ICAgICJpZGVudGlmeSBzZXJ2aWNlcyBw cm92aWRlZCBieSBleGlzdGluZyBJRVRGIHRyYW5zcG9ydCBwcm90b2NvbHMNCj4+Pj4+Pj4gICAg YW5kIGNvbmdlc3Rpb24gY29udHJvbCBtZWNoYW5pc21zLCBiYXNlZCBvbiBTdGFuZGFyZHMtdHJh Y2sgYW5kDQo+Pj4+Pj4+ICAgIEV4cGVyaW1lbnRhbCBSRkNzLiINCj4+Pj4+Pj4gICAgdG8NCj4+ Pj4+Pj4gICAgIiJpZGVudGlmeSBzZXJ2aWNlcyBwcm92aWRlZCBieSBleGlzdGluZyBJRVRGIHRy YW5zcG9ydA0KPj4+Pj4+PnByb3RvY29scw0KPj4+Pj4+PiAgICBhbmQgY29uZ2VzdGlvbiBjb250 cm9sIG1lY2hhbmlzbXMiID8NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgRm9yIG90aGVy IGNoYW5nZXMsIEknbGwgdHJ5IHRvIHJlY2FwIHRoZSBjdXJyZW50IHN0YXRlOyBwbGVhc2UsDQo+ Pj4+Pj4+ICAgIGFsbCwgaWYgeW91IGZlZWwgSSdtIG1pc3JlcHJlc2VudGluZyB0aGluZ3MsIDEp IGl0J3MgZGVmaW5pdGVseQ0KPj4+Pj4+PiAgICBub3QgaW50ZW50aW9uYWxseSwgMikgYnkgYWxs IG1lYW5zIGNvcnJlY3QgbWUhDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgIFRoZSB3YXkg SSBzZWUgaXQsIHdlIGhhdmUgMiBpc3N1ZXMgdG8gZGlzY3Vzcy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4N Cj4+Pj4+Pj4gICAgSVNTVUUgMToNCj4+Pj4+Pj4gICAgLS0tLS0tLS0tLS0tDQo+Pj4+Pj4+DQo+ Pj4+Pj4+ICAgIFdlIGhhZCBzb21lIGNvbnNlbnN1cyBvbiB0aGUgY2hhcnRlciBhcyBpdCBjdXJy ZW50bHkgc3RhbmRzOw0KPj4+Pj4+PiAgICB0aGVuLCB0aGVyZSB3YXMgdGhlIGNvbW1lbnQgYnkg QWFyb24gYWJvdXQgYSBzbWFsbCB3b3JkaW5nDQo+Pj4+Pj4+Y2hhbmdlDQo+Pj4+Pj4+ICAgIHRo YXQgSSBoYWQgbWlzc2VkLCBpbiBXRyBnb2FsICMyLCB3aGljaCBjdXJyZW50bHkgcmVhZHM6DQo+ Pj4+Pj4+DQo+Pj4+Pj4+ICAgICJzcGVjaWZ5IGEgc2V0IG9mIHRyYW5zcG9ydCBzZXJ2aWNlcyB0 aGF0IGVuZCBzeXN0ZW1zIG5lZWQgdG8NCj4+Pj4+Pj4gICAgcHJvdmlkZSBhbmQgcHJvdmlkZSBn dWlkYW5jZSBvbiBjaG9vc2luZyBhbW9uZyBhdmFpbGFibGUNCj4+Pj4+Pj4gICAgbWVjaGFuaXNt cyBhbmQgcHJvdG9jb2xzIHRvIG9idGFpbiBhIGdpdmVuIHRyYW5zcG9ydCBzZXJ2aWNlLiINCj4+ Pj4+Pj4NCj4+Pj4+Pj4gICAgSm9lIHNwb2tlIGFnYWluc3QgQWFyb24ncyBjaGFuZ2UgYW5kIG9m ZmVyZWQgYW4gYWx0ZXJuYXRpdmUNCj4+Pj4+Pj4gICAgcHJvcG9zYWwsIHdoaWNoIGFnYWluIEdv cnJ5IGRpZG4ndCBsaWtlLCBzYXlpbmcgdGhhdCBpdCBzZWVtcyB0bw0KPj4+Pj4+PiAgICBoaW0g dG8gYmUgYSBiaWcgY2hhbmdlIGluIHdoYXQgaGUncyBzZWVuIG9uIHRoZSBsaXN0Lg0KPj4+Pj4+ Pg0KPj4+Pj4+PiAgICBNeSBxdWVzdGlvbiBhdCB0aGlzIHBvaW50IGlzOiBjYW4gd2Uga2VlcCB0 aGUgb3JpZ2luYWwgdGV4dCBvZg0KPj4+Pj4+PiAgICBnb2FsICMyIGFzIEkgcXVvdGUgaXQgaGVy ZSwgb3IgZG9lcyBhbnlib2R5IGhhdmUgeWV0IGFub3RoZXINCj4+Pj4+Pj4gICAgcHJvcG9zYWwg dGhhdCB3ZSBhbGwgY2FuIGxpdmUgd2l0aD8NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAg SVNTVUUgMjoNCj4+Pj4+Pj4gICAgLS0tLS0tLS0tLS0tDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgIFRo ZXJlIHdlcmUgc29tZSBhcmd1bWVudHMgYWJvdXQgdGhlIG5lZWQgZm9yIFdHIGdvYWwgIzMsDQo+ Pj4+Pj4+ICAgIG1lY2hhbmlzbXMgdG8gZGlzY292ZXIgdGhlIGF2YWlsYWJpbGl0eSBvZiBwcm90 b2NvbHMuLi4gICAtIGFuZA0KPj4+Pj4+PiAgICBpdCBzZWVtcyB0aGF0IHNldmVyYWwgb2YgdXMg d2FudCB0byBrZWVwIGl0LiBDYW4gd2UgKHdpdGggdGhlDQo+Pj4+Pj4+ICAgIGN1cnJlbnQgdGV4 dCksIG9yIGRvIHdlIG5lZWQgdG8gZGlzY3VzcyB0aGlzIG1vcmU/DQo+Pj4+Pj4+DQo+Pj4+Pj4+ DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgIEFueSBvdGhlciBpc3N1ZXM/IFNob290LCBhbGwgIDotKQ0K Pj4+Pj4+Pg0KPj4+Pj4+PiAgICBDaGVlcnMsDQo+Pj4+Pj4+ICAgIE1pY2hhZWwNCj4+Pj4+Pj4N Cj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+Pj4+Pj4gICAgVGFwcyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4gICAgVGFw c0BpZXRmLm9yZyA8bWFpbHRvOlRhcHNAaWV0Zi5vcmc+DQo+Pj4+Pj4+ICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGFwcw0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+ DQo+Pj4+Pj4NCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+Pj4+IFRhcHMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gVGFwc0BpZXRmLm9yZw0K Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGFwcw0KPj4+Pj4N Cj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4+PiBUYXBzIG1haWxpbmcgbGlzdA0KPj4+Pj4gVGFwc0BpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90YXBzDQo+Pj4+Pg0KPj4+Pg0KPj4+Pg0K Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ PiBUYXBzIG1haWxpbmcgbGlzdA0KPj4+PiBUYXBzQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGFwcw0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBUYXBz IG1haWxpbmcgbGlzdA0KPj4+IFRhcHNAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3RhcHMNCj4+Pg0KPj4NCj4NCj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPlRhcHMgbWFpbGluZyBsaXN0DQo+VGFwc0Bp ZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGFwcw0KPg0K Pg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KDQoNCi0tIA0KSm9lIEhpbGRl YnJhbmQNCg0KDQoNCg== From nobody Wed Jun 4 09:21:58 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F2E1A03A8 for ; Wed, 4 Jun 2014 09:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 jKJo4zj04ivQ for ; Wed, 4 Jun 2014 09:21:54 -0700 (PDT) Received: from mail-oa0-x233.google.com (mail-oa0-x233.google.com [IPv6:2607:f8b0:4003:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C249C1A0312 for ; Wed, 4 Jun 2014 09:21:54 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id n16so8161562oag.24 for ; Wed, 04 Jun 2014 09:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=WoBZNJsZm3rOiT5beOK/qBn0UKLsetyOHBHbukMNgYY=; b=nQahptGxs/5RGE/WQsfUo3FH7zYtRTJiw86Ip+LUHdGhm3T9gaq2jTjpHEni8nL30A EseV2cmt+c2OLECmd1bksQQkrAtJbvA7YwOjXjLwcFQxWYy0x7NDUZ8zXLGxNDFIyuEm H5GQLXZCCKvMZmXhup+mn1YIAkLHjq4f5RxnJEiZwY8T6OKTnqtrlDGxg44k6ifVebcu uIi+LKZVbH8k1qT52KDqubEbZOGcc3KYQp2A5gcPWegNIoJLkulh162Hv4sS7Co5Kx2A Z7W3VKMmAxLmRriDjIz9aHWpFrcf8qt+xVxN0sNcnX1sA92wX7JELjfUJ9VaWSvGYNxp Q5+g== X-Received: by 10.182.58.83 with SMTP id o19mr59463430obq.26.1401898908613; Wed, 04 Jun 2014 09:21:48 -0700 (PDT) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id x8sm5593054obw.0.2014.06.04.09.21.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Jun 2014 09:21:48 -0700 (PDT) Message-ID: <538F475A.5060108@gmail.com> Date: Wed, 04 Jun 2014 11:20:42 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Michael Welzl , Brian Trammell References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> <2CF5E619-D270-48F2-B84A-6684F3A8E7E6@ifi.uio.no> In-Reply-To: <2CF5E619-D270-48F2-B84A-6684F3A8E7E6@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/f7QMz4c67md1wF1OTchxonwR4Vs Cc: Joe Hildebrand , taps@ietf.org Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 16:21:56 -0000 On 06/04/2014 04:04 AM, Michael Welzl wrote: > and also done the other change that Spencer requested. He wrote: "...dropping the specifics about document category", with which he can only have meant this text: > "identify services provided by existing IETF transport protocols and congestion control mechanisms, based on Standards-track and Experimental RFCs." I actually meant something else :-) The specifics about document category in that text were fine (the existing protocol specifications are already in specific document categories now), although there's no strong reason I can see to add that back in to the charter. I was talking about specifics on document categories in the milestones (there was a decent amount of mailing list discussion about whether the third milestone would be standards-track or experimental, and the milestones didn't have to say anything about that, beyond "to the IESG"). > which I now changed to: > "identify services provided by existing IETF transport protocols and congestion control mechanisms" > > So, I think if we get an ok from Joe on this change, I can probably hand this charter over to Spencer... Just let me know :-) Spencer From nobody Wed Jun 4 09:36:26 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824201A0307 for ; Wed, 4 Jun 2014 09:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 KwWd8LahbNX3 for ; Wed, 4 Jun 2014 09:36:23 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DCCD1A02F2 for ; Wed, 4 Jun 2014 09:36:22 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WsEAc-0004vq-3M; Wed, 04 Jun 2014 18:36:10 +0200 Received: from [193.212.24.100] (helo=[192.168.80.141]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1WsEAb-0002MG-IQ; Wed, 04 Jun 2014 18:36:10 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <538F475A.5060108@gmail.com> Date: Wed, 4 Jun 2014 18:36:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> <2CF5E619-D270-48F2-B84A-6684F3A8E7E6@ifi.uio.no> <538F475A.5060108@gmail.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 8 sum msgs/h 2 total rcpts 17313 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B5418607F4B717FD82E764269AEA1F01FBED2EF7 X-UiO-SPAM-Test: remote_host: 193.212.24.100 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 311 max/h 12 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/egrztvAz7Jh8lk-5f0Q0SwFO-DI Cc: Brian Trammell , Joe Hildebrand , taps@ietf.org Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 16:36:25 -0000 On 4. juni 2014, at 18:20, Spencer Dawkins = wrote: >=20 > On 06/04/2014 04:04 AM, Michael Welzl wrote: >> and also done the other change that Spencer requested. He wrote: = "...dropping the specifics about document category", with which he can = only have meant this text: >> "identify services provided by existing IETF transport protocols and = congestion control mechanisms, based on Standards-track and Experimental = RFCs." >=20 > I actually meant something else :-) >=20 > The specifics about document category in that text were fine (the = existing protocol specifications are already in specific document = categories now), although there's no strong reason I can see to add that = back in to the charter. ok, so I left it as it is now - > I was talking about specifics on document categories in the milestones = (there was a decent amount of mailing list discussion about whether the = third milestone would be standards-track or experimental, and the = milestones didn't have to say anything about that, beyond "to the = IESG"). fixed. Cheers, Michael From nobody Wed Jun 4 09:42:45 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBC81A0318 for ; Wed, 4 Jun 2014 09:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 0EmRqmehJoC5 for ; Wed, 4 Jun 2014 09:42:42 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 B02F71A02F3 for ; Wed, 4 Jun 2014 09:42:41 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WsEGo-0001gM-Kk; Wed, 04 Jun 2014 18:42:34 +0200 Received: from [193.212.24.100] (helo=[192.168.80.141]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WsEGo-0004Xx-4U; Wed, 04 Jun 2014 18:42:34 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: Date: Wed, 4 Jun 2014 18:42:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <541A9359-636A-481D-BFAE-3AB7DAC9A7D8@ifi.uio.no> References: To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 10 sum msgs/h 3 total rcpts 17315 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C32698E490D1727FDBDCA23A1D23A8BF8E806B20 X-UiO-SPAM-Test: remote_host: 193.212.24.100 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 312 max/h 12 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/atLGz8vZubjCmPjthaWDgBfSu0s Cc: "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 16:42:43 -0000 On 4. juni 2014, at 18:13, Joe Hildebrand (jhildebr) = wrote: > I won't stand in the way of that text, but I'll repeat for the folks = that > haven't heard me say this: >=20 > If the TAPS wg doesn't have adequate representation from the = application > layer folks, you will produce something that won't be consumed. = Saying > things like "we're just the support side" is liable to make the > apps-focused people assume that this is yet another TSV thing they can > safely ignore. >=20 > "What apps want" is *not* an unending story. ... but agreeing on it for the sake of a WG charter is. We've gone = through a year of "no, this is a TSV-only thing, let's incorporate apps = stuff in the charter" now, only to find us back at the beginning after a = year of debate. I'm fine with this beginning because it's *something* - = it's a way to get started, and something we need to do anyway. > They want to be able to > deploy something more flexible than TCP on top of today's Internet, > without requiring everyone to update their OS kernels, and without > requiring administrator privileges at any point. Treating that set of > requirements as rocket science won't help your output to get deployed. I'm not treating it as rocket science, but there are many different = opinions here on how this should be done. You state one thing ("deploy = something more flexible than TCP on top of today's Internet"), but this = isn't quite the whole story. You have people who actually deal with = sockets. You have people who don't. You have people saying the first = group of people doesn't exist. You have people only dealing with = middlewares and wanting to make patterns work better. You have folks = trying to make everything look like TCP. It's a large number of = opinions, and they don't seem to be mutually exclusive to me - these are = all different ways of dealing with the problem. But now go ahead and incorporate all the opinions in the paragraph above = in the charter and try to get people to agree on things. I've been = trying this for a year. Even when I started I thought it won't work, but = people like you said "if you don't get apps people in on this from the = start, this is bound to fail", and so we've been having fun with all = these views for a year now. See? This is why I don't want to repeat this exercise now. But I do want = to get started with something small and reasonable, something that we = all need no matter what. Cheers, Michael From nobody Wed Jun 4 09:51:14 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93EB41A037D for ; Wed, 4 Jun 2014 09:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 GuDrgLG4He6N for ; Wed, 4 Jun 2014 09:51:10 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 77F951A0248 for ; Wed, 4 Jun 2014 09:50:54 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id C3CBC2B40B9; Wed, 4 Jun 2014 17:50:47 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Wed, 4 Jun 2014 17:50:47 +0100 Message-ID: <475d45ecbcadfb4af16e929f559cfb05.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <541A9359-636A-481D-BFAE-3AB7DAC9A7D8@ifi.uio.no> References: <541A9359-636A-481D-BFAE-3AB7DAC9A7D8@ifi.uio.no> Date: Wed, 4 Jun 2014 17:50:47 +0100 From: gorry@erg.abdn.ac.uk To: "Michael Welzl" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/taps/21A9SRlRXyFuvnC5TO1taG7qUH4 Cc: "Joe Hildebrand \(jhildebr\)" , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 16:51:12 -0000 +1 I suggest we'll find there is more than one problem here - and I really do think there is a need to review the Apps needs/expectations etc - and maybe a need to express really what transports are trying to achieve for apps - but equally I don't understand why this stops deployment of the methods above/within the transport framework for apps that *CAN* use existing protocols. I move to start the work. Gorry > > On 4. juni 2014, at 18:13, Joe Hildebrand (jhildebr) > wrote: > >> I won't stand in the way of that text, but I'll repeat for the folks >> that >> haven't heard me say this: >> >> If the TAPS wg doesn't have adequate representation from the application >> layer folks, you will produce something that won't be consumed. Saying >> things like "we're just the support side" is liable to make the >> apps-focused people assume that this is yet another TSV thing they can >> safely ignore. >> >> "What apps want" is *not* an unending story. > > ... but agreeing on it for the sake of a WG charter is. We've gone through > a year of "no, this is a TSV-only thing, let's incorporate apps stuff in > the charter" now, only to find us back at the beginning after a year of > debate. I'm fine with this beginning because it's *something* - it's a way > to get started, and something we need to do anyway. > > >> They want to be able to >> deploy something more flexible than TCP on top of today's Internet, >> without requiring everyone to update their OS kernels, and without >> requiring administrator privileges at any point. Treating that set of >> requirements as rocket science won't help your output to get deployed. > > I'm not treating it as rocket science, but there are many different > opinions here on how this should be done. You state one thing ("deploy > something more flexible than TCP on top of today's Internet"), but this > isn't quite the whole story. You have people who actually deal with > sockets. You have people who don't. You have people saying the first group > of people doesn't exist. You have people only dealing with middlewares and > wanting to make patterns work better. You have folks trying to make > everything look like TCP. It's a large number of opinions, and they don't > seem to be mutually exclusive to me - these are all different ways of > dealing with the problem. > > But now go ahead and incorporate all the opinions in the paragraph above > in the charter and try to get people to agree on things. I've been trying > this for a year. Even when I started I thought it won't work, but people > like you said "if you don't get apps people in on this from the start, > this is bound to fail", and so we've been having fun with all these views > for a year now. > > See? This is why I don't want to repeat this exercise now. But I do want > to get started with something small and reasonable, something that we all > need no matter what. > > Cheers, > Michael > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Wed Jun 4 09:59:26 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C00E1A0306 for ; Wed, 4 Jun 2014 09:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 7eX9YQEX3Aoq for ; Wed, 4 Jun 2014 09:59:22 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88B5D1A00DF for ; Wed, 4 Jun 2014 09:59:21 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WsEVM-0002mo-TC; Wed, 04 Jun 2014 18:57:36 +0200 Received: from [193.212.24.100] (helo=[192.168.80.141]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WsEVL-0005UY-Nz; Wed, 04 Jun 2014 18:57:36 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D2DE6D@dfweml701-chm.china.huawei.com> Date: Wed, 4 Jun 2014 18:57:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <457B55E5-6B64-4955-90DD-B2B40FF3D6E8@ifi.uio.no> References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> <20140604050204.p5a00h7lusccggw8@webmail.mit.edu> <4A95BA014132FF49AE685FAB4B9F17F645D2DE6D@dfweml701-chm.china.huawei.com> To: Linda Dunbar X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 13 msgs/h 4 sum rcpts/h 17 sum msgs/h 5 total rcpts 17322 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 46EBB85BE5C7BCC8ACC4E0C055263D432760CA78 X-UiO-SPAM-Test: remote_host: 193.212.24.100 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 314 max/h 12 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/2bK-bzAjUZH1h7rwpSUyEyfCVDQ Cc: Brian Trammell , Marie-Jose Montpetit , Joe Hildebrand , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 16:59:25 -0000 Hi, While I agree with your thinking, I don't want to open yet another can = of worms. See, as I just wrote in the other email, this group has a = 1-year-history of starting with a small compromise; blowing it up; = letting the air out again. Don't blow the balloon up again, please. In my opinion, such text belongs where that particular debate happens: = in the charter of AEON (now called AECON) - where it could be formulated = to say that the work of TAPS, should a TAPS WG come into being, would be = extended as you propose below. I do support the AECON work. In my opinion AECON and TAPS could form two = very nicely complementary WGs - but I want TAPS to survive in case AECON = doesn't, so to speak... Cheers, Michael On 4. juni 2014, at 17:50, Linda Dunbar wrote: > All the transport protocols listed in the first paragraph are = protocols between applications (SCTP, DCCP, MPTCP, UDP-Lite and the = LEDBAT).=20 >=20 > With layers of layers aggregations (or tunnels) in today's network, = the hosts (applications) level transport layers information get buried. = That means those application level transport protocols are not visible = to network elements. Therefore, the gained benefits are very limited = even with relentless effort (of IETF) to fine tune the transport = protocols between applications.=20 >=20 > It is much more effective to have transport protocols between = applications <-> networks. =20 >=20 > Therefore, I am suggesting following wording changes to the charter = description: >=20 > -------------------------------- >=20 > Description of Working Group >=20 > Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite = and the LEDBAT congestion control mechanism extend the number of = transport services to applications in addition to the long-standing two = services provided by TCP and UDP. All those transport protocols are = protocols between hosts (or applications).=20 >=20 > With layers of layers aggregations (or tunnels) in today's network, = the hosts (applications) level transport layers information get buried. = That means those application level transport protocols are not visible = to network elements. Therefore, the gained benefits are very limited = even with relentless effort to fine tune the transport protocols between = applications.=20 >=20 > It is much more effective to have transport protocols between = applications <-> networks. =20 >=20 > For an application programmer, it is hard to use protocols other than = TCP or UDP: not all protocols are available everywhere, hence a = fall-back solution to e.g. TCP or UDP must be implemented. Some = protocols provide the same services in different ways. Layering = decisions must be made (e.g. should a protocol be used natively or over = UDP?). Because of these complications, programmers often resort to = either using TCP or implementing their own customized solution over UDP, = and chances of benefiting from other transport protocols are lost. >=20 > There are many ways in which this problem could be addressed; while it = may not yet be clear what the best way forward could be, any approach to = provide a richer set of transport services to applications will have to = begin with the identification of the services that current transport = protocols provide. >=20 >=20 > Linda Dunbar >=20 > -----Original Message----- > From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Brian Trammell > Sent: Wednesday, June 04, 2014 4:08 AM > To: Marie-Jose Montpetit > Cc: Joe Hildebrand; Michael Welzl; taps@ietf.org > Subject: Re: [Taps] So, is this the -00 charter yet? >=20 >=20 > On 04 Jun 2014, at 11:02, Marie-Jose Montpetit = wrote: >=20 >> Yes to get more applications developers. >>=20 >> I do have a problem with "what applicactions want". I think it should=20= >> be "what applications require"? >=20 > (This is a bit of a side conversation, because I think it's okay to = remove mention of application requirements from the charter = altogether... but...) >=20 > There's a little bit of a mismatch between the demand- and supply-side = here; applications have requirements and will do what is necessary with = available transports to meet those requirements. Usually this means they = use some API provided by their platform that somewhere along the line = maps down to something-over-TCP (XmlHttpSocket, for example). Sometimes = this means application developers roll their own transports over UDP = (QUIC, Mosh).=20 >=20 > Given this pragmatism, there is, I think, value in providing services = from the transport layer that the application development community = doesn't know it needs yet. Simply reacting to requirements expressed in = terms of the present situation is unlikely to lead to much innovation. = :) >=20 > Cheers, >=20 > Brian >=20 >> Quoting Brian Trammell : >>=20 >>> hi Michael, all, >>>=20 >>> I think the point Joe was trying to make here (please correct me, = Joe) is more that the supply-side does, at some point, need to match up = with services that applications that will actually use. Yes, we're doing = things from the supply-side in TAPS, but we will need participation from = application developers at the _very_ least as a sanity check on the = output of TAPS. >>>=20 >>> That said, I'm personally happy with Anna's text here, since trying = to draw a boundary around "what applications want" within the charter is = probably a less productive way to do this IMO than just making sure the = app developers are paying attention _during_ discussions of the = milestones on the charter. The IAB "IP Stack Evolution" = program-in-formation (current name is still subject to change, program = scope to be published shortly) will have as one of its goals working = together with the chairs of TAPS and within the WG itself to foster this = cross-area coordination. >>>=20 >>> Cheers, >>>=20 >>> Brian >>>=20 >>> On 04 Jun 2014, at 10:39, Michael Welzl wrote: >>>=20 >>>> Hi Joe, >>>>=20 >>>> I think I need you to say on the TAPS list whether you agree with = this or not. >>>>=20 >>>> It's about this text bit: >>>> ""specify a set of transport services that end systems supporting=20= >>>> TAPS need to provide and provide guidance on choosing among=20 >>>> available mechanisms and protocols to obtain a given transport = service." >>>>=20 >>>> (below, Anna spoke against your suggested text and suggested this=20= >>>> alternative) >>>>=20 >>>> My personal opinion: I'd go with Anna's suggestion - this whole = "what do applications want" question is a never-ending story and doesn't = seem to be necessary to me: as Brian called it, we start with the = "support side" here, not the "demand side". TAPS is only the beginning. >>>>=20 >>>> Cheers, >>>> Michael >>>>=20 >>>>=20 >>>>=20 >>>> Begin forwarded message: >>>>=20 >>>>> From: Aaron Falk >>>>> Subject: Re: [Taps] So, is this the -00 charter yet? >>>>> Date: 3. juni 2014 20:43:16 CEST >>>>> To: Michael Welzl >>>>> Cc: "taps@ietf.org" >>>>>=20 >>>>> fine with me >>>>>=20 >>>>> --aaron >>>>>=20 >>>>>=20 >>>>> On Tue, Jun 3, 2014 at 4:54 AM, Michael Welzl = wrote: >>>>> Aaron? Joe? >>>>>=20 >>>>>=20 >>>>> On 3. juni 2014, at 10:46, Gorry Fairhurst = wrote: >>>>>=20 >>>>>> Sorry, "yes". >>>>>>=20 >>>>>> Gorry >>>>>>=20 >>>>>>=20 >>>>>> On 03/06/2014 09:17, Michael Welzl wrote: >>>>>>> Anna talked about item #2, not item #3 (where no other wording = was proposed I think), so your response is confusing. Try again? >>>>>>>=20 >>>>>>> Do you agree with Anna's proposed wording for item #2? I do. >>>>>>>=20 >>>>>>>=20 >>>>>>> On 3. juni 2014, at 09:31, gorry@erg.abdn.ac.uk wrote: >>>>>>>=20 >>>>>>>> My original point was that I did not think this was the piece=20= >>>>>>>> about what applications wanted to use - that I thought was=20 >>>>>>>> going to be part of #2, my thoughts were that #3 related to the=20= >>>>>>>> transport system working out what was actually supported, and=20= >>>>>>>> the mechanisms (tricks, protocols and messages to be exchanged)=20= >>>>>>>> to complete this process determining a usable transport. My=20 >>>>>>>> view is probably a fairly modular way of looking at the problem=20= >>>>>>>> - but it would allow at least something to be built, and = experimentally deployed - who knows, if the method works it would = achieve the goal. >>>>>>>>=20 >>>>>>>> That's not to say there isn't a chance for a richer "apps"=20 >>>>>>>> interaction, i'd juts like a focus on what paths *support*. =20 >>>>>>>> Putting more over UDP probably heightens the need to also do=20 >>>>>>>> the apps part - but UDP also has its own set of path issues. My=20= >>>>>>>> argument is that the TAPS #3 item needs to focus on finding a=20= >>>>>>>> transport that can be used over the path - if that can't be = fixed, then TAPS can't succeed. >>>>>>>>=20 >>>>>>>> Gorry >>>>>>>>=20 >>>>>>>>> Hi, >>>>>>>>>=20 >>>>>>>>> I do not like "applications want to use". The application=20 >>>>>>>>> requirements give input for the services to specify, but to=20 >>>>>>>>> say that we should specify what applications want to use = sounds strange to me. >>>>>>>>>=20 >>>>>>>>> I think the current formulation is better and more clear. I am=20= >>>>>>>>> also fine with the "implementing TAPS" addition that Aaron=20 >>>>>>>>> suggested. But as Joe did not like "implementing", how about: >>>>>>>>>=20 >>>>>>>>> "specify a set of transport services that end systems=20 >>>>>>>>> supporting TAPS need to provide and provide guidance on=20 >>>>>>>>> choosing among available mechanisms and protocols to obtain a = given transport service." >>>>>>>>>=20 >>>>>>>>> Anna >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 2014-06-03 00:13, Michael Welzl wrote: >>>>>>>>>> other opinions? (myself, i'm neutral) >>>>>>>>>>=20 >>>>>>>>>> Sent from my iPhone >>>>>>>>>>=20 >>>>>>>>>> On 3. juni 2014, at 00:02, Aaron Falk >>>>>>>>> > wrote: >>>>>>>>>>=20 >>>>>>>>>>> Michael- >>>>>>>>>>>=20 >>>>>>>>>>> I'm actually OK with Joe's proposed wording: >>>>>>>>>>>=20 >>>>>>>>>>> On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (jhildebr)=20= >>>>>>>>>>> > wrote: >>>>>>>>>>>=20 >>>>>>>>>>> On 5/30/14, 8:29 AM, "Aaron Falk" >>>>>>>>>> > wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> My proposed wording change (which at least Gorry accepted)=20= >>>>>>>>>>>> is >>>>>>>>>>> not in the >>>>>>>>>>>> current draft. Repeating: >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Revise working group goal #2 to read "specify a set of=20 >>>>>>>>>>>> transport >>>>>>>>>>> services >>>>>>>>>>>> that end systems **implementing TAPS** need to provide and=20= >>>>>>>>>>>> provide guidance on choosing among available mechanisms and=20= >>>>>>>>>>>> protocols to >>>>>>>>>>> obtain a >>>>>>>>>>>> given transport service." >>>>>>>>>>>=20 >>>>>>>>>>> There's no protocol for TAPS yet, so nobody is going to >>>>>>>>>>> "implement TAPS". >>>>>>>>>>> Suggested change: "end systems need to provide" -> = "applications >>>>>>>>>>> want to >>>>>>>>>>> use". >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> It allows the wg more flexibility which is probably=20 >>>>>>>>>>> appropriate in this stage. >>>>>>>>>>>=20 >>>>>>>>>>> --aaron >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl=20 >>>>>>>>>>> > wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Hi! >>>>>>>>>>>=20 >>>>>>>>>>> Spencer, thank you very much for this update. Much = appreciated! >>>>>>>>>>>=20 >>>>>>>>>>> Regarding the charter bit, let's try to figure out what >>>>>>>>>>> specifically is needed. Here's the link to the >>>>>>>>>>> always-most-up-to-date version: >>>>>>>>>>>=20 >>>>>>>>>>> https://sites.google.com/site/transportprotocolservices/char >>>>>>>>>>> ter-proposal >>>>>>>>>>>=20 >>>>>>>>>>> You wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> I'd like to see an updated charter proposal that reflects = recent >>>>>>>>>>>> mailing list discussion, including dropping the specifics = about >>>>>>>>>>>> document category, so that the folks on the mailing list = can >>>>>>>>>>>> check whether their concerns have been addressed. >>>>>>>>>>>=20 >>>>>>>>>>> What exactly do you mean with "dropping the specifics = about >>>>>>>>>>> document category" - is the suggestion to change WG goal = #1, >>>>>>>>>>> which now reads: >>>>>>>>>>> "identify services provided by existing IETF transport = protocols >>>>>>>>>>> and congestion control mechanisms, based on = Standards-track and >>>>>>>>>>> Experimental RFCs." >>>>>>>>>>> to >>>>>>>>>>> ""identify services provided by existing IETF transport = protocols >>>>>>>>>>> and congestion control mechanisms" ? >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> For other changes, I'll try to recap the current state; = please, >>>>>>>>>>> all, if you feel I'm misrepresenting things, 1) it's = definitely >>>>>>>>>>> not intentionally, 2) by all means correct me! >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> The way I see it, we have 2 issues to discuss. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> ISSUE 1: >>>>>>>>>>> ------------ >>>>>>>>>>>=20 >>>>>>>>>>> We had some consensus on the charter as it currently = stands; >>>>>>>>>>> then, there was the comment by Aaron about a small wording = change >>>>>>>>>>> that I had missed, in WG goal #2, which currently reads: >>>>>>>>>>>=20 >>>>>>>>>>> "specify a set of transport services that end systems need = to >>>>>>>>>>> provide and provide guidance on choosing among available >>>>>>>>>>> mechanisms and protocols to obtain a given transport = service." >>>>>>>>>>>=20 >>>>>>>>>>> Joe spoke against Aaron's change and offered an = alternative >>>>>>>>>>> proposal, which again Gorry didn't like, saying that it = seems to >>>>>>>>>>> him to be a big change in what he's seen on the list. >>>>>>>>>>>=20 >>>>>>>>>>> My question at this point is: can we keep the original = text of >>>>>>>>>>> goal #2 as I quote it here, or does anybody have yet = another >>>>>>>>>>> proposal that we all can live with? >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> ISSUE 2: >>>>>>>>>>> ------------ >>>>>>>>>>>=20 >>>>>>>>>>> There were some arguments about the need for WG goal #3, >>>>>>>>>>> mechanisms to discover the availability of protocols... = - and >>>>>>>>>>> it seems that several of us want to keep it. Can we (with = the >>>>>>>>>>> current text), or do we need to discuss this more? >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Any other issues? Shoot, all :-) >>>>>>>>>>>=20 >>>>>>>>>>> Cheers, >>>>>>>>>>> Michael >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Taps mailing list >>>>>>>>>>> Taps@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> _______________________________________________ >>>>>>>>>> Taps mailing list >>>>>>>>>> Taps@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> Taps mailing list >>>>>>>>> Taps@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Taps mailing list >>>>>>>> Taps@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Taps mailing list >>>>>>> Taps@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Taps mailing list >>>>> Taps@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>=20 >>>=20 >>=20 >>=20 >=20 From nobody Wed Jun 4 10:33:40 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85DB1A0141 for ; Wed, 4 Jun 2014 10:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 IXalC1UxlyzR for ; Wed, 4 Jun 2014 10:33:29 -0700 (PDT) Received: from mail-oa0-x22a.google.com (mail-oa0-x22a.google.com [IPv6:2607:f8b0:4003:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BDE31A0232 for ; Wed, 4 Jun 2014 10:33:28 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id j17so8348624oag.1 for ; Wed, 04 Jun 2014 10:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Lw0B+roFxf7aDUAmqoyvB7oGvoJA33jut0VunBYGXcM=; b=uyD0CdZMcYKQlr1w1sZCtofixQJgHoLclq5wZQPUPIg2qSSiSI+Ue75mMZAs+RzDaU soPDhdr6uQ484c2Ja/UQJwfyz2s6dcuRRVpo+Exr88a76D3Ehnqe4ps+x5W3F7JD0pW2 +xrtX2MNxYjbkrJ8H9tFli9c8aEYCXduiby1awl/VZhKMXKK2BKX75T7ZZdZHhkfY9g4 KonoZBtAusVY5V9WWTKjSFr4b+8YuhK95Mawi2as+Gw0M3mSkCiRq+HWz4uoPmR8HLq3 A772xHRfSbr1HKoDxaOm9QNZouw7i5exTVKS8XkBu7FHH16gps1JE8ZyLCfHAaDTifmL SNfQ== X-Received: by 10.182.19.196 with SMTP id h4mr60428508obe.20.1401903202801; Wed, 04 Jun 2014 10:33:22 -0700 (PDT) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id ar2sm5877172obc.29.2014.06.04.10.33.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Jun 2014 10:33:22 -0700 (PDT) Message-ID: <538F585F.2030606@gmail.com> Date: Wed, 04 Jun 2014 12:33:19 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Michael Welzl , Linda Dunbar References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> <20140604050204.p5a00h7lusccggw8@webmail.mit.edu> <4A95BA014132FF49AE685FAB4B9F17F645D2DE6D@dfweml701-chm.china.huawei.com> <457B55E5-6B64-4955-90DD-B2B40FF3D6E8@ifi.uio.no> In-Reply-To: <457B55E5-6B64-4955-90DD-B2B40FF3D6E8@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/rW_IAAbPte-BBP75dxQCVhMc7CA Cc: Brian Trammell , Marie-Jose Montpetit , Joe Hildebrand , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 17:33:34 -0000 Just for light steering (as a somewhat responsible AD) ... On 06/04/2014 11:57 AM, Michael Welzl wrote: > Hi, > > While I agree with your thinking, I don't want to open yet another can of worms. See, as I just wrote in the other email, this group has a 1-year-history of starting with a small compromise; blowing it up; letting the air out again. Don't blow the balloon up again, please. I don't know the future any more than other folks, but I'm guessing that TAPS would be more successful if it's exporting needs to other groups after it identifies the needed services, than if it's importing suggestions about how services could be provided from (potentially many) other places. > In my opinion, such text belongs where that particular debate happens: in the charter of AEON (now called AECON) - where it could be formulated to say that the work of TAPS, should a TAPS WG come into being, would be extended as you propose below. > > I do support the AECON work. In my opinion AECON and TAPS could form two very nicely complementary WGs - but I want TAPS to survive in case AECON doesn't, so to speak... I just want the right thing to happen. That could be a right thing, but it's too early for me to tell :-) Spencer > Cheers, > Michael > > > On 4. juni 2014, at 17:50, Linda Dunbar wrote: > >> All the transport protocols listed in the first paragraph are protocols between applications (SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT). >> >> With layers of layers aggregations (or tunnels) in today's network, the hosts (applications) level transport layers information get buried. That means those application level transport protocols are not visible to network elements. Therefore, the gained benefits are very limited even with relentless effort (of IETF) to fine tune the transport protocols between applications. >> >> It is much more effective to have transport protocols between applications <-> networks. >> >> Therefore, I am suggesting following wording changes to the charter description: >> >> -------------------------------- >> >> Description of Working Group >> >> Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion control mechanism extend the number of transport services to applications in addition to the long-standing two services provided by TCP and UDP. All those transport protocols are protocols between hosts (or applications). >> >> With layers of layers aggregations (or tunnels) in today's network, the hosts (applications) level transport layers information get buried. That means those application level transport protocols are not visible to network elements. Therefore, the gained benefits are very limited even with relentless effort to fine tune the transport protocols between applications. >> >> It is much more effective to have transport protocols between applications <-> networks. >> >> For an application programmer, it is hard to use protocols other than TCP or UDP: not all protocols are available everywhere, hence a fall-back solution to e.g. TCP or UDP must be implemented. Some protocols provide the same services in different ways. Layering decisions must be made (e.g. should a protocol be used natively or over UDP?). Because of these complications, programmers often resort to either using TCP or implementing their own customized solution over UDP, and chances of benefiting from other transport protocols are lost. >> >> There are many ways in which this problem could be addressed; while it may not yet be clear what the best way forward could be, any approach to provide a richer set of transport services to applications will have to begin with the identification of the services that current transport protocols provide. >> >> >> Linda Dunbar >> >> -----Original Message----- >> From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Brian Trammell >> Sent: Wednesday, June 04, 2014 4:08 AM >> To: Marie-Jose Montpetit >> Cc: Joe Hildebrand; Michael Welzl; taps@ietf.org >> Subject: Re: [Taps] So, is this the -00 charter yet? >> >> >> On 04 Jun 2014, at 11:02, Marie-Jose Montpetit wrote: >> >>> Yes to get more applications developers. >>> >>> I do have a problem with "what applicactions want". I think it should >>> be "what applications require"? >> (This is a bit of a side conversation, because I think it's okay to remove mention of application requirements from the charter altogether... but...) >> >> There's a little bit of a mismatch between the demand- and supply-side here; applications have requirements and will do what is necessary with available transports to meet those requirements. Usually this means they use some API provided by their platform that somewhere along the line maps down to something-over-TCP (XmlHttpSocket, for example). Sometimes this means application developers roll their own transports over UDP (QUIC, Mosh). >> >> Given this pragmatism, there is, I think, value in providing services from the transport layer that the application development community doesn't know it needs yet. Simply reacting to requirements expressed in terms of the present situation is unlikely to lead to much innovation. :) >> >> Cheers, >> >> Brian >> >>> Quoting Brian Trammell : >>> >>>> hi Michael, all, >>>> >>>> I think the point Joe was trying to make here (please correct me, Joe) is more that the supply-side does, at some point, need to match up with services that applications that will actually use. Yes, we're doing things from the supply-side in TAPS, but we will need participation from application developers at the _very_ least as a sanity check on the output of TAPS. >>>> >>>> That said, I'm personally happy with Anna's text here, since trying to draw a boundary around "what applications want" within the charter is probably a less productive way to do this IMO than just making sure the app developers are paying attention _during_ discussions of the milestones on the charter. The IAB "IP Stack Evolution" program-in-formation (current name is still subject to change, program scope to be published shortly) will have as one of its goals working together with the chairs of TAPS and within the WG itself to foster this cross-area coordination. >>>> >>>> Cheers, >>>> >>>> Brian >>>> >>>> On 04 Jun 2014, at 10:39, Michael Welzl wrote: >>>> >>>>> Hi Joe, >>>>> >>>>> I think I need you to say on the TAPS list whether you agree with this or not. >>>>> >>>>> It's about this text bit: >>>>> ""specify a set of transport services that end systems supporting >>>>> TAPS need to provide and provide guidance on choosing among >>>>> available mechanisms and protocols to obtain a given transport service." >>>>> >>>>> (below, Anna spoke against your suggested text and suggested this >>>>> alternative) >>>>> >>>>> My personal opinion: I'd go with Anna's suggestion - this whole "what do applications want" question is a never-ending story and doesn't seem to be necessary to me: as Brian called it, we start with the "support side" here, not the "demand side". TAPS is only the beginning. >>>>> >>>>> Cheers, >>>>> Michael >>>>> >>>>> >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: Aaron Falk >>>>>> Subject: Re: [Taps] So, is this the -00 charter yet? >>>>>> Date: 3. juni 2014 20:43:16 CEST >>>>>> To: Michael Welzl >>>>>> Cc: "taps@ietf.org" >>>>>> >>>>>> fine with me >>>>>> >>>>>> --aaron >>>>>> >>>>>> >>>>>> On Tue, Jun 3, 2014 at 4:54 AM, Michael Welzl wrote: >>>>>> Aaron? Joe? >>>>>> >>>>>> >>>>>> On 3. juni 2014, at 10:46, Gorry Fairhurst wrote: >>>>>> >>>>>>> Sorry, "yes". >>>>>>> >>>>>>> Gorry >>>>>>> >>>>>>> >>>>>>> On 03/06/2014 09:17, Michael Welzl wrote: >>>>>>>> Anna talked about item #2, not item #3 (where no other wording was proposed I think), so your response is confusing. Try again? >>>>>>>> >>>>>>>> Do you agree with Anna's proposed wording for item #2? I do. >>>>>>>> >>>>>>>> >>>>>>>> On 3. juni 2014, at 09:31, gorry@erg.abdn.ac.uk wrote: >>>>>>>> >>>>>>>>> My original point was that I did not think this was the piece >>>>>>>>> about what applications wanted to use - that I thought was >>>>>>>>> going to be part of #2, my thoughts were that #3 related to the >>>>>>>>> transport system working out what was actually supported, and >>>>>>>>> the mechanisms (tricks, protocols and messages to be exchanged) >>>>>>>>> to complete this process determining a usable transport. My >>>>>>>>> view is probably a fairly modular way of looking at the problem >>>>>>>>> - but it would allow at least something to be built, and experimentally deployed - who knows, if the method works it would achieve the goal. >>>>>>>>> >>>>>>>>> That's not to say there isn't a chance for a richer "apps" >>>>>>>>> interaction, i'd juts like a focus on what paths *support*. >>>>>>>>> Putting more over UDP probably heightens the need to also do >>>>>>>>> the apps part - but UDP also has its own set of path issues. My >>>>>>>>> argument is that the TAPS #3 item needs to focus on finding a >>>>>>>>> transport that can be used over the path - if that can't be fixed, then TAPS can't succeed. >>>>>>>>> >>>>>>>>> Gorry >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I do not like "applications want to use". The application >>>>>>>>>> requirements give input for the services to specify, but to >>>>>>>>>> say that we should specify what applications want to use sounds strange to me. >>>>>>>>>> >>>>>>>>>> I think the current formulation is better and more clear. I am >>>>>>>>>> also fine with the "implementing TAPS" addition that Aaron >>>>>>>>>> suggested. But as Joe did not like "implementing", how about: >>>>>>>>>> >>>>>>>>>> "specify a set of transport services that end systems >>>>>>>>>> supporting TAPS need to provide and provide guidance on >>>>>>>>>> choosing among available mechanisms and protocols to obtain a given transport service." >>>>>>>>>> >>>>>>>>>> Anna >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2014-06-03 00:13, Michael Welzl wrote: >>>>>>>>>>> other opinions? (myself, i'm neutral) >>>>>>>>>>> >>>>>>>>>>> Sent from my iPhone >>>>>>>>>>> >>>>>>>>>>> On 3. juni 2014, at 00:02, Aaron Falk >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>>> Michael- >>>>>>>>>>>> >>>>>>>>>>>> I'm actually OK with Joe's proposed wording: >>>>>>>>>>>> >>>>>>>>>>>> On Fri, May 30, 2014 at 11:55 AM, Joe Hildebrand (jhildebr) >>>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>> On 5/30/14, 8:29 AM, "Aaron Falk" >>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>>> My proposed wording change (which at least Gorry accepted) >>>>>>>>>>>>> is >>>>>>>>>>>> not in the >>>>>>>>>>>>> current draft. Repeating: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Revise working group goal #2 to read "specify a set of >>>>>>>>>>>>> transport >>>>>>>>>>>> services >>>>>>>>>>>>> that end systems **implementing TAPS** need to provide and >>>>>>>>>>>>> provide guidance on choosing among available mechanisms and >>>>>>>>>>>>> protocols to >>>>>>>>>>>> obtain a >>>>>>>>>>>>> given transport service." >>>>>>>>>>>> There's no protocol for TAPS yet, so nobody is going to >>>>>>>>>>>> "implement TAPS". >>>>>>>>>>>> Suggested change: "end systems need to provide" -> "applications >>>>>>>>>>>> want to >>>>>>>>>>>> use". >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> It allows the wg more flexibility which is probably >>>>>>>>>>>> appropriate in this stage. >>>>>>>>>>>> >>>>>>>>>>>> --aaron >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Jun 2, 2014 at 5:47 PM, Michael Welzl >>>>>>>>>>>> > wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi! >>>>>>>>>>>> >>>>>>>>>>>> Spencer, thank you very much for this update. Much appreciated! >>>>>>>>>>>> >>>>>>>>>>>> Regarding the charter bit, let's try to figure out what >>>>>>>>>>>> specifically is needed. Here's the link to the >>>>>>>>>>>> always-most-up-to-date version: >>>>>>>>>>>> >>>>>>>>>>>> https://sites.google.com/site/transportprotocolservices/char >>>>>>>>>>>> ter-proposal >>>>>>>>>>>> >>>>>>>>>>>> You wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I'd like to see an updated charter proposal that reflects recent >>>>>>>>>>>>> mailing list discussion, including dropping the specifics about >>>>>>>>>>>>> document category, so that the folks on the mailing list can >>>>>>>>>>>>> check whether their concerns have been addressed. >>>>>>>>>>>> What exactly do you mean with "dropping the specifics about >>>>>>>>>>>> document category" - is the suggestion to change WG goal #1, >>>>>>>>>>>> which now reads: >>>>>>>>>>>> "identify services provided by existing IETF transport protocols >>>>>>>>>>>> and congestion control mechanisms, based on Standards-track and >>>>>>>>>>>> Experimental RFCs." >>>>>>>>>>>> to >>>>>>>>>>>> ""identify services provided by existing IETF transport protocols >>>>>>>>>>>> and congestion control mechanisms" ? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> For other changes, I'll try to recap the current state; please, >>>>>>>>>>>> all, if you feel I'm misrepresenting things, 1) it's definitely >>>>>>>>>>>> not intentionally, 2) by all means correct me! >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The way I see it, we have 2 issues to discuss. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ISSUE 1: >>>>>>>>>>>> ------------ >>>>>>>>>>>> >>>>>>>>>>>> We had some consensus on the charter as it currently stands; >>>>>>>>>>>> then, there was the comment by Aaron about a small wording change >>>>>>>>>>>> that I had missed, in WG goal #2, which currently reads: >>>>>>>>>>>> >>>>>>>>>>>> "specify a set of transport services that end systems need to >>>>>>>>>>>> provide and provide guidance on choosing among available >>>>>>>>>>>> mechanisms and protocols to obtain a given transport service." >>>>>>>>>>>> >>>>>>>>>>>> Joe spoke against Aaron's change and offered an alternative >>>>>>>>>>>> proposal, which again Gorry didn't like, saying that it seems to >>>>>>>>>>>> him to be a big change in what he's seen on the list. >>>>>>>>>>>> >>>>>>>>>>>> My question at this point is: can we keep the original text of >>>>>>>>>>>> goal #2 as I quote it here, or does anybody have yet another >>>>>>>>>>>> proposal that we all can live with? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ISSUE 2: >>>>>>>>>>>> ------------ >>>>>>>>>>>> >>>>>>>>>>>> There were some arguments about the need for WG goal #3, >>>>>>>>>>>> mechanisms to discover the availability of protocols... - and >>>>>>>>>>>> it seems that several of us want to keep it. Can we (with the >>>>>>>>>>>> current text), or do we need to discuss this more? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Any other issues? Shoot, all :-) >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Michael >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>> >>>>> _______________________________________________ >>>>> Taps mailing list >>>>> Taps@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/taps >>>> >>> > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu Jun 5 00:38:03 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF43C1A00E9 for ; Thu, 5 Jun 2014 00:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 tnb1ux_Ajb-7 for ; Thu, 5 Jun 2014 00:37:59 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id C1CDC1A009E for ; Thu, 5 Jun 2014 00:37:58 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2::2] (unknown [IPv6:2001:470:26:9c2::2]) by trammell.ch (Postfix) with ESMTPSA id CD9B01A0A44; Thu, 5 Jun 2014 09:37:20 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_E9CC0C50-6C97-4DA8-9D05-3FF6122CFD9A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Brian Trammell In-Reply-To: <538F585F.2030606@gmail.com> Date: Thu, 5 Jun 2014 09:37:19 +0200 Message-Id: <35C1DB85-E82C-4E2E-8621-6C1ECA338889@trammell.ch> References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> <20140604050204.p5a00h7lusccggw8@webmail.mit.edu> <4A95BA014132FF49AE685FAB4B9F17F645D2DE6D@dfweml701-chm.china.huawei.com> <457B55E5-6B64-4955-90DD-B2B40FF3D6E8@ifi.uio.no> <538F585F.2030606@gmail.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/G-JqlC0q3pfF3oXp5EzS4t-zwKg Cc: "taps@ietf.org" , Marie-Jose Montpetit , Joe Hildebrand , Michael Welzl , Linda Dunbar Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 07:38:01 -0000 --Apple-Mail=_E9CC0C50-6C97-4DA8-9D05-3FF6122CFD9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii greetings all, Tying a couple of threads together here... On 04 Jun 2014, at 19:33, Spencer Dawkins = wrote: > Just for light steering (as a somewhat responsible AD) ... >=20 > On 06/04/2014 11:57 AM, Michael Welzl wrote: >> Hi, >>=20 >> While I agree with your thinking, I don't want to open yet another = can of worms. See, as I just wrote in the other email, this group has a = 1-year-history of starting with a small compromise; blowing it up; = letting the air out again. Don't blow the balloon up again, please. >=20 > I don't know the future any more than other folks, but I'm guessing = that TAPS would be more successful if it's exporting needs to other = groups after it identifies the needed services, than if it's importing = suggestions about how services could be provided from (potentially many) = other places. +1 >> In my opinion, such text belongs where that particular debate = happens: in the charter of AEON (now called AECON) - where it could be = formulated to say that the work of TAPS, should a TAPS WG come into = being, would be extended as you propose below. >>=20 >> I do support the AECON work. In my opinion AECON and TAPS could form = two very nicely complementary WGs - but I want TAPS to survive in case = AECON doesn't, so to speak... >=20 > I just want the right thing to happen. That could be a right thing, = but it's too early for me to tell :-) In my opinion as well there's a very clear line between AECON and TAPS, = and I agree with Michael that these questions belong in AECON. Missing from either at the moment are approaches for lower-level = signaling to in-path devices -- not to say "this traffic will have these = characteristics" but more to group flows using new (userland) transport = protocols into sessions so that firewalls and middleboxes that want to = make decisions at session establishment time can do so without mucking = about in each transport's semantics. This is something we're discussing = in (what will now definitively be called) the IAB IP Stack Evolution = program, which may result in work being referred into an existing or new = WG or RG. But at the moment that effort is definitively separate from = TAPS in the present charter. On 04 Jun 2014, at 18:50, gorry@erg.abdn.ac.uk wrote: > +1 >=20 > I suggest we'll find there is more than one problem here - and I = really do > think there is a need to review the Apps needs/expectations etc - and > maybe a need to express really what transports are trying to achieve = for > apps - but equally I don't understand why this stops deployment of the > methods above/within the transport framework for apps that *CAN* use > existing protocols. >=20 > I move to start the work. I second Gorry's call. The points Joe raises are important -- again, I = think it's useful to do this work from the "supply side", but only if = there is some indication of current or eventual "demand". There's a = tension here that comes from trying to do engineering work from two = different viewpoints, and IETF area-tribalism (backed up by a scheduling = algorithm that is not focused on making cross-area participation easy) = doesn't help. I don't think this tension is something we can resolve in the charter; = rather, we (TAPS participants, chairs, ADs, the IAB) will have to remain = vigilant to make sure the output is applicable to application = requirements. In any case, the charter is IMO ready to send up for wider review. Cheers, Brian --Apple-Mail=_E9CC0C50-6C97-4DA8-9D05-3FF6122CFD9A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTkB4wAAoJENt3nsOmbNJcgDIIAJsAbU91J3YJ3IXN/zZw1kgt 8fb4tR2srhdMktycuwV8DvKJokbN2+psD+0pe0DwCeKa9g/GsWAv2/Qyep+vGAh8 cUwEkmLxaw/3eF06MoSML7prA9TYoquEGvKkApVbLaJr2/G49DjfuHxIxeLqyTvA aG+TxHUWgv2nS5pOOAg4um4Te93qGQjUjuVzgZ4sRayxVp7t7mM7YjbYzuVkFrIN +crmHMKtQrLx6f01Uzgygx+LWJ7E3ObbSKI1NF1ySnUvN1ObfVgTnEe3LcMBL50u LuG4hCfFsZvJT27yOKjTqcSnFnwkT7kuGygprLDyOrIHW96kcN+s/bJ5qcAmU6M= =VaTt -----END PGP SIGNATURE----- --Apple-Mail=_E9CC0C50-6C97-4DA8-9D05-3FF6122CFD9A-- From nobody Thu Jun 5 04:58:54 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8231A007F for ; Thu, 5 Jun 2014 04:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.95 X-Spam-Level: X-Spam-Status: No, score=-1.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 O1j8eDzdmEaD for ; Thu, 5 Jun 2014 04:58:50 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D22091A0096 for ; Thu, 5 Jun 2014 04:58:39 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WsWJC-0000zG-H7; Thu, 05 Jun 2014 13:58:14 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WsWJB-0008Tu-RU; Thu, 05 Jun 2014 13:58:14 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_2F803E8B-5A87-4E41-B27E-88D9F0693B98" From: Michael Welzl In-Reply-To: <35C1DB85-E82C-4E2E-8621-6C1ECA338889@trammell.ch> Date: Thu, 5 Jun 2014 13:58:12 +0200 Message-Id: References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> <20140604050204.p5a00h7lusccggw8@webmail.mit.edu> <4A95BA014132FF49AE685FAB4B9F17F645D2DE6D@dfweml701-chm.china.huawei.com> <457B55E5-6B64-4955-90DD-B2B40FF3D6E8@ifi.uio.no> <538F585F.2030606@gmail.com> <35C1DB85-E82C-4E2E-8621-6C1ECA338889@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 26 msgs/h 12 sum rcpts/h 28 sum msgs/h 13 total rcpts 17399 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F77B6B1D7789B1858600A479492CB178CC110360 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 12 total 5530 max/h 16 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/DB1UEQYHf6ZCAnFLtZuyvBiXP6A Cc: "taps@ietf.org" , Marie-Jose Montpetit , Spencer Dawkins , Joe Hildebrand , Linda Dunbar Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 11:58:54 -0000 --Apple-Mail=_2F803E8B-5A87-4E41-B27E-88D9F0693B98 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Thanks Brian for all you wrote here; I agree with all of it. As for = sending the charter on, I would also agree... Spencer, what do you = think? If you agree with our impression that "the time has come", then please = go ahead, just copy+paste it out from = https://sites.google.com/site/transportprotocolservices/charter-proposal = :-) Spencer, I also noticed that TAPS isn't in the BOF Wiki yet, and we have = only one more day before the scheduling deadline - are you going to put = it in there, or shall I? (anyway, given that it seems we have an = agreed-upon charter, is this then even intended as a BOF, or a = side-meeting of some sort, or what?) Cheers, Michael On 5. juni 2014, at 09:37, Brian Trammell wrote: > greetings all, >=20 > Tying a couple of threads together here... >=20 > On 04 Jun 2014, at 19:33, Spencer Dawkins = wrote: >=20 >> Just for light steering (as a somewhat responsible AD) ... >>=20 >> On 06/04/2014 11:57 AM, Michael Welzl wrote: >>> Hi, >>>=20 >>> While I agree with your thinking, I don't want to open yet another = can of worms. See, as I just wrote in the other email, this group has a = 1-year-history of starting with a small compromise; blowing it up; = letting the air out again. Don't blow the balloon up again, please. >>=20 >> I don't know the future any more than other folks, but I'm guessing = that TAPS would be more successful if it's exporting needs to other = groups after it identifies the needed services, than if it's importing = suggestions about how services could be provided from (potentially many) = other places. >=20 > +1 >=20 >>> In my opinion, such text belongs where that particular debate = happens: in the charter of AEON (now called AECON) - where it could be = formulated to say that the work of TAPS, should a TAPS WG come into = being, would be extended as you propose below. >>>=20 >>> I do support the AECON work. In my opinion AECON and TAPS could form = two very nicely complementary WGs - but I want TAPS to survive in case = AECON doesn't, so to speak... >>=20 >> I just want the right thing to happen. That could be a right thing, = but it's too early for me to tell :-) >=20 > In my opinion as well there's a very clear line between AECON and = TAPS, and I agree with Michael that these questions belong in AECON. >=20 > Missing from either at the moment are approaches for lower-level = signaling to in-path devices -- not to say "this traffic will have these = characteristics" but more to group flows using new (userland) transport = protocols into sessions so that firewalls and middleboxes that want to = make decisions at session establishment time can do so without mucking = about in each transport's semantics. This is something we're discussing = in (what will now definitively be called) the IAB IP Stack Evolution = program, which may result in work being referred into an existing or new = WG or RG. But at the moment that effort is definitively separate from = TAPS in the present charter. >=20 > On 04 Jun 2014, at 18:50, gorry@erg.abdn.ac.uk wrote: >=20 >> +1 >>=20 >> I suggest we'll find there is more than one problem here - and I = really do >> think there is a need to review the Apps needs/expectations etc - and >> maybe a need to express really what transports are trying to achieve = for >> apps - but equally I don't understand why this stops deployment of = the >> methods above/within the transport framework for apps that *CAN* use >> existing protocols. >>=20 >> I move to start the work. >=20 > I second Gorry's call. The points Joe raises are important -- again, I = think it's useful to do this work from the "supply side", but only if = there is some indication of current or eventual "demand". There's a = tension here that comes from trying to do engineering work from two = different viewpoints, and IETF area-tribalism (backed up by a scheduling = algorithm that is not focused on making cross-area participation easy) = doesn't help. >=20 > I don't think this tension is something we can resolve in the charter; = rather, we (TAPS participants, chairs, ADs, the IAB) will have to remain = vigilant to make sure the output is applicable to application = requirements. >=20 > In any case, the charter is IMO ready to send up for wider review. >=20 > Cheers, >=20 > Brian --Apple-Mail=_2F803E8B-5A87-4E41-B27E-88D9F0693B98 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii https://sites.google.com/site/transportprotocolservices/charter-pr= oposal   :-)

Spencer, I also = noticed that TAPS isn't in the BOF Wiki yet, and we have only one more = day before the scheduling deadline - are you going to put it in there, = or shall I?   (anyway, given that it seems we have an agreed-upon = charter, is this then even intended as a BOF, or a side-meeting of some = sort, or = what?)

Cheers,
Michael



On 5. juni 2014, at 09:37, Brian = Trammell wrote:

greetings all,

Tying a couple of threads = together here...

On 04 Jun 2014, at 19:33, Spencer Dawkins <spencerdawkins.ietf@gmail.co= m> wrote:

Just for light = steering (as a somewhat responsible AD) ...

On 06/04/2014 = 11:57 AM, Michael Welzl wrote:
Hi,

While I agree with your = thinking, I don't want to open yet another can of worms. See, as I just = wrote in the other email, this group has a 1-year-history of starting = with a small compromise; blowing it up; letting the air out again. Don't = blow the balloon up again, = please.

I don't know = the future any more than other folks, but I'm guessing that TAPS would = be more successful if it's exporting needs to other groups after it = identifies the needed services, than if it's importing suggestions about = how services could be provided from (potentially many) other = places.

+1

In my opinion, such text belongs = where that particular debate happens: in the charter of AEON (now called = AECON) - where it could be formulated to say that the work of TAPS, = should a TAPS WG come into being, would be extended as you propose = below.

I do support the AECON work. In = my opinion AECON and TAPS could form two very nicely complementary WGs - = but I want TAPS to survive in case AECON doesn't, so to = speak...

I just want the = right thing to happen. That could be a right thing, but it's too early = for me to tell :-)

In my opinion as well there's a = very clear line between AECON and TAPS, and I agree with Michael that = these questions belong in AECON.

Missing from either at the = moment are approaches for lower-level signaling to in-path devices -- = not to say "this traffic will have these characteristics" but more to = group flows using new (userland) transport protocols into sessions so = that firewalls and middleboxes that want to make decisions at session = establishment time can do so without mucking about in each transport's = semantics. This is something we're discussing in (what will now = definitively be called) the IAB IP Stack Evolution program, which may = result in work being referred into an existing or new WG or RG. But at = the moment that effort is definitively separate from TAPS in the present = charter.

On 04 Jun 2014, at 18:50, gorry@erg.abdn.ac.uk = wrote:

+1

I suggest we'll = find there is more than one problem here - and I really = do
think there is a need to = review the Apps needs/expectations etc - and
maybe a need to express really what transports are trying = to achieve for
apps - but = equally I don't understand why this stops deployment of = the
methods above/within the = transport framework for apps that *CAN* use
existing protocols.

I move to start = the work.

I second Gorry's call. The points Joe = raises are important -- again, I think it's useful to do this work from = the "supply side", but only if there is some indication of current or = eventual "demand". There's a tension here that comes from trying to do = engineering work from two different viewpoints, and IETF area-tribalism = (backed up by a scheduling algorithm that is not focused on  making = cross-area participation easy) doesn't help.

I don't think this = tension is something we can resolve in the charter; rather, we (TAPS = participants, chairs, ADs, the IAB) will have to remain vigilant to make = sure the output is applicable to application requirements.

In any = case, the charter is IMO ready to send up for wider = review.

Cheers,

Brian

=
= --Apple-Mail=_2F803E8B-5A87-4E41-B27E-88D9F0693B98-- From nobody Thu Jun 5 09:55:17 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A531A0221 for ; Thu, 5 Jun 2014 09:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001] autolearn=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 dzd1CjEmVv2g for ; Thu, 5 Jun 2014 09:55:14 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BC531A017F for ; Thu, 5 Jun 2014 09:55:14 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id i7so1467750oag.23 for ; Thu, 05 Jun 2014 09:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=yW3WpxbsKC15/LFE2+dBDFMakJWCKPkYAGRwnm0SGsU=; b=AXRLO65hr2be8ldl3cEySGcaiQniRv/AClWsXdpk/4Hurm9rXUFUNbTYTWg4oX0oKi jXrSQIlEsylbTMgYVIeQX0dprpIhSfOtqNNrVbJDIpwxi1Y1LBaipwmxBOkn/ZDMgAho cPktvc5Zr6lj5+SwbaXFvYsNqvet/rJY/d/r/gHiSOVFGdboUbIbXfBJF1POECQaelsA p56rmy25RJpLE/lF+6BCTW+UY80OJnfzrRR6Wid9+ijPGMu9xisvI9MyvYXCkcRh8O/F elUc9eLFILgHpQkgUL3qRIB62C5LhGG13SLlzsI0TBYz6dt86v60D4sgm/pbr23dB8+T zILA== X-Received: by 10.182.209.10 with SMTP id mi10mr67807313obc.37.1401987307739; Thu, 05 Jun 2014 09:55:07 -0700 (PDT) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id ub1sm22452613oeb.9.2014.06.05.09.55.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 09:55:07 -0700 (PDT) Message-ID: <5390A0E8.9050003@gmail.com> Date: Thu, 05 Jun 2014 11:55:04 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Michael Welzl , Brian Trammell References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> <20140604050204.p5a00h7lusccggw8@webmail.mit.edu> <4A95BA014132FF49AE685FAB4B9F17F645D2DE6D@dfweml701-chm.china.huawei.com> <457B55E5-6B64-4955-90DD-B2B40FF3D6E8@ifi.uio.no> <538F585F.2030606@gmail.com> <35C1DB85-E82C-4E2E-8621-6C1ECA338889@trammell.ch> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/brQlOHIUxyZHw0ZU3m1Oq0YP6T8 Cc: "taps@ietf.org" , Marie-Jose Montpetit , Joe Hildebrand , Linda Dunbar Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 16:55:15 -0000 On 06/05/2014 06:58 AM, Michael Welzl wrote: > Hi, > > Thanks Brian for all you wrote here; I agree with all of it. As for > sending the charter on, I would also agree... Spencer, what do you think? > > If you agree with our impression that "the time has come", then please > go ahead, just copy+paste it out from > https://sites.google.com/site/transportprotocolservices/charter-proposal > :-) Michael, I'm ready when the group is. My next step would be to put this in the datatracker as a proposed working group charter for review. > Spencer, I also noticed that TAPS isn't in the BOF Wiki yet, and we > have only one more day before the scheduling deadline - are you going > to put it in there, or shall I? (anyway, given that it seems we have > an agreed-upon charter, is this then even intended as a BOF, or a > side-meeting of some sort, or what?) So, if TAPS moves forward and wants to meet in Toronto, TAPS will need a slot, and slots go to working groups (which TAPS isn't) and to BOFs. It would be helpful if you cut-and-pasted into the BOF Wiki, and just put "in charter review process" somewhere toward the top of the description. That way, TAPS reserves a slot for Toronto, and if the charter is approved before Toronto, that works, too. Does that make sense? Spencer From nobody Thu Jun 5 12:31:34 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFB91A0369 for ; Thu, 5 Jun 2014 12:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 UvKtp-Ph29Mi for ; Thu, 5 Jun 2014 12:31:18 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 8E7081A0340 for ; Thu, 5 Jun 2014 12:31:14 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WsdMS-0000XC-BA; Thu, 05 Jun 2014 21:30:04 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WsdMR-0006C0-JV; Thu, 05 Jun 2014 21:30:04 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <5390A0E8.9050003@gmail.com> Date: Thu, 5 Jun 2014 21:29:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3A113E54-9BE7-4045-BC08-4D6CE5A21358@ifi.uio.no> References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> <20140604050204.p5a00h7lusccggw8@webmail.mit.edu> <4A95BA014132FF49AE685FAB4B9F17F645D2DE6D@dfweml701-chm.china.huawei.com> <457B55E5-6B64-4955-90DD-B2B40FF3D6E8@ifi.uio.no> <538F585F.2030606@gmail.com> <35C1DB85-E82C-4E2E-8621-6C1ECA338889@trammell.ch> <5390A0E8.9050003@gmail.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 2 sum rcpts/h 9 sum msgs/h 2 total rcpts 17433 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A37AD266AE7B2E1C361D9BED45EDE26DD72A17EA X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1558 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/dRPLDDBHsTpKMJJTIA3F88ZYZjA Cc: Brian Trammell , "taps@ietf.org" , Marie-Jose Montpetit , Joe Hildebrand , Linda Dunbar Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 19:31:25 -0000 On 5. juni 2014, at 18:55, Spencer Dawkins = wrote: >=20 > On 06/05/2014 06:58 AM, Michael Welzl wrote: >> Hi, >>=20 >> Thanks Brian for all you wrote here; I agree with all of it. As for = sending the charter on, I would also agree... Spencer, what do you = think? >>=20 >> If you agree with our impression that "the time has come", then = please go ahead, just copy+paste it out from = https://sites.google.com/site/transportprotocolservices/charter-proposal = :-) >=20 > Michael, I'm ready when the group is. My feeling is that the group is ready. I'm asking one more time, = explicitly: ARE YOU READY? https://www.youtube.com/watch?v=3DCIhylLW4Fcs (Let's say: we're all ready if no complaints come up within the next = day) > My next step would be to put this in the datatracker as a proposed = working group charter for review. Great!! >> Spencer, I also noticed that TAPS isn't in the BOF Wiki yet, and we = have only one more day before the scheduling deadline - are you going to = put it in there, or shall I? (anyway, given that it seems we have an = agreed-upon charter, is this then even intended as a BOF, or a = side-meeting of some sort, or what?) >=20 > So, if TAPS moves forward and wants to meet in Toronto, TAPS will need = a slot, and slots go to working groups (which TAPS isn't) and to BOFs. = It would be helpful if you cut-and-pasted into the BOF Wiki, and just = put "in charter review process" somewhere toward the top of the = description. That way, TAPS reserves a slot for Toronto, and if the = charter is approved before Toronto, that works, too. >=20 > Does that make sense? Sure does, will do! Michael From nobody Thu Jun 5 13:36:30 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB901A0278 for ; Thu, 5 Jun 2014 13:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 LUdlGEZ3WZQ3 for ; Thu, 5 Jun 2014 13:36:27 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D50BB1A018E for ; Thu, 5 Jun 2014 13:36:26 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id sa20so1904482veb.41 for ; Thu, 05 Jun 2014 13:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=t2yKA81uKAXdojPMz1kVWQVp/WVzMb4IE0uJPZc2Sj4=; b=dIrpjynU64bREm6871btkh2IIakyHEMKQmQKyJJnAoWRh2uVXtYOuecUxER6c+cguI RXNApyb/IUKejeB2ZhG21Na0npcR2owllYiciXbbGVZ5Ky5VyQLUednk4VgDM51ncz7i 9HzjFvaqGSGZSZmHlVol5WwDvYLf9QhEmBahVEpC4Q+XEZFaiJNzfMcqqJDOgdQDx626 8WeYtUviVQlffqcGu3losnv9pFGFn8ZNsr7ChRJs/CpDv3CGW90cWdBZ3ULxOWZOheB6 uVRGfp6IsG9LE4bjvSBTIJUCEKe2TI/SfSmgMs+peIJGB/POm8MrjCgsqEBL7A9M2Rq9 rsxA== MIME-Version: 1.0 X-Received: by 10.58.227.193 with SMTP id sc1mr5370210vec.43.1402000579916; Thu, 05 Jun 2014 13:36:19 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.33.199 with HTTP; Thu, 5 Jun 2014 13:36:19 -0700 (PDT) In-Reply-To: <3A113E54-9BE7-4045-BC08-4D6CE5A21358@ifi.uio.no> References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> <20140604050204.p5a00h7lusccggw8@webmail.mit.edu> <4A95BA014132FF49AE685FAB4B9F17F645D2DE6D@dfweml701-chm.china.huawei.com> <457B55E5-6B64-4955-90DD-B2B40FF3D6E8@ifi.uio.no> <538F585F.2030606@gmail.com> <35C1DB85-E82C-4E2E-8621-6C1ECA338889@trammell.ch> <5390A0E8.9050003@gmail.com> <3A113E54-9BE7-4045-BC08-4D6CE5A21358@ifi.uio.no> Date: Thu, 5 Jun 2014 16:36:19 -0400 X-Google-Sender-Auth: 6y0dje2UYrhMaX-EAjtfG9m_8j0 Message-ID: From: Barry Leiba To: Michael Welzl Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/C-arw4CnSsG8gsbFlpUf5kN-oNQ Cc: Linda Dunbar , Spencer Dawkins , Joe Hildebrand , Brian Trammell , Marie-Jose Montpetit , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 20:36:28 -0000 > My feeling is that the group is ready. I'm asking one more time, > explicitly: ARE YOU READY? > > https://www.youtube.com/watch?v=CIhylLW4Fcs AC/DC? Feh. https://www.youtube.com/watch?v=x3KjlnuETk0 Barry From nobody Thu Jun 5 13:53:26 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31D4F1A044A for ; Thu, 5 Jun 2014 13:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001] autolearn=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 TsEeE0QaTaKJ for ; Thu, 5 Jun 2014 13:53:22 -0700 (PDT) Received: from mail-vc0-x22c.google.com (mail-vc0-x22c.google.com [IPv6:2607:f8b0:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D377D1A0451 for ; Thu, 5 Jun 2014 13:53:00 -0700 (PDT) Received: by mail-vc0-f172.google.com with SMTP id lf12so1853971vcb.31 for ; Thu, 05 Jun 2014 13:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=PJt4TqVVD6Ak9Snx1RMG863hmV16WkZcHEsxM3hzIsI=; b=l1Wf2KMXbsn2zqzdzZLbssnUvlbxswWwIT87/OPGaLBrjwlWhy9T2XCKtjMLAvgKs0 IwICCDcZm5DcJsqSt9RCXOefpsCQjPrScCWyUgZEkYpT0IGpsiIldvesbxmASPV/EYQ6 YxA8dXdTaFW1pQg83zwmOndnhEUQdEbarB7pyBzwmcDGmiDnVb4FBSblRlJkcvLOy0Fd n17bddWnI8gPwvMUrL15YfPSuVixg/1oN4VFGLR2F0MYj0GTT00hlT/VlwgYoIQJC2xA 42gwnqZuU7X2bBbxgYz9Yz4y3u3qiDuj2mAfXHJyKMcvZkoGwzZbrYR38HWKnb3KtpNT KUyg== MIME-Version: 1.0 X-Received: by 10.220.94.8 with SMTP id x8mr5484324vcm.67.1402001573752; Thu, 05 Jun 2014 13:52:53 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.33.199 with HTTP; Thu, 5 Jun 2014 13:52:53 -0700 (PDT) In-Reply-To: <5390A0E8.9050003@gmail.com> References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> <20140604050204.p5a00h7lusccggw8@webmail.mit.edu> <4A95BA014132FF49AE685FAB4B9F17F645D2DE6D@dfweml701-chm.china.huawei.com> <457B55E5-6B64-4955-90DD-B2B40FF3D6E8@ifi.uio.no> <538F585F.2030606@gmail.com> <35C1DB85-E82C-4E2E-8621-6C1ECA338889@trammell.ch> <5390A0E8.9050003@gmail.com> Date: Thu, 5 Jun 2014 16:52:53 -0400 X-Google-Sender-Auth: tEYCSKDURihxKWuoUsFyTnZr6vM Message-ID: From: Barry Leiba To: Spencer Dawkins Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/VyS_Y3ejoI1UtlRcehD6BIv_-2M Cc: Michael Welzl , Linda Dunbar , Joe Hildebrand , Brian Trammell , Marie-Jose Montpetit , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 20:53:24 -0000 >> If you agree with our impression that "the time has come", then please go >> ahead, just copy+paste it out from >> https://sites.google.com/site/transportprotocolservices/charter-proposal >> :-) > > Michael, I'm ready when the group is. > > My next step would be to put this in the datatracker as a proposed working > group charter for review. Rather than waiting until it officially goes to the IESG, some suggestions: OLD Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion control mechanism extend the number of transport services to applications in addition to the long-standing two services provided by TCP and UDP. END TCP and UDP are two protocols... they provide more than two services. I think what this really wants to say is something like this: NEW Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite, and the LEDBAT congestion control mechanism extend the set of transport services that are available to applications, beyond those provided by TCP and UDP. END I would break into a new paragraph before "For an application programmer". OLD For an application programmer, it is hard to use protocols other than TCP or UDP: not all protocols are available everywhere, hence a fall-back solution to e.g. TCP or UDP must be implemented. NEW For an application programmer, it is hard to use protocols other than TCP or UDP: most network stacks only support TCP and UDP, many firewalls only pass TCP and UDP, and requiring other transport protocols risks having an application not work in many environments. Applications, therefore, must always be able to fall back to TCP or UDP. END OLD Some protocols provide the same services in different ways. Layering decisions must be made (e.g. should a protocol be used natively or over UDP?). Because of these complications, programmers often resort to either using TCP or implementing their own customized solution over UDP, and chances of benefiting from other transport protocols are lost. NEW Further, different protocols can provide the same services in different ways. Layering decisions must be made (for example, whether a protocol is used natively or tunneled through UDP). Because of these complications, programmers often resort to either using TCP or implementing their own customized solution over UDP. That can result in applications re-implementing features already available elsewhere, and chances of benefiting from other transport protocols are lost. END I don't really understand what work item 2 is trying to say, and how it's a distinct work item from number 1. Maybe it should be merged with 1, or rephrased to make the distinction clear. For item 3, I thought we were going for more than discovery, and meant to specify an experimental mechanism for specifying the services that were desired, and allow the transport layer to figure out how to provide those services. No? Barry From nobody Thu Jun 5 15:37:03 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36AE51A02B0 for ; Thu, 5 Jun 2014 15:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.951 X-Spam-Level: X-Spam-Status: No, score=-1.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 uBDA4XX-aHmv for ; Thu, 5 Jun 2014 15:36:56 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1A21A029A for ; Thu, 5 Jun 2014 15:36:56 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WsgH9-0007So-ND; Fri, 06 Jun 2014 00:36:47 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1WsgH8-0007lO-Uh; Fri, 06 Jun 2014 00:36:47 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: Date: Fri, 6 Jun 2014 00:36:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> <20140604050204.p5a00h7lusccggw8@webmail.mit.edu> <4A95BA014132FF49AE685FAB4B9F17F645D2DE6D@dfweml701-chm.china.huawei.com> <457B55E5-6B64-4955-90DD-B2B40FF3D6E8@ifi.uio.no> <538F585F.2030606@gmail.com> <35C1DB85-E82C-4E2E-8621-6C1ECA338889@trammell.ch> <5390A0E8.9050003@gmail.com> To: Barry Leiba X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 1 sum rcpts/h 14 sum msgs/h 4 total rcpts 17447 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 0323B0DBCC3B734F38F4A45CCFEE38067D592B70 X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1564 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/YpYGR7S-Bk4Tkuc5tGbBtsUI3EY Cc: Linda Dunbar , Spencer Dawkins , Joe Hildebrand , Brian Trammell , Marie-Jose Montpetit , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 22:37:00 -0000 Hi, Thanks a lot for your suggestions! Comments below: On 5. juni 2014, at 22:52, Barry Leiba wrote: >>> If you agree with our impression that "the time has come", then = please go >>> ahead, just copy+paste it out from >>> = https://sites.google.com/site/transportprotocolservices/charter-proposal >>> :-) >>=20 >> Michael, I'm ready when the group is. >>=20 >> My next step would be to put this in the datatracker as a proposed = working >> group charter for review. >=20 > Rather than waiting until it officially goes to the IESG, some = suggestions: >=20 > OLD > Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite > and the LEDBAT congestion control mechanism extend the number of > transport services to applications in addition to the long-standing > two services provided by TCP and UDP. > END >=20 > TCP and UDP are two protocols... they provide more than two services. > I think what this really wants to say is something like this: >=20 > NEW > Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite, > and the LEDBAT congestion control mechanism extend the set of > transport services that are available to applications, beyond those > provided by TCP and UDP. > END >=20 > I would break into a new paragraph before "For an application = programmer". >=20 > OLD > For an application programmer, it is hard to use protocols other than > TCP or UDP: not all protocols are available everywhere, hence a > fall-back solution to e.g. TCP or UDP must be implemented. > NEW > For an application programmer, it is hard to use protocols other than > TCP or UDP: most network stacks only support TCP and UDP, many > firewalls only pass TCP and UDP, and requiring other transport > protocols risks having an application not work in many environments. > Applications, therefore, must always be able to fall back to TCP or > UDP. > END >=20 > OLD > Some protocols provide the same services in different ways. Layering > decisions must be made (e.g. should a protocol be used natively or > over UDP?). Because of these complications, programmers often resort > to either using TCP or implementing their own customized solution over > UDP, and chances of benefiting from other transport protocols are > lost. > NEW > Further, different protocols can provide the same services in > different ways. Layering decisions must be made (for example, whether > a protocol is used natively or tunneled through UDP). >=20 > Because of these complications, programmers often resort to either > using TCP or implementing their own customized solution over UDP. > That can result in applications re-implementing features already > available elsewhere, and chances of benefiting from other transport > protocols are lost. > END I agree with all of the above, and I also find it hard to imagine that = someone would want to object to these changes - hence I incorporated = them in the charter at https://sites.google.com/site/transportprotocolservices/charter-proposal straight away. (this is not to stop others from commenting, of course! = Just saying I think it's unlikely so I did what seemed efficient to me) > I don't really understand what work item 2 is trying to say, and how > it's a distinct work item from number 1. Maybe it should be merged > with 1, or rephrased to make the distinction clear. In my interpretation (and I hope that's the general view here?), #2 is a = shortened list of #1 - just the useful stuff that we really recommend = providing, not the complete list of absolutely all combinations of = things, no matter how strange or useless. I'd be glad to get suggestions = (from you or anybody else) on making that clearer in the text. > For item 3, I thought we were going for more than discovery, and meant > to specify an experimental mechanism for specifying the services that > were desired, and allow the transport layer to figure out how to > provide those services. No? So, item #2 is meant to be the list of services that we desired. I'd say = we wanted and tried to capture "allow the transport layer to figure out" = with "discover the availability... how to select and engage a = protocol...". Again, glad to get phrasing suggestions! Cheers, Michael From nobody Sat Jun 7 02:03:12 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582D01A031D for ; Sat, 7 Jun 2014 02:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 ezO6_8MFnAje for ; Sat, 7 Jun 2014 02:03:07 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CADC1A0319 for ; Sat, 7 Jun 2014 02:03:07 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WtCWX-0005mT-Ro; Sat, 07 Jun 2014 11:02:49 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WtCWX-0001Q1-2j; Sat, 07 Jun 2014 11:02:49 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_5293A8C7-ED26-4ECD-B602-CEACD7A1DC15" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: Date: Sat, 7 Jun 2014 11:02:39 +0200 Message-Id: <4A293128-F511-42D2-AC2C-4C94E45AF54D@ifi.uio.no> References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> <20140604050204.p5a00h7lusccggw8@webmail.mit.edu> <4A95BA014132FF49AE685FAB4B9F17F645D2DE6D@dfweml701-chm.china.huawei.com> <457B55E5-6B64-4955-90DD-B2B40FF3D6E8@ifi.uio.no> <538F585F.2030606@gmail.com> <35C1DB85-E82C-4E2E-8621-6C1ECA338889@trammell.ch> <5390A0E8.9050003@gmail.com> To: Barry Leiba X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 1 sum rcpts/h 13 sum msgs/h 4 total rcpts 17494 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 0E81D3887E16A8988CA13D70897AC7EB7A81AFFA X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1567 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/5E8dmOHD7dcUWyYhHNySggJibFg Cc: Linda Dunbar , Spencer Dawkins , Joe Hildebrand , Brian Trammell , Marie-Jose Montpetit , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 09:03:10 -0000 --Apple-Mail=_5293A8C7-ED26-4ECD-B602-CEACD7A1DC15 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Ok, I will give it a try myself. See below: On 6. juni 2014, at 00:36, Michael Welzl wrote: > (snip) >=20 > On 5. juni 2014, at 22:52, Barry Leiba = wrote: (snip) >> I don't really understand what work item 2 is trying to say, and how >> it's a distinct work item from number 1. Maybe it should be merged >> with 1, or rephrased to make the distinction clear. >=20 > In my interpretation (and I hope that's the general view here?), #2 is = a shortened list of #1 - just the useful stuff that we really recommend = providing, not the complete list of absolutely all combinations of = things, no matter how strange or useless. I'd be glad to get suggestions = (from you or anybody else) on making that clearer in the text. Here goes a proposal for item #2: OLD specify a set of transport services that end systems supporting TAPS = need to provide and provide guidance on choosing among available = mechanisms and protocols to obtain a given transport service. END NEW specify a shorter set of transport services that end systems supporting = TAPS need to provide and provide guidance on choosing among available = mechanisms and protocols to obtain a given transport service. END The only change is that I inserted "shorter", but maybe that's enough to = clarify the relationship to item #1? >> For item 3, I thought we were going for more than discovery, and = meant >> to specify an experimental mechanism for specifying the services that >> were desired, and allow the transport layer to figure out how to >> provide those services. No? >=20 > So, item #2 is meant to be the list of services that we desired. I'd = say we wanted and tried to capture "allow the transport layer to figure = out" with "discover the availability... how to select and engage a = protocol...". Again, glad to get phrasing suggestions! My proposal for item #3: OLD specify experimental mechanisms to discover the availability of = protocols on an interface (both end system and path support), in order = to provide a basis for incremental deployment. This will explain how to = select and engage a protocol to deliver a transport service. END NEW specify experimental mechanisms to deliver a transport service. This = will explain how to select and engage a protocol, and how to discover = the availability of protocols on an interface (both end system and path = support), in order to provide a basis for incremental deployment. END The intention is to more clearly say - with the first sentence - that we = want to let the transport layer "figure out how to provide these = services". The rest is just a rearrangement of the old text, no new = words were introduced (and no animals harmed) :-) Thoughts? Cheers, Michael --Apple-Mail=_5293A8C7-ED26-4ECD-B602-CEACD7A1DC15 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Ok, I = will give it a try myself. See = below:


On 6. juni 2014, at 00:36, = Michael Welzl <michawe@ifi.uio.no> = wrote:

(snip)

On 5. juni 2014, at = 22:52, Barry Leiba <barryleiba@computer.org> = wrote:

(snip)


I don't really understand what work item = 2 is trying to say, and how
it's a distinct work item from number 1. =  Maybe it should be merged
with 1, or rephrased to make the = distinction clear.

In my interpretation (and I hope = that's the general view here?), #2 is a shortened list of #1 - just the = useful stuff that we really recommend providing, not the complete list = of absolutely all combinations of things, no matter how strange or = useless. I'd be glad to get suggestions (from you or anybody else) on = making that clearer in the = text.

Here goes a proposal for = item #2:

OLD
specify a set of = transport services that end systems supporting TAPS need to provide = and provide guidance on choosing among available mechanisms and = protocols to obtain a given transport = service.
END

NEW
specif= y a shorter set of transport services that end systems supporting = TAPS need to provide and provide guidance on choosing among = available mechanisms and protocols to obtain a given transport = service.
END

The only change is that I = inserted "shorter", but maybe that's enough to clarify the relationship = to item #1?


For item 3, I = thought we were going for more than discovery, and meant
to specify = an experimental mechanism for specifying the services that
were = desired, and allow the transport layer to figure out how to
provide = those services.  No?

So, item #2 is meant to be = the list of services that we desired. I'd say we wanted and tried to = capture "allow the transport layer to figure out" with "discover the = availability... how to select and engage a protocol...". Again, glad to = get phrasing suggestions!

My = proposal for item = #3:

OLD
specify experimental = mechanisms to discover the availability of protocols on an interface = (both end system and path support), in order to provide a basis for = incremental deployment. This will explain how to select and engage a = protocol to deliver a transport = service.
END

NEW
specify = experimental mechanisms to deliver a transport service. This will = explain how to select and engage a protocol, and how to discover the = availability of protocols on an interface (both end system and path = support), in order to provide a basis for incremental = deployment.
END

The intention is to = more clearly say - with the first sentence - that we want to let the = transport layer "figure out how to provide these services". The rest is = just a rearrangement of the old text, no new words were introduced (and = no animals harmed)   = :-)

Thoughts?

Cheers,
Michael

= --Apple-Mail=_5293A8C7-ED26-4ECD-B602-CEACD7A1DC15-- From nobody Sat Jun 7 07:20:41 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B801A00D7 for ; Sat, 7 Jun 2014 07:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 fbO5dm0dwHPe for ; Sat, 7 Jun 2014 07:20:34 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC9961A00C3 for ; Sat, 7 Jun 2014 07:20:34 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id la4so4565895vcb.28 for ; Sat, 07 Jun 2014 07:20:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Mt4EPp/9Y6oHzHrH4qHAgdhgV4eP3IaQwRLkLXVECvE=; b=OkDx0p62TBy4o3J115P/+y3gY2TFzidaP5Df5JFPd+8ntPzQCEsZCkzq/a1/Jclnsb 0F7MWUiH++FNFe4XlVOhieLBgKwj1V0EwgkhsT0ktX1PWd3ao3akRMQI5tXZq9KUAz+h idCiNFtk6gCK25Bt+wRHJkt8NkAuy6N+3c9BemP/UnQViWy4RQfQLcnpbeEfDm9NmNs0 wAUFyoZnGqy7HWW3TmLkevZvNOb+pbwnwA/g8Zq9QXZm/uIp0inkBSbK4fTcc6mRAyKn OYt3eUxpY6rk0udfnULQ62znUaEMrb/xt/XH2zx4H8XE9hnl9Qgo9tuw0dkZ9D7UBDO5 noXA== MIME-Version: 1.0 X-Received: by 10.221.5.1 with SMTP id oe1mr13507130vcb.10.1402150826278; Sat, 07 Jun 2014 07:20:26 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.33.199 with HTTP; Sat, 7 Jun 2014 07:20:26 -0700 (PDT) In-Reply-To: <4A293128-F511-42D2-AC2C-4C94E45AF54D@ifi.uio.no> References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> <20140604050204.p5a00h7lusccggw8@webmail.mit.edu> <4A95BA014132FF49AE685FAB4B9F17F645D2DE6D@dfweml701-chm.china.huawei.com> <457B55E5-6B64-4955-90DD-B2B40FF3D6E8@ifi.uio.no> <538F585F.2030606@gmail.com> <35C1DB85-E82C-4E2E-8621-6C1ECA338889@trammell.ch> <5390A0E8.9050003@gmail.com> <4A293128-F511-42D2-AC2C-4C94E45AF54D@ifi.uio.no> Date: Sat, 7 Jun 2014 10:20:26 -0400 X-Google-Sender-Auth: rGomsMRfmWF5-CqPNjd1o9UTxDY Message-ID: From: Barry Leiba To: Michael Welzl Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/W5OBPHlpXFRpDd0xidS5qL1UlWg Cc: Linda Dunbar , Spencer Dawkins , Joe Hildebrand , Brian Trammell , Marie-Jose Montpetit , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 14:20:36 -0000 > Ok, I will give it a try myself. Yes, sorry: I was in httpbis meetings for a couple of days, and was distracted from other things by that. > Here goes a proposal for item #2: > > OLD > specify a set of transport services that end systems supporting TAPS need to > provide and provide guidance on choosing among available mechanisms and > protocols to obtain a given transport service. > END > > NEW > specify a shorter set of transport services that end systems supporting TAPS > need to provide and provide guidance on choosing among available mechanisms > and protocols to obtain a given transport service. > END > > The only change is that I inserted "shorter", but maybe that's enough to > clarify the relationship to item #1? Maybe... Or maybe "specify a subset of those services identified in item 1, which end systems..." Does that work for you? I think it does for me. > My proposal for item #3: > > OLD > specify experimental mechanisms to discover the availability of protocols on > an interface (both end system and path support), in order to provide a basis > for incremental deployment. This will explain how to select and engage a > protocol to deliver a transport service. > END > > NEW > specify experimental mechanisms to deliver a transport service. This will > explain how to select and engage a protocol, and how to discover the > availability of protocols on an interface (both end system and path > support), in order to provide a basis for incremental deployment. > END > > The intention is to more clearly say - with the first sentence - that we > want to let the transport layer "figure out how to provide these services". > The rest is just a rearrangement of the old text, no new words were > introduced (and no animals harmed) :-) I like that change; thanks. Barry From nobody Sat Jun 7 15:26:54 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52EF1A023A for ; Sat, 7 Jun 2014 15:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 LsXfvYEnm6UV for ; Sat, 7 Jun 2014 15:26:50 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 444A11A0228 for ; Sat, 7 Jun 2014 15:26:50 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WtP3Z-0003if-2l; Sun, 08 Jun 2014 00:25:45 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WtP3Y-0008MQ-GH; Sun, 08 Jun 2014 00:25:44 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: Date: Sun, 8 Jun 2014 00:25:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> <20140604050204.p5a00h7lusccggw8@webmail.mit.edu> <4A95BA014132FF49AE685FAB4B9F17F645D2DE6D@dfweml701-chm.china.huawei.com> <457B55E5-6B64-4955-90DD-B2B40FF3D6E8@ifi.uio.no> <538F585F.2030606@gmail.com> <35C1DB85-E82C-4E2E-8621-6C1ECA338889@trammell.ch> <5390A0E8.9050003@gmail.com> <4A293128-F511-42D2-AC2C-4C94E45AF54D@ifi.uio.no> To: Barry Leiba X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 2 sum rcpts/h 12 sum msgs/h 3 total rcpts 17510 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 75805E36A30EC5F757A297B31D6BCEDC22BA46DD X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1574 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/3A1nq6deug70miZfRaMbSuxnkYU Cc: Linda Dunbar , Spencer Dawkins , Joe Hildebrand , Brian Trammell , Marie-Jose Montpetit , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jun 2014 22:26:52 -0000 On 7. juni 2014, at 16:20, Barry Leiba wrote: >> Ok, I will give it a try myself. >=20 > Yes, sorry: I was in httpbis meetings for a couple of days, and was > distracted from other things by that. No worries! >> Here goes a proposal for item #2: >>=20 >> OLD >> specify a set of transport services that end systems supporting TAPS = need to >> provide and provide guidance on choosing among available mechanisms = and >> protocols to obtain a given transport service. >> END >>=20 >> NEW >> specify a shorter set of transport services that end systems = supporting TAPS >> need to provide and provide guidance on choosing among available = mechanisms >> and protocols to obtain a given transport service. >> END >>=20 >> The only change is that I inserted "shorter", but maybe that's enough = to >> clarify the relationship to item #1? >=20 > Maybe... > Or maybe "specify a subset of those services identified in item 1, > which end systems..." >=20 > Does that work for you? I think it does for me. It does for me, too. Others? List? >> My proposal for item #3: >>=20 >> OLD >> specify experimental mechanisms to discover the availability of = protocols on >> an interface (both end system and path support), in order to provide = a basis >> for incremental deployment. This will explain how to select and = engage a >> protocol to deliver a transport service. >> END >>=20 >> NEW >> specify experimental mechanisms to deliver a transport service. This = will >> explain how to select and engage a protocol, and how to discover the >> availability of protocols on an interface (both end system and path >> support), in order to provide a basis for incremental deployment. >> END >>=20 >> The intention is to more clearly say - with the first sentence - that = we >> want to let the transport layer "figure out how to provide these = services". >> The rest is just a rearrangement of the old text, no new words were >> introduced (and no animals harmed) :-) >=20 > I like that change; thanks. Cool. Others? List? Cheers, Michael From nobody Tue Jun 10 00:05:47 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CF71A0439 for ; Tue, 10 Jun 2014 00:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 5kyyvdEgIsIi for ; Tue, 10 Jun 2014 00:05:43 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59EA31A0426 for ; Tue, 10 Jun 2014 00:05:43 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WuG7f-0004h4-Gv; Tue, 10 Jun 2014 09:05:31 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WuG7e-0001ng-Vc; Tue, 10 Jun 2014 09:05:31 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_8759FF55-1643-4014-B778-BC5102BEAC4D" From: Michael Welzl In-Reply-To: Date: Tue, 10 Jun 2014 09:05:27 +0200 Message-Id: <97DCE482-AA77-44A7-9710-E1933781E53E@ifi.uio.no> References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> <20140604050204.p5a00h7lusccggw8@webmail.mit.edu> <4A95BA014132FF49AE685FAB4B9F17F645D2DE6D@dfweml701-chm.china.huawei.com> <457B55E5-6B64-4955-90DD-B2B40FF3D6E8@ifi.uio.no> <538F585F.2030606@gmail.com> <35C1DB85-E82C-4E2E-8621-6C1ECA338889@trammell.ch> <5390A0E8.9050003@gmail.com> <4A293128-F511-42D2-AC2C-4C94E45AF54D@ifi.uio.no> To: Barry Leiba X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 2 sum rcpts/h 13 sum msgs/h 2 total rcpts 17546 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B363536F6DE8907917FFB4764E1E4A8EDE3FC687 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 5568 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/P8vyPx0EHX6HLQHJ8ozLbWklsvk Cc: Linda Dunbar , Spencer Dawkins , Joe Hildebrand , Brian Trammell , Marie-Jose Montpetit , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2014 07:05:46 -0000 --Apple-Mail=_8759FF55-1643-4014-B778-BC5102BEAC4D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I have now applied these comments at: https://sites.google.com/site/transportprotocolservices/charter-proposal Any more comments? Anyone? Cheers, Michael On 8. juni 2014, at 00:25, Michael Welzl wrote: >=20 > On 7. juni 2014, at 16:20, Barry Leiba = wrote: >=20 >>> Ok, I will give it a try myself. >>=20 >> Yes, sorry: I was in httpbis meetings for a couple of days, and was >> distracted from other things by that. >=20 > No worries! >=20 >=20 >>> Here goes a proposal for item #2: >>>=20 >>> OLD >>> specify a set of transport services that end systems supporting TAPS = need to >>> provide and provide guidance on choosing among available mechanisms = and >>> protocols to obtain a given transport service. >>> END >>>=20 >>> NEW >>> specify a shorter set of transport services that end systems = supporting TAPS >>> need to provide and provide guidance on choosing among available = mechanisms >>> and protocols to obtain a given transport service. >>> END >>>=20 >>> The only change is that I inserted "shorter", but maybe that's = enough to >>> clarify the relationship to item #1? >>=20 >> Maybe... >> Or maybe "specify a subset of those services identified in item 1, >> which end systems..." >>=20 >> Does that work for you? I think it does for me. >=20 > It does for me, too. >=20 > Others? List? >=20 >=20 >>> My proposal for item #3: >>>=20 >>> OLD >>> specify experimental mechanisms to discover the availability of = protocols on >>> an interface (both end system and path support), in order to provide = a basis >>> for incremental deployment. This will explain how to select and = engage a >>> protocol to deliver a transport service. >>> END >>>=20 >>> NEW >>> specify experimental mechanisms to deliver a transport service. This = will >>> explain how to select and engage a protocol, and how to discover the >>> availability of protocols on an interface (both end system and path >>> support), in order to provide a basis for incremental deployment. >>> END >>>=20 >>> The intention is to more clearly say - with the first sentence - = that we >>> want to let the transport layer "figure out how to provide these = services". >>> The rest is just a rearrangement of the old text, no new words were >>> introduced (and no animals harmed) :-) >>=20 >> I like that change; thanks. >=20 > Cool. Others? List? >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_8759FF55-1643-4014-B778-BC5102BEAC4D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii https://sites.google.com/site/transportprotocolservices/charter-pr= oposal

Any more comments? = Anyone?

Cheers,
Michael

<= /div>


On 8. juni 2014, at 00:25, = Michael Welzl wrote:


On = 7. juni 2014, at 16:20, Barry Leiba <barryleiba@computer.org> = wrote:

Ok, I = will give it a try myself.

Yes, sorry: I = was in httpbis meetings for a couple of days, and = was
distracted from other = things by that.

No worries!


Here goes a proposal for item = #2:

OLD
specify a set of transport = services that end systems supporting TAPS need = to
provide and provide guidance on choosing among available = mechanisms and
protocols to obtain a given = transport service.
END

NEW
specify a shorter set of = transport services that end systems supporting = TAPS
need to provide and provide guidance on choosing among = available mechanisms
and protocols to obtain a given = transport service.
END

The only change is that I = inserted "shorter", but maybe that's enough = to
clarify the relationship to item = #1?

Maybe...
Or = maybe "specify a subset of those services identified in item = 1,
which end = systems..."

Does that work = for you?  I think it does for me.

It does for = me, too.

Others? List?


My proposal for item = #3:

OLD
specify experimental mechanisms = to discover the availability of protocols = on
an interface (both end system and path support), in order = to provide a basis
for incremental deployment. This = will explain how to select and engage = a
protocol to deliver a transport = service.
END

NEW
specify experimental mechanisms = to deliver a transport service. This = will
explain how to select and engage a protocol, and how to = discover the
availability of protocols on an = interface (both end system and = path
support), in order to provide a basis for incremental = deployment.
END

The intention is to more clearly = say - with the first sentence - that = we
want to let the transport layer "figure out how to provide = these services".
The rest is just a rearrangement = of the old text, no new words = were
introduced (and no animals harmed) =   :-)

I like that = change; thanks.

Cool. Others? = List?

Cheers,
Michael

___________________________________= ____________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/ma= ilman/listinfo/taps

= --Apple-Mail=_8759FF55-1643-4014-B778-BC5102BEAC4D-- From nobody Wed Jun 11 00:11:23 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D961B2828 for ; Wed, 11 Jun 2014 00:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 Syje8wMT-jsL for ; Wed, 11 Jun 2014 00:11:02 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 067E21A03E4 for ; Wed, 11 Jun 2014 00:11:02 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WucgW-00074b-7d for taps@ietf.org; Wed, 11 Jun 2014 09:11:00 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WucgV-0000ru-KC for taps@ietf.org; Wed, 11 Jun 2014 09:11:00 +0200 From: Michael Welzl Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_0BD5331E-0E79-4B22-9167-55AEABCE2ADA" Date: Wed, 11 Jun 2014 09:10:58 +0200 In-Reply-To: <97DCE482-AA77-44A7-9710-E1933781E53E@ifi.uio.no> To: taps@ietf.org References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> <20140604050204.p5a00h7lusccggw8@webmail.mit.edu> <4A95BA014132FF49AE685FAB4B9F17F645D2DE6D@dfweml701-chm.china.huawei.com> <457B55E5-6B64-4955-90DD-B2B40FF3D6E8@ifi.uio.no> <538F585F.2030606@gmail.com> <35C1DB85-E82C-4E2E-8621-6C1ECA338889@trammell.ch> <5390A0E8.9050003@gmail.com> <4A293128-F511-42D2-AC2C-4C94E45AF54D@ifi.uio.no> <97DCE482-AA77-44A7-9710-E1933781E53E@ifi.uio.no> Message-Id: <08354C41-1F72-4C4C-BC24-F445C7D6956E@ifi.uio.no> X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 2 sum rcpts/h 3 sum msgs/h 3 total rcpts 17564 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: AD3525C96C9A8165019AF4304B57429F80501B5A X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 5583 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/fqFEenIAL3UPcuaU1fuuIE-nzZ4 Subject: [Taps] LAST CALL: charter ready to ship? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 07:11:21 -0000 --Apple-Mail=_0BD5331E-0E79-4B22-9167-55AEABCE2ADA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Unless someone comments by the end of tomorrow, 12 June, I will consider = the charter final from the point of view of the WG and ship it to = Spencer. Cheers, Michael On 10. juni 2014, at 09:05, Michael Welzl wrote: > Hi, >=20 > I have now applied these comments at: > = https://sites.google.com/site/transportprotocolservices/charter-proposal >=20 > Any more comments? Anyone? >=20 > Cheers, > Michael >=20 >=20 >=20 > On 8. juni 2014, at 00:25, Michael Welzl wrote: >=20 >>=20 >> On 7. juni 2014, at 16:20, Barry Leiba = wrote: >>=20 >>>> Ok, I will give it a try myself. >>>=20 >>> Yes, sorry: I was in httpbis meetings for a couple of days, and was >>> distracted from other things by that. >>=20 >> No worries! >>=20 >>=20 >>>> Here goes a proposal for item #2: >>>>=20 >>>> OLD >>>> specify a set of transport services that end systems supporting = TAPS need to >>>> provide and provide guidance on choosing among available mechanisms = and >>>> protocols to obtain a given transport service. >>>> END >>>>=20 >>>> NEW >>>> specify a shorter set of transport services that end systems = supporting TAPS >>>> need to provide and provide guidance on choosing among available = mechanisms >>>> and protocols to obtain a given transport service. >>>> END >>>>=20 >>>> The only change is that I inserted "shorter", but maybe that's = enough to >>>> clarify the relationship to item #1? >>>=20 >>> Maybe... >>> Or maybe "specify a subset of those services identified in item 1, >>> which end systems..." >>>=20 >>> Does that work for you? I think it does for me. >>=20 >> It does for me, too. >>=20 >> Others? List? >>=20 >>=20 >>>> My proposal for item #3: >>>>=20 >>>> OLD >>>> specify experimental mechanisms to discover the availability of = protocols on >>>> an interface (both end system and path support), in order to = provide a basis >>>> for incremental deployment. This will explain how to select and = engage a >>>> protocol to deliver a transport service. >>>> END >>>>=20 >>>> NEW >>>> specify experimental mechanisms to deliver a transport service. = This will >>>> explain how to select and engage a protocol, and how to discover = the >>>> availability of protocols on an interface (both end system and path >>>> support), in order to provide a basis for incremental deployment. >>>> END >>>>=20 >>>> The intention is to more clearly say - with the first sentence - = that we >>>> want to let the transport layer "figure out how to provide these = services". >>>> The rest is just a rearrangement of the old text, no new words were >>>> introduced (and no animals harmed) :-) >>>=20 >>> I like that change; thanks. >>=20 >> Cool. Others? List? >>=20 >> Cheers, >> Michael >>=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 --Apple-Mail=_0BD5331E-0E79-4B22-9167-55AEABCE2ADA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi,

I = have now applied these comments at:

Any more comments? = Anyone?

Cheers,
Michael

<= /div>


On 8. juni 2014, at 00:25, = Michael Welzl wrote:


On = 7. juni 2014, at 16:20, Barry Leiba <barryleiba@computer.org> = wrote:

Ok, I = will give it a try myself.

Yes, sorry: I = was in httpbis meetings for a couple of days, and = was
distracted from other = things by that.

No worries!


Here goes a proposal for item = #2:

OLD
specify a set of transport = services that end systems supporting TAPS need = to
provide and provide guidance on choosing among available = mechanisms and
protocols to obtain a given = transport service.
END

NEW
specify a shorter set of = transport services that end systems supporting = TAPS
need to provide and provide guidance on choosing among = available mechanisms
and protocols to obtain a given = transport service.
END

The only change is that I = inserted "shorter", but maybe that's enough = to
clarify the relationship to item = #1?

Maybe...
Or = maybe "specify a subset of those services identified in item = 1,
which end = systems..."

Does that work = for you?  I think it does for me.

It does for = me, too.

Others? List?


My proposal for item = #3:

OLD
specify experimental mechanisms = to discover the availability of protocols = on
an interface (both end system and path support), in order = to provide a basis
for incremental deployment. This = will explain how to select and engage = a
protocol to deliver a transport = service.
END

NEW
specify experimental mechanisms = to deliver a transport service. This = will
explain how to select and engage a protocol, and how to = discover the
availability of protocols on an = interface (both end system and = path
support), in order to provide a basis for incremental = deployment.
END

The intention is to more clearly = say - with the first sentence - that = we
want to let the transport layer "figure out how to provide = these services".
The rest is just a rearrangement = of the old text, no new words = were
introduced (and no animals harmed) =   :-)

I like that = change; thanks.

Cool. Others? = List?

Cheers,
Michael

___________________________________= ____________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/m= ailman/listinfo/taps

_____= __________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/ma= ilman/listinfo/taps

= --Apple-Mail=_0BD5331E-0E79-4B22-9167-55AEABCE2ADA-- From nobody Wed Jun 11 00:23:10 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33721A03DB for ; Wed, 11 Jun 2014 00:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 GTAa5O_Bypwx for ; Wed, 11 Jun 2014 00:23:02 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 415621A04A3 for ; Wed, 11 Jun 2014 00:23:02 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2::2] (unknown [IPv6:2001:470:26:9c2::2]) by trammell.ch (Postfix) with ESMTPSA id 0F0B51A0A55; Wed, 11 Jun 2014 09:22:29 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_40CABCC7-7785-4793-B16B-620BE3EE740F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Brian Trammell In-Reply-To: <08354C41-1F72-4C4C-BC24-F445C7D6956E@ifi.uio.no> Date: Wed, 11 Jun 2014 09:22:27 +0200 Message-Id: References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> <20140604050204.p5a00h7lusccggw8@webmail.mit.edu> <4A95BA014132FF49AE685FAB4B9F17F645D2DE6D@dfweml701-chm.china.huawei.com> <457B55E5-6B64-4955-90DD-B2B40FF3D6E8@ifi.uio.no> <538F585F.2030606@gmail.com> <35C1DB85-E82C-4E2E-8621-6C1ECA338889@trammell.ch> <5390A0E8.9050003@gmail.com> <4A293128-F511-42D2-AC2C-4C94E45AF54D@ifi.uio.no> <97DCE482-AA77-44A7-9710-E1933781E53E@ifi.uio.no> <08354C41-1F72-4C4C-BC24-F445C7D6956E@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/-qNRBPD_toirUeqTi4E2nIxl-Ew Cc: taps@ietf.org Subject: Re: [Taps] LAST CALL: charter ready to ship? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 07:23:05 -0000 --Apple-Mail=_40CABCC7-7785-4793-B16B-620BE3EE740F Content-Type: multipart/alternative; boundary="Apple-Mail=_E4E11D2C-55B7-456E-AB03-33A6263966D6" --Apple-Mail=_E4E11D2C-55B7-456E-AB03-33A6263966D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Michael, It looks good to me. Thanks a lot for driving this forward! Cheers, Brian On 11 Jun 2014, at 09:10, Michael Welzl wrote: > Hi, >=20 > Unless someone comments by the end of tomorrow, 12 June, I will = consider the charter final from the point of view of the WG and ship it = to Spencer. >=20 > Cheers, > Michael >=20 >=20 > On 10. juni 2014, at 09:05, Michael Welzl wrote: >=20 >> Hi, >>=20 >> I have now applied these comments at: >> = https://sites.google.com/site/transportprotocolservices/charter-proposal >>=20 >> Any more comments? Anyone? >>=20 >> Cheers, >> Michael >>=20 >>=20 >>=20 >> On 8. juni 2014, at 00:25, Michael Welzl wrote: >>=20 >>>=20 >>> On 7. juni 2014, at 16:20, Barry Leiba = wrote: >>>=20 >>>>> Ok, I will give it a try myself. >>>>=20 >>>> Yes, sorry: I was in httpbis meetings for a couple of days, and was >>>> distracted from other things by that. >>>=20 >>> No worries! >>>=20 >>>=20 >>>>> Here goes a proposal for item #2: >>>>>=20 >>>>> OLD >>>>> specify a set of transport services that end systems supporting = TAPS need to >>>>> provide and provide guidance on choosing among available = mechanisms and >>>>> protocols to obtain a given transport service. >>>>> END >>>>>=20 >>>>> NEW >>>>> specify a shorter set of transport services that end systems = supporting TAPS >>>>> need to provide and provide guidance on choosing among available = mechanisms >>>>> and protocols to obtain a given transport service. >>>>> END >>>>>=20 >>>>> The only change is that I inserted "shorter", but maybe that's = enough to >>>>> clarify the relationship to item #1? >>>>=20 >>>> Maybe... >>>> Or maybe "specify a subset of those services identified in item 1, >>>> which end systems..." >>>>=20 >>>> Does that work for you? I think it does for me. >>>=20 >>> It does for me, too. >>>=20 >>> Others? List? >>>=20 >>>=20 >>>>> My proposal for item #3: >>>>>=20 >>>>> OLD >>>>> specify experimental mechanisms to discover the availability of = protocols on >>>>> an interface (both end system and path support), in order to = provide a basis >>>>> for incremental deployment. This will explain how to select and = engage a >>>>> protocol to deliver a transport service. >>>>> END >>>>>=20 >>>>> NEW >>>>> specify experimental mechanisms to deliver a transport service. = This will >>>>> explain how to select and engage a protocol, and how to discover = the >>>>> availability of protocols on an interface (both end system and = path >>>>> support), in order to provide a basis for incremental deployment. >>>>> END >>>>>=20 >>>>> The intention is to more clearly say - with the first sentence - = that we >>>>> want to let the transport layer "figure out how to provide these = services". >>>>> The rest is just a rearrangement of the old text, no new words = were >>>>> introduced (and no animals harmed) :-) >>>>=20 >>>> I like that change; thanks. >>>=20 >>> Cool. Others? List? >>>=20 >>> Cheers, >>> Michael >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_E4E11D2C-55B7-456E-AB03-33A6263966D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii hi = Michael,

It looks good to me. Thanks a lot for = driving this = forward!

Cheers,

Brian

On 11 Jun 2014, at 09:10, Michael Welzl <michawe@ifi.uio.no> = wrote:

Hi,

I = have now applied these comments at:

Any more comments? = Anyone?

Cheers,
Michael

<= /div>


On 8. juni 2014, at 00:25, = Michael Welzl wrote:


On 7. = juni 2014, at 16:20, Barry Leiba <barryleiba@computer.org> = wrote:

Ok, I = will give it a try myself.

Yes, sorry: I = was in httpbis meetings for a couple of days, and = was
distracted from other = things by that.

No worries!


Here goes a proposal for item = #2:

OLD
specify a set of transport = services that end systems supporting TAPS need = to
provide and provide guidance on choosing among available = mechanisms and
protocols to obtain a given = transport service.
END

NEW
specify a shorter set of = transport services that end systems supporting = TAPS
need to provide and provide guidance on choosing among = available mechanisms
and protocols to obtain a given = transport service.
END

The only change is that I = inserted "shorter", but maybe that's enough = to
clarify the relationship to item = #1?

Maybe...
Or = maybe "specify a subset of those services identified in item = 1,
which end = systems..."

Does that work = for you?  I think it does for me.

It does for = me, too.

Others? List?


My proposal for item = #3:

OLD
specify experimental mechanisms = to discover the availability of protocols = on
an interface (both end system and path support), in order = to provide a basis
for incremental deployment. This = will explain how to select and engage = a
protocol to deliver a transport = service.
END

NEW
specify experimental mechanisms = to deliver a transport service. This = will
explain how to select and engage a protocol, and how to = discover the
availability of protocols on an = interface (both end system and = path
support), in order to provide a basis for incremental = deployment.
END

The intention is to more clearly = say - with the first sentence - that = we
want to let the transport layer "figure out how to provide = these services".
The rest is just a rearrangement = of the old text, no new words = were
introduced (and no animals harmed) =   :-)

I like that = change; thanks.

Cool. Others? = List?

Cheers,
Michael

___________________________________= ____________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/m= ailman/listinfo/taps

___________= ____________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/m= ailman/listinfo/taps

___________= ____________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/ma= ilman/listinfo/taps

= --Apple-Mail=_E4E11D2C-55B7-456E-AB03-33A6263966D6-- --Apple-Mail=_40CABCC7-7785-4793-B16B-620BE3EE740F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTmAOzAAoJENt3nsOmbNJcE8QH/20m3BDYFKAO81TRMEtzOP7E C22KTlFE1t1+RYOCEHgN3sZb+eAinnyC1/0dp9pjrXb7Wd7djo2boDpeu/J5KGju J+T4fNCH8WcXUZAAQ7hx9DOhoOjBspxkrYAPymzk3PxqbDKdxmDmiBZ234XxoLqw TJin4RMGNjPKe/H1bJQAyiMGFhpHXiQiuuZstO8I1AKyDzEart5PYWn2g9bH6Buk zuWx4spRlQihAhxCUCgKzNzRWIpej+Zqmn3cVvPzqZp6Xf78SLiRo+7g9VMJrLj7 1NR7fcUGmbVTVQXAOOr1hkGHR9j493eYny05BNzMTGFR3TLwwRn8PyrrZ5fJTGw= =cwav -----END PGP SIGNATURE----- --Apple-Mail=_40CABCC7-7785-4793-B16B-620BE3EE740F-- From nobody Wed Jun 11 07:21:55 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510251A0564 for ; Wed, 11 Jun 2014 07:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 L9jkpFlQ09Nx for ; Wed, 11 Jun 2014 07:21:51 -0700 (PDT) Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (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 684CD1A055D for ; Wed, 11 Jun 2014 07:21:51 -0700 (PDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1WujPQ-0006Pi-HU for ; Wed, 11 Jun 2014 16:21:48 +0200 Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by vorta.tm.kit.edu (Postfix) with ESMTPS id 8814BA80126 for ; Wed, 11 Jun 2014 16:21:49 +0200 (CEST) Message-ID: <539865FD.3000301@kit.edu> Date: Wed, 11 Jun 2014 16:21:49 +0200 From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: taps@ietf.org References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> <20140604050204.p5a00h7lusccggw8@webmail.mit.edu> <4A95BA014132FF49AE685FAB4B9F17F645D2DE6D@dfweml701-chm.china.huawei.com> <457B55E5-6B64-4955-90DD-B2B40FF3D6E8@ifi.uio.no> <538F585F.2030606@gmail.com> <35C1DB85-E82C-4E2E-8621-6C1ECA338889@trammell.ch> <5390A0E8.9050003@gmail.com> <4A293128-F511-42D2-AC2C-4C94E45AF54D@ifi.uio.no> <97DCE482-AA77-44A7-9710-E1933781E53E@ifi.uio.no> <08354C41-1F72-4C4C-BC24-F445C7D6956E@ifi.uio.no> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1402496508. Archived-At: http://mailarchive.ietf.org/arch/msg/taps/4pM3Md0KgvhuIsN3Jkino88fONc Subject: Re: [Taps] LAST CALL: charter ready to ship? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 14:21:53 -0000 Hi, Am 11.06.2014 09:22, schrieb Brian Trammell: > It looks good to me. Thanks a lot for driving this forward! +1 Regards, Roland From nobody Thu Jun 12 02:33:40 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A683B1A037C for ; Thu, 12 Jun 2014 02:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 rdvwG19PBRFH for ; Thu, 12 Jun 2014 02:33:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3084E1B2793 for ; Thu, 12 Jun 2014 02:33:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BII56667; Thu, 12 Jun 2014 09:33:35 +0000 (GMT) Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Jun 2014 10:33:35 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.3]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Thu, 12 Jun 2014 17:33:32 +0800 From: "Liushucheng (Will)" To: "taps@ietf.org" Thread-Topic: [Taps] LAST CALL: charter ready to ship? Thread-Index: AQHPhURleJoJ6No3NkyQkkYDsBfvhptq+yaAgAB1K4CAAcJpYA== Date: Thu, 12 Jun 2014 09:33:31 +0000 Message-ID: References: <1C88E251-56E0-4712-9509-747FF4823108@trammell.ch> <20140604050204.p5a00h7lusccggw8@webmail.mit.edu> <4A95BA014132FF49AE685FAB4B9F17F645D2DE6D@dfweml701-chm.china.huawei.com> <457B55E5-6B64-4955-90DD-B2B40FF3D6E8@ifi.uio.no> <538F585F.2030606@gmail.com> <35C1DB85-E82C-4E2E-8621-6C1ECA338889@trammell.ch> <5390A0E8.9050003@gmail.com> <4A293128-F511-42D2-AC2C-4C94E45AF54D@ifi.uio.no> <97DCE482-AA77-44A7-9710-E1933781E53E@ifi.uio.no> <08354C41-1F72-4C4C-BC24-F445C7D6956E@ifi.uio.no> <539865FD.3000301@kit.edu> In-Reply-To: <539865FD.3000301@kit.edu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/taps/zwuzVHssMkyLF5DBa74wF7efKus Subject: Re: [Taps] LAST CALL: charter ready to ship? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 09:33:39 -0000 +1 Regards, Will (Shucheng LIU) > -----Original Message----- > From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of Bless, Roland > (TM) > Sent: Wednesday, June 11, 2014 10:22 PM > To: taps@ietf.org > Subject: Re: [Taps] LAST CALL: charter ready to ship? >=20 > Hi, >=20 > Am 11.06.2014 09:22, schrieb Brian Trammell: > > It looks good to me. Thanks a lot for driving this forward! >=20 > +1 >=20 > Regards, > Roland >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu Jun 12 02:43:07 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC151B27DF for ; Thu, 12 Jun 2014 02:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 FA5Gfu_E31sC for ; Thu, 12 Jun 2014 02:43:03 -0700 (PDT) Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7FA71B27DB for ; Thu, 12 Jun 2014 02:43:02 -0700 (PDT) Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id 7770C6014D; Thu, 12 Jun 2014 11:43:00 +0200 (CEST) Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id 74AB76014C; Thu, 12 Jun 2014 11:43:00 +0200 (CEST) From: Mirja Kuehlewind Organization: University of Stuttgart (Germany), IKR To: taps@ietf.org Date: Thu, 12 Jun 2014 11:43:00 +0200 User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316) References: <97DCE482-AA77-44A7-9710-E1933781E53E@ifi.uio.no> <08354C41-1F72-4C4C-BC24-F445C7D6956E@ifi.uio.no> In-Reply-To: <08354C41-1F72-4C4C-BC24-F445C7D6956E@ifi.uio.no> X-KMail-QuotePrefix: > MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201406121143.00295.mirja.kuehlewind@ikr.uni-stuttgart.de> Archived-At: http://mailarchive.ietf.org/arch/msg/taps/TJ4XDAKjE_3KO9SURhcBhar4nDg Cc: Michael Welzl Subject: Re: [Taps] LAST CALL: charter ready to ship? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 09:43:06 -0000 Hi Michael, hi all, I didn't contribute so far, but were following the discussion. You all did = a=20 really good job. Special thanks to Michael for caring! I believe the charte= r=20 is ready and I'm happy to contribute in future! Mirja On Wednesday 11 June 2014 09:10:58 Michael Welzl wrote: > Hi, > > Unless someone comments by the end of tomorrow, 12 June, I will consider > the charter final from the point of view of the WG and ship it to Spencer. > > Cheers, > Michael > > On 10. juni 2014, at 09:05, Michael Welzl wrote: > > Hi, > > > > I have now applied these comments at: > > https://sites.google.com/site/transportprotocolservices/charter-proposal > > > > Any more comments? Anyone? > > > > Cheers, > > Michael > > > > On 8. juni 2014, at 00:25, Michael Welzl wrote: > >> On 7. juni 2014, at 16:20, Barry Leiba wrote: > >>>> Ok, I will give it a try myself. > >>> > >>> Yes, sorry: I was in httpbis meetings for a couple of days, and was > >>> distracted from other things by that. > >> > >> No worries! > >> > >>>> Here goes a proposal for item #2: > >>>> > >>>> OLD > >>>> specify a set of transport services that end systems supporting TAPS > >>>> need to provide and provide guidance on choosing among available > >>>> mechanisms and protocols to obtain a given transport service. > >>>> END > >>>> > >>>> NEW > >>>> specify a shorter set of transport services that end systems > >>>> supporting TAPS need to provide and provide guidance on choosing amo= ng > >>>> available mechanisms and protocols to obtain a given transport > >>>> service. > >>>> END > >>>> > >>>> The only change is that I inserted "shorter", but maybe that's enough > >>>> to clarify the relationship to item #1? > >>> > >>> Maybe... > >>> Or maybe "specify a subset of those services identified in item 1, > >>> which end systems..." > >>> > >>> Does that work for you? I think it does for me. > >> > >> It does for me, too. > >> > >> Others? List? > >> > >>>> My proposal for item #3: > >>>> > >>>> OLD > >>>> specify experimental mechanisms to discover the availability of > >>>> protocols on an interface (both end system and path support), in ord= er > >>>> to provide a basis for incremental deployment. This will explain how > >>>> to select and engage a protocol to deliver a transport service. > >>>> END > >>>> > >>>> NEW > >>>> specify experimental mechanisms to deliver a transport service. This > >>>> will explain how to select and engage a protocol, and how to discover > >>>> the availability of protocols on an interface (both end system and > >>>> path support), in order to provide a basis for incremental deploymen= t. > >>>> END > >>>> > >>>> The intention is to more clearly say - with the first sentence - that > >>>> we want to let the transport layer "figure out how to provide these > >>>> services". The rest is just a rearrangement of the old text, no new > >>>> words were introduced (and no animals harmed) :-) > >>> > >>> I like that change; thanks. > >> > >> Cool. Others? List? > >> > >> Cheers, > >> Michael > >> > >> _______________________________________________ > >> 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 =2D-=20 =2D------------------------------------------------------------------ Dipl.-Ing. Mirja K=FChlewind Institute of Communication Networks and Computer Engineering (IKR) University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart tel: +49(0)711/685-67973 email: mirja.kuehlewind@ikr.uni-stuttgart.de web: www.ikr.uni-stuttgart.de =2D------------------------------------------------------------------ From nobody Thu Jun 12 03:12:46 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4011B2833 for ; Thu, 12 Jun 2014 03:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 m3PT8Ay4HhTW for ; Thu, 12 Jun 2014 03:12:40 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2852A1B2830 for ; Thu, 12 Jun 2014 03:12:39 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z12so988337wgg.25 for ; Thu, 12 Jun 2014 03:12:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=HPeTtLG/QPN2teJgQS1Es/nh5voCKKUgj4lXsGkjKYk=; b=aXgzRjWyjeL6QJeIxDEM7mlDWtzahg4qpmJib4cjidRiPziheNYcVT9G0uflpz3EFF +maVLzp0i/igQgPSpz1rdF9CcfTrSao+BIVLnZSifb7vZCZZTRbHuiTH5wMsUfl4wbkF 3ptmbNzOtpxFNy2X2ZqHtyJct0JoNLG6LwAN1aMtf3iT9fZdtjroi2BKuiHSNl/s+bkM yTpk31PM64KwDRnVJfgpUrXtehgZuKs1fSn1nGFKFWdstG3r9w3U1TssLsNjDOkxn5UK e247f22MZ+/2aH/282DOo/a0foZsrxkXEQk0XhfVXz45N3C2juflOdhNZtN4s0LbXLOk 6g9w== X-Gm-Message-State: ALoCoQlR8mJ/QpIZqeFORGREfU8TIZE0l8aMRK9Qh2HFDQPRGwbSqPcno7XQ4uHJKaSmO5V3AxUr X-Received: by 10.194.110.10 with SMTP id hw10mr32812217wjb.81.1402567958625; Thu, 12 Jun 2014 03:12:38 -0700 (PDT) Received: from [192.168.202.156] ([77.88.71.157]) by mx.google.com with ESMTPSA id o46sm3861223eef.31.2014.06.12.03.12.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 03:12:37 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: David Ros In-Reply-To: <201406121143.00295.mirja.kuehlewind@ikr.uni-stuttgart.de> Date: Thu, 12 Jun 2014 12:12:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <950BF072-EA80-4657-9718-92A9F4A6AF1A@simula.no> References: <97DCE482-AA77-44A7-9710-E1933781E53E@ifi.uio.no> <08354C41-1F72-4C4C-BC24-F445C7D6956E@ifi.uio.no> <201406121143.00295.mirja.kuehlewind@ikr.uni-stuttgart.de> To: Michael Welzl X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/2ucGsTOtV6A7CQCotxTJ-dBQee8 Cc: taps@ietf.org Subject: Re: [Taps] LAST CALL: charter ready to ship? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 10:12:42 -0000 On 12 Jun 2014, at 11:43, Mirja Kuehlewind = wrote: > Hi Michael, hi all, >=20 > I didn't contribute so far, but were following the discussion. You all = did a=20 > really good job. Special thanks to Michael for caring! I believe the = charter=20 > is ready and I'm happy to contribute in future! >=20 > Mirja Hi, +1 Cheers, David >=20 >=20 > On Wednesday 11 June 2014 09:10:58 Michael Welzl wrote: >> Hi, >>=20 >> Unless someone comments by the end of tomorrow, 12 June, I will = consider >> the charter final from the point of view of the WG and ship it to = Spencer. >>=20 >> Cheers, >> Michael >>=20 >> On 10. juni 2014, at 09:05, Michael Welzl wrote: >>> Hi, >>>=20 >>> I have now applied these comments at: >>> = https://sites.google.com/site/transportprotocolservices/charter-proposal >>>=20 >>> Any more comments? Anyone? >>>=20 >>> Cheers, >>> Michael >>>=20 >>> On 8. juni 2014, at 00:25, Michael Welzl wrote: >>>> On 7. juni 2014, at 16:20, Barry Leiba = wrote: >>>>>> Ok, I will give it a try myself. >>>>>=20 >>>>> Yes, sorry: I was in httpbis meetings for a couple of days, and = was >>>>> distracted from other things by that. >>>>=20 >>>> No worries! >>>>=20 >>>>>> Here goes a proposal for item #2: >>>>>>=20 >>>>>> OLD >>>>>> specify a set of transport services that end systems supporting = TAPS >>>>>> need to provide and provide guidance on choosing among available >>>>>> mechanisms and protocols to obtain a given transport service. >>>>>> END >>>>>>=20 >>>>>> NEW >>>>>> specify a shorter set of transport services that end systems >>>>>> supporting TAPS need to provide and provide guidance on choosing = among >>>>>> available mechanisms and protocols to obtain a given transport >>>>>> service. >>>>>> END >>>>>>=20 >>>>>> The only change is that I inserted "shorter", but maybe that's = enough >>>>>> to clarify the relationship to item #1? >>>>>=20 >>>>> Maybe... >>>>> Or maybe "specify a subset of those services identified in item 1, >>>>> which end systems..." >>>>>=20 >>>>> Does that work for you? I think it does for me. >>>>=20 >>>> It does for me, too. >>>>=20 >>>> Others? List? >>>>=20 >>>>>> My proposal for item #3: >>>>>>=20 >>>>>> OLD >>>>>> specify experimental mechanisms to discover the availability of >>>>>> protocols on an interface (both end system and path support), in = order >>>>>> to provide a basis for incremental deployment. This will explain = how >>>>>> to select and engage a protocol to deliver a transport service. >>>>>> END >>>>>>=20 >>>>>> NEW >>>>>> specify experimental mechanisms to deliver a transport service. = This >>>>>> will explain how to select and engage a protocol, and how to = discover >>>>>> the availability of protocols on an interface (both end system = and >>>>>> path support), in order to provide a basis for incremental = deployment. >>>>>> END >>>>>>=20 >>>>>> The intention is to more clearly say - with the first sentence - = that >>>>>> we want to let the transport layer "figure out how to provide = these >>>>>> services". The rest is just a rearrangement of the old text, no = new >>>>>> words were introduced (and no animals harmed) :-) >>>>>=20 >>>>> I like that change; thanks. >>>>=20 >>>> Cool. Others? List? >>>>=20 >>>> Cheers, >>>> Michael >>>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >=20 >=20 >=20 > --=20 > ------------------------------------------------------------------- > Dipl.-Ing. Mirja K=FChlewind > Institute of Communication Networks and Computer Engineering (IKR) > University of Stuttgart, Germany > Pfaffenwaldring 47, D-70569 Stuttgart >=20 > tel: +49(0)711/685-67973 > email: mirja.kuehlewind@ikr.uni-stuttgart.de > web: www.ikr.uni-stuttgart.de > ------------------------------------------------------------------- >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu Jun 12 03:16:30 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443531B2833 for ; Thu, 12 Jun 2014 03:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 EA8FAIl4_mpR for ; Thu, 12 Jun 2014 03:16:25 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f41]) (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 CC2691B2830 for ; Thu, 12 Jun 2014 03:16:24 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from dhcp-172-17-153-238.eduroam.lapwing.private.cam.ac.uk ([172.17.153.238]:63587) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:587) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1Wv23R-0002uD-Sa (Exim 4.82_3-c0e5623) (return-path ); Thu, 12 Jun 2014 11:16:21 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Toby Moncaster X-Mailer: iPhone Mail (11D167) In-Reply-To: <950BF072-EA80-4657-9718-92A9F4A6AF1A@simula.no> Date: Thu, 12 Jun 2014 11:16:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <97DCE482-AA77-44A7-9710-E1933781E53E@ifi.uio.no> <08354C41-1F72-4C4C-BC24-F445C7D6956E@ifi.uio.no> <201406121143.00295.mirja.kuehlewind@ikr.uni-stuttgart.de> <950BF072-EA80-4657-9718-92A9F4A6AF1A@simula.no> To: David Ros Sender: "T. Moncaster" Archived-At: http://mailarchive.ietf.org/arch/msg/taps/k5RcQ0zaDNwb1kaT6ObNM08ay1U Cc: Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] LAST CALL: charter ready to ship? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 10:16:27 -0000 Also +1 (and I echo Mirja's thanks to Michael) Toby > On 12 Jun 2014, at 11:12, David Ros wrote: >=20 >> On 12 Jun 2014, at 11:43, Mirja Kuehlewind wrote: >>=20 >> Hi Michael, hi all, >>=20 >> I didn't contribute so far, but were following the discussion. You all di= d a=20 >> really good job. Special thanks to Michael for caring! I believe the char= ter=20 >> is ready and I'm happy to contribute in future! >>=20 >> Mirja >=20 > Hi, >=20 > +1 >=20 > Cheers, >=20 > David >=20 >=20 >>=20 >>=20 >>> On Wednesday 11 June 2014 09:10:58 Michael Welzl wrote: >>> Hi, >>>=20 >>> Unless someone comments by the end of tomorrow, 12 June, I will consider= >>> the charter final from the point of view of the WG and ship it to Spence= r. >>>=20 >>> Cheers, >>> Michael >>>=20 >>>> On 10. juni 2014, at 09:05, Michael Welzl wrote: >>>> Hi, >>>>=20 >>>> I have now applied these comments at: >>>> https://sites.google.com/site/transportprotocolservices/charter-proposa= l >>>>=20 >>>> Any more comments? Anyone? >>>>=20 >>>> Cheers, >>>> Michael >>>>=20 >>>>> On 8. juni 2014, at 00:25, Michael Welzl wrote: >>>>> On 7. juni 2014, at 16:20, Barry Leiba wrote= : >>>>>>> Ok, I will give it a try myself. >>>>>>=20 >>>>>> Yes, sorry: I was in httpbis meetings for a couple of days, and was >>>>>> distracted from other things by that. >>>>>=20 >>>>> No worries! >>>>>=20 >>>>>>> Here goes a proposal for item #2: >>>>>>>=20 >>>>>>> OLD >>>>>>> specify a set of transport services that end systems supporting TAPS= >>>>>>> need to provide and provide guidance on choosing among available >>>>>>> mechanisms and protocols to obtain a given transport service. >>>>>>> END >>>>>>>=20 >>>>>>> NEW >>>>>>> specify a shorter set of transport services that end systems >>>>>>> supporting TAPS need to provide and provide guidance on choosing amo= ng >>>>>>> available mechanisms and protocols to obtain a given transport >>>>>>> service. >>>>>>> END >>>>>>>=20 >>>>>>> The only change is that I inserted "shorter", but maybe that's enoug= h >>>>>>> to clarify the relationship to item #1? >>>>>>=20 >>>>>> Maybe... >>>>>> Or maybe "specify a subset of those services identified in item 1, >>>>>> which end systems..." >>>>>>=20 >>>>>> Does that work for you? I think it does for me. >>>>>=20 >>>>> It does for me, too. >>>>>=20 >>>>> Others? List? >>>>>=20 >>>>>>> My proposal for item #3: >>>>>>>=20 >>>>>>> OLD >>>>>>> specify experimental mechanisms to discover the availability of >>>>>>> protocols on an interface (both end system and path support), in ord= er >>>>>>> to provide a basis for incremental deployment. This will explain how= >>>>>>> to select and engage a protocol to deliver a transport service. >>>>>>> END >>>>>>>=20 >>>>>>> NEW >>>>>>> specify experimental mechanisms to deliver a transport service. This= >>>>>>> will explain how to select and engage a protocol, and how to discove= r >>>>>>> the availability of protocols on an interface (both end system and >>>>>>> path support), in order to provide a basis for incremental deploymen= t. >>>>>>> END >>>>>>>=20 >>>>>>> The intention is to more clearly say - with the first sentence - tha= t >>>>>>> we want to let the transport layer "figure out how to provide these >>>>>>> services". The rest is just a rearrangement of the old text, no new >>>>>>> words were introduced (and no animals harmed) :-) >>>>>>=20 >>>>>> I like that change; thanks. >>>>>=20 >>>>> Cool. Others? List? >>>>>=20 >>>>> Cheers, >>>>> Michael >>>>>=20 >>>>> _______________________________________________ >>>>> Taps mailing list >>>>> Taps@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/taps >>>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>=20 >>=20 >>=20 >> --=20 >> ------------------------------------------------------------------- >> Dipl.-Ing. Mirja K=C3=BChlewind >> Institute of Communication Networks and Computer Engineering (IKR) >> University of Stuttgart, Germany >> Pfaffenwaldring 47, D-70569 Stuttgart >>=20 >> tel: +49(0)711/685-67973 >> email: mirja.kuehlewind@ikr.uni-stuttgart.de >> web: www.ikr.uni-stuttgart.de >> ------------------------------------------------------------------- >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu Jun 12 04:32:42 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85DB61B2854 for ; Thu, 12 Jun 2014 04:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 OSHcXHzVqqIw for ; Thu, 12 Jun 2014 04:32:36 -0700 (PDT) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33BA71B2848 for ; Thu, 12 Jun 2014 04:32:36 -0700 (PDT) X-Spam-Processed: mail.kau.se, Thu, 12 Jun 2014 13:32:00 +0200 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: annabrun@kau.se X-MDRemoteIP: 193.11.155.70 X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se X-MDaemon-Deliver-To: taps@ietf.org Message-ID: <53998FC7.1050203@kau.se> Date: Thu, 12 Jun 2014 13:32:23 +0200 From: Anna Brunstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: taps@ietf.org References: <97DCE482-AA77-44A7-9710-E1933781E53E@ifi.uio.no> <08354C41-1F72-4C4C-BC24-F445C7D6956E@ifi.uio.no> <201406121143.00295.mirja.kuehlewind@ikr.uni-stuttgart.de> <950BF072-EA80-4657-9718-92A9F4A6AF1A@simula.no> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/_YtJhfIfw1oaUjCfwI3V8-Ds06k Subject: Re: [Taps] LAST CALL: charter ready to ship? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 11:32:38 -0000 +1 Anna On 2014-06-12 12:16, Toby Moncaster wrote: > Also +1 (and I echo Mirja's thanks to Michael) > > Toby > >> On 12 Jun 2014, at 11:12, David Ros wrote: >> >>> On 12 Jun 2014, at 11:43, Mirja Kuehlewind wrote: >>> >>> Hi Michael, hi all, >>> >>> I didn't contribute so far, but were following the discussion. You all did a >>> really good job. Special thanks to Michael for caring! I believe the charter >>> is ready and I'm happy to contribute in future! >>> >>> Mirja >> Hi, >> >> +1 >> >> Cheers, >> >> David >> >> >>> >>>> On Wednesday 11 June 2014 09:10:58 Michael Welzl wrote: >>>> Hi, >>>> >>>> Unless someone comments by the end of tomorrow, 12 June, I will consider >>>> the charter final from the point of view of the WG and ship it to Spencer. >>>> >>>> Cheers, >>>> Michael >>>> >>>>> On 10. juni 2014, at 09:05, Michael Welzl wrote: >>>>> Hi, >>>>> >>>>> I have now applied these comments at: >>>>> https://sites.google.com/site/transportprotocolservices/charter-proposal >>>>> >>>>> Any more comments? Anyone? >>>>> >>>>> Cheers, >>>>> Michael >>>>> >>>>>> On 8. juni 2014, at 00:25, Michael Welzl wrote: >>>>>> On 7. juni 2014, at 16:20, Barry Leiba wrote: >>>>>>>> Ok, I will give it a try myself. >>>>>>> Yes, sorry: I was in httpbis meetings for a couple of days, and was >>>>>>> distracted from other things by that. >>>>>> No worries! >>>>>> >>>>>>>> Here goes a proposal for item #2: >>>>>>>> >>>>>>>> OLD >>>>>>>> specify a set of transport services that end systems supporting TAPS >>>>>>>> need to provide and provide guidance on choosing among available >>>>>>>> mechanisms and protocols to obtain a given transport service. >>>>>>>> END >>>>>>>> >>>>>>>> NEW >>>>>>>> specify a shorter set of transport services that end systems >>>>>>>> supporting TAPS need to provide and provide guidance on choosing among >>>>>>>> available mechanisms and protocols to obtain a given transport >>>>>>>> service. >>>>>>>> END >>>>>>>> >>>>>>>> The only change is that I inserted "shorter", but maybe that's enough >>>>>>>> to clarify the relationship to item #1? >>>>>>> Maybe... >>>>>>> Or maybe "specify a subset of those services identified in item 1, >>>>>>> which end systems..." >>>>>>> >>>>>>> Does that work for you? I think it does for me. >>>>>> It does for me, too. >>>>>> >>>>>> Others? List? >>>>>> >>>>>>>> My proposal for item #3: >>>>>>>> >>>>>>>> OLD >>>>>>>> specify experimental mechanisms to discover the availability of >>>>>>>> protocols on an interface (both end system and path support), in order >>>>>>>> to provide a basis for incremental deployment. This will explain how >>>>>>>> to select and engage a protocol to deliver a transport service. >>>>>>>> END >>>>>>>> >>>>>>>> NEW >>>>>>>> specify experimental mechanisms to deliver a transport service. This >>>>>>>> will explain how to select and engage a protocol, and how to discover >>>>>>>> the availability of protocols on an interface (both end system and >>>>>>>> path support), in order to provide a basis for incremental deployment. >>>>>>>> END >>>>>>>> >>>>>>>> The intention is to more clearly say - with the first sentence - that >>>>>>>> we want to let the transport layer "figure out how to provide these >>>>>>>> services". The rest is just a rearrangement of the old text, no new >>>>>>>> words were introduced (and no animals harmed) :-) >>>>>>> I like that change; thanks. >>>>>> Cool. Others? List? >>>>>> >>>>>> Cheers, >>>>>> Michael >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>> >>> >>> -- >>> ------------------------------------------------------------------- >>> Dipl.-Ing. Mirja Kühlewind >>> Institute of Communication Networks and Computer Engineering (IKR) >>> University of Stuttgart, Germany >>> Pfaffenwaldring 47, D-70569 Stuttgart >>> >>> tel: +49(0)711/685-67973 >>> email: mirja.kuehlewind@ikr.uni-stuttgart.de >>> web: www.ikr.uni-stuttgart.de >>> ------------------------------------------------------------------- >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu Jun 12 04:37:10 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04371B284E for ; Thu, 12 Jun 2014 04:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 RvwurykrbhlK for ; Thu, 12 Jun 2014 04:37:06 -0700 (PDT) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADECB1B2848 for ; Thu, 12 Jun 2014 04:37:06 -0700 (PDT) Received: by mail-yh0-f45.google.com with SMTP id t59so833750yho.4 for ; Thu, 12 Jun 2014 04:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=DuhLVWvTAYql47YQJUSTSq/BuG6za4wyXK6WUimy9V8=; b=AWFsG64rl/3Lx/qKUdrWiHgyLGTH4SGwUZFb6/3n6aaGHUO0nSWdsf3FdJNYImLiSF m7f4ZyAcfevaBL4dyFQougCPMxPOegoAh5GkCACEZAuKYrR2R+eZwWat4orzTEN56k0H c390cmU3cLpjgs8iWTtP2NhMieWO11CU5zxpu7fRfUenmeW/9ar7Z+1gimZOL7m08mV8 1pgJGWDBsBLNZmGQnc43eYsPoHBjCCeI0lUYjU6UP2lwCSHplHGSZCJtvvc3dpadQiqq PXDhYJftaeB7s8DEhn9wxTvkGQc9EMCJnp+1wbx5hJ5Ib0KJeAmLUsJAf0kRM5Nh8cTq pyWA== X-Received: by 10.236.140.233 with SMTP id e69mr4146118yhj.120.1402573025961; Thu, 12 Jun 2014 04:37:05 -0700 (PDT) Received: from [10.71.14.162] ([64.197.173.10]) by mx.google.com with ESMTPSA id q42sm951472yhm.56.2014.06.12.04.37.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Jun 2014 04:37:05 -0700 (PDT) Message-ID: <539990E0.3060101@gmail.com> Date: Thu, 12 Jun 2014 06:37:04 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Michael Welzl , taps@ietf.org References: <97DCE482-AA77-44A7-9710-E1933781E53E@ifi.uio.no> <08354C41-1F72-4C4C-BC24-F445C7D6956E@ifi.uio.no> <201406121143.00295.mirja.kuehlewind@ikr.uni-stuttgart.de> <950BF072-EA80-4657-9718-92A9F4A6AF1A@simula.no> <53998FC7.1050203@kau.se> In-Reply-To: <53998FC7.1050203@kau.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/eeCE3fdCjt2FthBGuVW2UUlBM4w Subject: Re: [Taps] LAST CALL: charter ready to ship? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 11:37:08 -0000 Michael, Please let me know when to pull the trigger :-) Spencer On 06/12/2014 06:32 AM, Anna Brunstrom wrote: > +1 > > Anna > > On 2014-06-12 12:16, Toby Moncaster wrote: >> Also +1 (and I echo Mirja's thanks to Michael) >> >> Toby >> >>> On 12 Jun 2014, at 11:12, David Ros wrote: >>> >>>> On 12 Jun 2014, at 11:43, Mirja Kuehlewind >>>> wrote: >>>> >>>> Hi Michael, hi all, >>>> >>>> I didn't contribute so far, but were following the discussion. You >>>> all did a >>>> really good job. Special thanks to Michael for caring! I believe >>>> the charter >>>> is ready and I'm happy to contribute in future! >>>> >>>> Mirja >>> Hi, >>> >>> +1 >>> >>> Cheers, >>> >>> David >>> >>> >>>> >>>>> On Wednesday 11 June 2014 09:10:58 Michael Welzl wrote: >>>>> Hi, >>>>> >>>>> Unless someone comments by the end of tomorrow, 12 June, I will >>>>> consider >>>>> the charter final from the point of view of the WG and ship it to >>>>> Spencer. >>>>> >>>>> Cheers, >>>>> Michael >>>>> >>>>>> On 10. juni 2014, at 09:05, Michael Welzl wrote: >>>>>> Hi, >>>>>> >>>>>> I have now applied these comments at: >>>>>> https://sites.google.com/site/transportprotocolservices/charter-proposal >>>>>> >>>>>> >>>>>> Any more comments? Anyone? >>>>>> >>>>>> Cheers, >>>>>> Michael >>>>>> >>>>>>> On 8. juni 2014, at 00:25, Michael Welzl wrote: >>>>>>> On 7. juni 2014, at 16:20, Barry Leiba >>>>>>> wrote: >>>>>>>>> Ok, I will give it a try myself. >>>>>>>> Yes, sorry: I was in httpbis meetings for a couple of days, and >>>>>>>> was >>>>>>>> distracted from other things by that. >>>>>>> No worries! >>>>>>> >>>>>>>>> Here goes a proposal for item #2: >>>>>>>>> >>>>>>>>> OLD >>>>>>>>> specify a set of transport services that end systems >>>>>>>>> supporting TAPS >>>>>>>>> need to provide and provide guidance on choosing among available >>>>>>>>> mechanisms and protocols to obtain a given transport service. >>>>>>>>> END >>>>>>>>> >>>>>>>>> NEW >>>>>>>>> specify a shorter set of transport services that end systems >>>>>>>>> supporting TAPS need to provide and provide guidance on >>>>>>>>> choosing among >>>>>>>>> available mechanisms and protocols to obtain a given transport >>>>>>>>> service. >>>>>>>>> END >>>>>>>>> >>>>>>>>> The only change is that I inserted "shorter", but maybe that's >>>>>>>>> enough >>>>>>>>> to clarify the relationship to item #1? >>>>>>>> Maybe... >>>>>>>> Or maybe "specify a subset of those services identified in item 1, >>>>>>>> which end systems..." >>>>>>>> >>>>>>>> Does that work for you? I think it does for me. >>>>>>> It does for me, too. >>>>>>> >>>>>>> Others? List? >>>>>>> >>>>>>>>> My proposal for item #3: >>>>>>>>> >>>>>>>>> OLD >>>>>>>>> specify experimental mechanisms to discover the availability of >>>>>>>>> protocols on an interface (both end system and path support), >>>>>>>>> in order >>>>>>>>> to provide a basis for incremental deployment. This will >>>>>>>>> explain how >>>>>>>>> to select and engage a protocol to deliver a transport service. >>>>>>>>> END >>>>>>>>> >>>>>>>>> NEW >>>>>>>>> specify experimental mechanisms to deliver a transport >>>>>>>>> service. This >>>>>>>>> will explain how to select and engage a protocol, and how to >>>>>>>>> discover >>>>>>>>> the availability of protocols on an interface (both end system >>>>>>>>> and >>>>>>>>> path support), in order to provide a basis for incremental >>>>>>>>> deployment. >>>>>>>>> END >>>>>>>>> >>>>>>>>> The intention is to more clearly say - with the first sentence >>>>>>>>> - that >>>>>>>>> we want to let the transport layer "figure out how to provide >>>>>>>>> these >>>>>>>>> services". The rest is just a rearrangement of the old text, >>>>>>>>> no new >>>>>>>>> words were introduced (and no animals harmed) :-) >>>>>>>> I like that change; thanks. >>>>>>> Cool. Others? List? >>>>>>> >>>>>>> Cheers, >>>>>>> Michael >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>>> >>>> -- >>>> ------------------------------------------------------------------- >>>> Dipl.-Ing. Mirja Kühlewind >>>> Institute of Communication Networks and Computer Engineering (IKR) >>>> University of Stuttgart, Germany >>>> Pfaffenwaldring 47, D-70569 Stuttgart >>>> >>>> tel: +49(0)711/685-67973 >>>> email: mirja.kuehlewind@ikr.uni-stuttgart.de >>>> web: www.ikr.uni-stuttgart.de >>>> ------------------------------------------------------------------- >>>> >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu Jun 12 04:41:47 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1831B2854 for ; Thu, 12 Jun 2014 04:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 KM4_8lOE2fAj for ; Thu, 12 Jun 2014 04:41:42 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D6251B2848 for ; Thu, 12 Jun 2014 04:41:42 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Wv3Nz-0005GW-Sq; Thu, 12 Jun 2014 13:41:39 +0200 Received: from 1x-193-157-240-22.uio.no ([193.157.240.22]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Wv3Nz-0003or-87; Thu, 12 Jun 2014 13:41:39 +0200 References: <97DCE482-AA77-44A7-9710-E1933781E53E@ifi.uio.no> <08354C41-1F72-4C4C-BC24-F445C7D6956E@ifi.uio.no> <201406121143.00295.mirja.kuehlewind@ikr.uni-stuttgart.de> <950BF072-EA80-4657-9718-92A9F4A6AF1A@simula.no> <53998FC7.1050203@kau.se> <539990E0.3060101@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <539990E0.3060101@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (11D201) From: Michael Welzl Date: Thu, 12 Jun 2014 13:41:40 +0200 To: Spencer Dawkins X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 2 sum rcpts/h 8 sum msgs/h 3 total rcpts 17634 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 35A5AD191F1FC8481878801E9356C761A112503C X-UiO-SPAM-Test: remote_host: 193.157.240.22 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 112 max/h 9 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/uaTbiex3he_hw4LPI3JC6Q5DILg Cc: "taps@ietf.org" Subject: Re: [Taps] LAST CALL: charter ready to ship? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 11:41:45 -0000 after "the end of today", to keep my promise from y'day's mail.... Sent from my iPhone > On 12. juni 2014, at 13:37, Spencer Dawkins wrote: >=20 > Michael, >=20 > Please let me know when to pull the trigger :-) >=20 > Spencer >=20 >> On 06/12/2014 06:32 AM, Anna Brunstrom wrote: >> +1 >>=20 >> Anna >>=20 >>> On 2014-06-12 12:16, Toby Moncaster wrote: >>> Also +1 (and I echo Mirja's thanks to Michael) >>>=20 >>> Toby >>>=20 >>>>> On 12 Jun 2014, at 11:12, David Ros wrote: >>>>>=20 >>>>> On 12 Jun 2014, at 11:43, Mirja Kuehlewind wrote: >>>>>=20 >>>>> Hi Michael, hi all, >>>>>=20 >>>>> I didn't contribute so far, but were following the discussion. You all= did a >>>>> really good job. Special thanks to Michael for caring! I believe the c= harter >>>>> is ready and I'm happy to contribute in future! >>>>>=20 >>>>> Mirja >>>> Hi, >>>>=20 >>>> +1 >>>>=20 >>>> Cheers, >>>>=20 >>>> David >>>>=20 >>>>=20 >>>>>=20 >>>>>> On Wednesday 11 June 2014 09:10:58 Michael Welzl wrote: >>>>>> Hi, >>>>>>=20 >>>>>> Unless someone comments by the end of tomorrow, 12 June, I will consi= der >>>>>> the charter final from the point of view of the WG and ship it to Spe= ncer. >>>>>>=20 >>>>>> Cheers, >>>>>> Michael >>>>>>=20 >>>>>>> On 10. juni 2014, at 09:05, Michael Welzl wrote: >>>>>>> Hi, >>>>>>>=20 >>>>>>> I have now applied these comments at: >>>>>>> https://sites.google.com/site/transportprotocolservices/charter-prop= osal=20 >>>>>>>=20 >>>>>>> Any more comments? Anyone? >>>>>>>=20 >>>>>>> Cheers, >>>>>>> Michael >>>>>>>=20 >>>>>>>> On 8. juni 2014, at 00:25, Michael Welzl wrote: >>>>>>>> On 7. juni 2014, at 16:20, Barry Leiba wr= ote: >>>>>>>>>> Ok, I will give it a try myself. >>>>>>>>> Yes, sorry: I was in httpbis meetings for a couple of days, and wa= s >>>>>>>>> distracted from other things by that. >>>>>>>> No worries! >>>>>>>>=20 >>>>>>>>>> Here goes a proposal for item #2: >>>>>>>>>>=20 >>>>>>>>>> OLD >>>>>>>>>> specify a set of transport services that end systems supporting T= APS >>>>>>>>>> need to provide and provide guidance on choosing among available >>>>>>>>>> mechanisms and protocols to obtain a given transport service. >>>>>>>>>> END >>>>>>>>>>=20 >>>>>>>>>> NEW >>>>>>>>>> specify a shorter set of transport services that end systems >>>>>>>>>> supporting TAPS need to provide and provide guidance on choosing a= mong >>>>>>>>>> available mechanisms and protocols to obtain a given transport >>>>>>>>>> service. >>>>>>>>>> END >>>>>>>>>>=20 >>>>>>>>>> The only change is that I inserted "shorter", but maybe that's en= ough >>>>>>>>>> to clarify the relationship to item #1? >>>>>>>>> Maybe... >>>>>>>>> Or maybe "specify a subset of those services identified in item 1,= >>>>>>>>> which end systems..." >>>>>>>>>=20 >>>>>>>>> Does that work for you? I think it does for me. >>>>>>>> It does for me, too. >>>>>>>>=20 >>>>>>>> Others? List? >>>>>>>>=20 >>>>>>>>>> My proposal for item #3: >>>>>>>>>>=20 >>>>>>>>>> OLD >>>>>>>>>> specify experimental mechanisms to discover the availability of >>>>>>>>>> protocols on an interface (both end system and path support), in o= rder >>>>>>>>>> to provide a basis for incremental deployment. This will explain h= ow >>>>>>>>>> to select and engage a protocol to deliver a transport service. >>>>>>>>>> END >>>>>>>>>>=20 >>>>>>>>>> NEW >>>>>>>>>> specify experimental mechanisms to deliver a transport service. T= his >>>>>>>>>> will explain how to select and engage a protocol, and how to disc= over >>>>>>>>>> the availability of protocols on an interface (both end system an= d >>>>>>>>>> path support), in order to provide a basis for incremental deploy= ment. >>>>>>>>>> END >>>>>>>>>>=20 >>>>>>>>>> The intention is to more clearly say - with the first sentence - t= hat >>>>>>>>>> we want to let the transport layer "figure out how to provide the= se >>>>>>>>>> services". The rest is just a rearrangement of the old text, no n= ew >>>>>>>>>> words were introduced (and no animals harmed) :-) >>>>>>>>> I like that change; thanks. >>>>>>>> Cool. Others? List? >>>>>>>>=20 >>>>>>>> Cheers, >>>>>>>> Michael >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Taps mailing list >>>>>>>> Taps@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>>> _______________________________________________ >>>>>>> Taps mailing list >>>>>>> Taps@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>=20 >>>>>=20 >>>>> --=20 >>>>> ------------------------------------------------------------------- >>>>> Dipl.-Ing. Mirja K=C3=BChlewind >>>>> Institute of Communication Networks and Computer Engineering (IKR) >>>>> University of Stuttgart, Germany >>>>> Pfaffenwaldring 47, D-70569 Stuttgart >>>>>=20 >>>>> tel: +49(0)711/685-67973 >>>>> email: mirja.kuehlewind@ikr.uni-stuttgart.de >>>>> web: www.ikr.uni-stuttgart.de >>>>> ------------------------------------------------------------------- >>>>>=20 >>>>> _______________________________________________ >>>>> Taps mailing list >>>>> Taps@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/taps >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 From nobody Thu Jun 12 09:55:11 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B60EB1A0645 for ; Thu, 12 Jun 2014 09:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 WV284P3yvHSR for ; Thu, 12 Jun 2014 09:55:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCF9C1A0646 for ; Thu, 12 Jun 2014 09:54:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BII95966; Thu, 12 Jun 2014 16:54:54 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Jun 2014 17:54:53 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml704-chm.china.huawei.com ([169.254.6.5]) with mapi id 14.03.0158.001; Thu, 12 Jun 2014 09:54:47 -0700 From: Linda Dunbar To: Toby Moncaster , David Ros Thread-Topic: [Taps] LAST CALL: charter ready to ship? Thread-Index: AQHPhURmVsoMs6J8c0S4rSKjqXHkGpttsDUAgAAIRQCAAAELAP//+fVA Date: Thu, 12 Jun 2014 16:54:46 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D3422E@dfweml701-chm.china.huawei.com> References: <97DCE482-AA77-44A7-9710-E1933781E53E@ifi.uio.no> <08354C41-1F72-4C4C-BC24-F445C7D6956E@ifi.uio.no> <201406121143.00295.mirja.kuehlewind@ikr.uni-stuttgart.de> <950BF072-EA80-4657-9718-92A9F4A6AF1A@simula.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.147.229] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/taps/lxF-YlkkOPMHCVPeazOs6CrH3fU Cc: Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] LAST CALL: charter ready to ship? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jun 2014 16:55:08 -0000 KzEsIA0KDQpMaW5kYQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVGFwcyBb bWFpbHRvOnRhcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRvYnkgTW9uY2FzdGVy DQpTZW50OiBUaHVyc2RheSwgSnVuZSAxMiwgMjAxNCA1OjE2IEFNDQpUbzogRGF2aWQgUm9zDQpD YzogTWljaGFlbCBXZWx6bDsgdGFwc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUYXBzXSBMQVNU IENBTEw6IGNoYXJ0ZXIgcmVhZHkgdG8gc2hpcD8NCg0KQWxzbyArMSAoYW5kIEkgZWNobyBNaXJq YSdzIHRoYW5rcyB0byBNaWNoYWVsKQ0KDQpUb2J5DQoNCj4gT24gMTIgSnVuIDIwMTQsIGF0IDEx OjEyLCBEYXZpZCBSb3MgPGRyb3NAc2ltdWxhLm5vPiB3cm90ZToNCj4gDQo+PiBPbiAxMiBKdW4g MjAxNCwgYXQgMTE6NDMsIE1pcmphIEt1ZWhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAaWtyLnVu aS1zdHV0dGdhcnQuZGU+IHdyb3RlOg0KPj4gDQo+PiBIaSBNaWNoYWVsLCBoaSBhbGwsDQo+PiAN Cj4+IEkgZGlkbid0IGNvbnRyaWJ1dGUgc28gZmFyLCBidXQgd2VyZSBmb2xsb3dpbmcgdGhlIGRp c2N1c3Npb24uIFlvdSANCj4+IGFsbCBkaWQgYSByZWFsbHkgZ29vZCBqb2IuIFNwZWNpYWwgdGhh bmtzIHRvIE1pY2hhZWwgZm9yIGNhcmluZyEgSSANCj4+IGJlbGlldmUgdGhlIGNoYXJ0ZXIgaXMg cmVhZHkgYW5kIEknbSBoYXBweSB0byBjb250cmlidXRlIGluIGZ1dHVyZSENCj4+IA0KPj4gTWly amENCj4gDQo+IEhpLA0KPiANCj4gKzENCj4gDQo+IENoZWVycywNCj4gDQo+IERhdmlkDQo+IA0K PiANCj4+IA0KPj4gDQo+Pj4gT24gV2VkbmVzZGF5IDExIEp1bmUgMjAxNCAwOToxMDo1OCBNaWNo YWVsIFdlbHpsIHdyb3RlOg0KPj4+IEhpLA0KPj4+IA0KPj4+IFVubGVzcyBzb21lb25lIGNvbW1l bnRzIGJ5IHRoZSBlbmQgb2YgdG9tb3Jyb3csIDEyIEp1bmUsIEkgd2lsbCANCj4+PiBjb25zaWRl ciB0aGUgY2hhcnRlciBmaW5hbCBmcm9tIHRoZSBwb2ludCBvZiB2aWV3IG9mIHRoZSBXRyBhbmQg c2hpcCBpdCB0byBTcGVuY2VyLg0KPj4+IA0KPj4+IENoZWVycywNCj4+PiBNaWNoYWVsDQo+Pj4g DQo+Pj4+IE9uIDEwLiBqdW5pIDIwMTQsIGF0IDA5OjA1LCBNaWNoYWVsIFdlbHpsIHdyb3RlOg0K Pj4+PiBIaSwNCj4+Pj4gDQo+Pj4+IEkgaGF2ZSBub3cgYXBwbGllZCB0aGVzZSBjb21tZW50cyBh dDoNCj4+Pj4gaHR0cHM6Ly9zaXRlcy5nb29nbGUuY29tL3NpdGUvdHJhbnNwb3J0cHJvdG9jb2xz ZXJ2aWNlcy9jaGFydGVyLXBybw0KPj4+PiBwb3NhbA0KPj4+PiANCj4+Pj4gQW55IG1vcmUgY29t bWVudHM/IEFueW9uZT8NCj4+Pj4gDQo+Pj4+IENoZWVycywNCj4+Pj4gTWljaGFlbA0KPj4+PiAN Cj4+Pj4+IE9uIDguIGp1bmkgMjAxNCwgYXQgMDA6MjUsIE1pY2hhZWwgV2Vsemwgd3JvdGU6DQo+ Pj4+PiBPbiA3LiBqdW5pIDIwMTQsIGF0IDE2OjIwLCBCYXJyeSBMZWliYSA8YmFycnlsZWliYUBj b21wdXRlci5vcmc+IHdyb3RlOg0KPj4+Pj4+PiBPaywgSSB3aWxsIGdpdmUgaXQgYSB0cnkgbXlz ZWxmLg0KPj4+Pj4+IA0KPj4+Pj4+IFllcywgc29ycnk6IEkgd2FzIGluIGh0dHBiaXMgbWVldGlu Z3MgZm9yIGEgY291cGxlIG9mIGRheXMsIGFuZCANCj4+Pj4+PiB3YXMgZGlzdHJhY3RlZCBmcm9t IG90aGVyIHRoaW5ncyBieSB0aGF0Lg0KPj4+Pj4gDQo+Pj4+PiBObyB3b3JyaWVzIQ0KPj4+Pj4g DQo+Pj4+Pj4+IEhlcmUgZ29lcyBhIHByb3Bvc2FsIGZvciBpdGVtICMyOg0KPj4+Pj4+PiANCj4+ Pj4+Pj4gT0xEDQo+Pj4+Pj4+IHNwZWNpZnkgYSBzZXQgb2YgdHJhbnNwb3J0IHNlcnZpY2VzIHRo YXQgZW5kIHN5c3RlbXMgc3VwcG9ydGluZyANCj4+Pj4+Pj4gVEFQUyBuZWVkIHRvIHByb3ZpZGUg YW5kIHByb3ZpZGUgZ3VpZGFuY2Ugb24gY2hvb3NpbmcgYW1vbmcgDQo+Pj4+Pj4+IGF2YWlsYWJs ZSBtZWNoYW5pc21zIGFuZCBwcm90b2NvbHMgdG8gb2J0YWluIGEgZ2l2ZW4gdHJhbnNwb3J0IHNl cnZpY2UuDQo+Pj4+Pj4+IEVORA0KPj4+Pj4+PiANCj4+Pj4+Pj4gTkVXDQo+Pj4+Pj4+IHNwZWNp ZnkgYSBzaG9ydGVyIHNldCBvZiB0cmFuc3BvcnQgc2VydmljZXMgdGhhdCBlbmQgc3lzdGVtcyAN Cj4+Pj4+Pj4gc3VwcG9ydGluZyBUQVBTIG5lZWQgdG8gcHJvdmlkZSBhbmQgcHJvdmlkZSBndWlk YW5jZSBvbiBjaG9vc2luZyANCj4+Pj4+Pj4gYW1vbmcgYXZhaWxhYmxlIG1lY2hhbmlzbXMgYW5k IHByb3RvY29scyB0byBvYnRhaW4gYSBnaXZlbiANCj4+Pj4+Pj4gdHJhbnNwb3J0IHNlcnZpY2Uu DQo+Pj4+Pj4+IEVORA0KPj4+Pj4+PiANCj4+Pj4+Pj4gVGhlIG9ubHkgY2hhbmdlIGlzIHRoYXQg SSBpbnNlcnRlZCAic2hvcnRlciIsIGJ1dCBtYXliZSB0aGF0J3MgDQo+Pj4+Pj4+IGVub3VnaCB0 byBjbGFyaWZ5IHRoZSByZWxhdGlvbnNoaXAgdG8gaXRlbSAjMT8NCj4+Pj4+PiANCj4+Pj4+PiBN YXliZS4uLg0KPj4+Pj4+IE9yIG1heWJlICJzcGVjaWZ5IGEgc3Vic2V0IG9mIHRob3NlIHNlcnZp Y2VzIGlkZW50aWZpZWQgaW4gaXRlbSANCj4+Pj4+PiAxLCB3aGljaCBlbmQgc3lzdGVtcy4uLiIN Cj4+Pj4+PiANCj4+Pj4+PiBEb2VzIHRoYXQgd29yayBmb3IgeW91PyAgSSB0aGluayBpdCBkb2Vz IGZvciBtZS4NCj4+Pj4+IA0KPj4+Pj4gSXQgZG9lcyBmb3IgbWUsIHRvby4NCj4+Pj4+IA0KPj4+ Pj4gT3RoZXJzPyBMaXN0Pw0KPj4+Pj4gDQo+Pj4+Pj4+IE15IHByb3Bvc2FsIGZvciBpdGVtICMz Og0KPj4+Pj4+PiANCj4+Pj4+Pj4gT0xEDQo+Pj4+Pj4+IHNwZWNpZnkgZXhwZXJpbWVudGFsIG1l Y2hhbmlzbXMgdG8gZGlzY292ZXIgdGhlIGF2YWlsYWJpbGl0eSBvZiANCj4+Pj4+Pj4gcHJvdG9j b2xzIG9uIGFuIGludGVyZmFjZSAoYm90aCBlbmQgc3lzdGVtIGFuZCBwYXRoIHN1cHBvcnQpLCBp biANCj4+Pj4+Pj4gb3JkZXIgdG8gcHJvdmlkZSBhIGJhc2lzIGZvciBpbmNyZW1lbnRhbCBkZXBs b3ltZW50LiBUaGlzIHdpbGwgDQo+Pj4+Pj4+IGV4cGxhaW4gaG93IHRvIHNlbGVjdCBhbmQgZW5n YWdlIGEgcHJvdG9jb2wgdG8gZGVsaXZlciBhIHRyYW5zcG9ydCBzZXJ2aWNlLg0KPj4+Pj4+PiBF TkQNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IE5FVw0KPj4+Pj4+PiBzcGVjaWZ5IGV4cGVyaW1lbnRhbCBt ZWNoYW5pc21zIHRvIGRlbGl2ZXIgYSB0cmFuc3BvcnQgc2VydmljZS4gDQo+Pj4+Pj4+IFRoaXMg d2lsbCBleHBsYWluIGhvdyB0byBzZWxlY3QgYW5kIGVuZ2FnZSBhIHByb3RvY29sLCBhbmQgaG93 IA0KPj4+Pj4+PiB0byBkaXNjb3ZlciB0aGUgYXZhaWxhYmlsaXR5IG9mIHByb3RvY29scyBvbiBh biBpbnRlcmZhY2UgKGJvdGggDQo+Pj4+Pj4+IGVuZCBzeXN0ZW0gYW5kIHBhdGggc3VwcG9ydCks IGluIG9yZGVyIHRvIHByb3ZpZGUgYSBiYXNpcyBmb3IgaW5jcmVtZW50YWwgZGVwbG95bWVudC4N Cj4+Pj4+Pj4gRU5EDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBUaGUgaW50ZW50aW9uIGlzIHRvIG1vcmUg Y2xlYXJseSBzYXkgLSB3aXRoIHRoZSBmaXJzdCBzZW50ZW5jZSAtIA0KPj4+Pj4+PiB0aGF0IHdl IHdhbnQgdG8gbGV0IHRoZSB0cmFuc3BvcnQgbGF5ZXIgImZpZ3VyZSBvdXQgaG93IHRvIA0KPj4+ Pj4+PiBwcm92aWRlIHRoZXNlIHNlcnZpY2VzIi4gVGhlIHJlc3QgaXMganVzdCBhIHJlYXJyYW5n ZW1lbnQgb2YgdGhlIG9sZCB0ZXh0LCBubyBuZXcNCj4+Pj4+Pj4gd29yZHMgd2VyZSBpbnRyb2R1 Y2VkIChhbmQgbm8gYW5pbWFscyBoYXJtZWQpICAgOi0pDQo+Pj4+Pj4gDQo+Pj4+Pj4gSSBsaWtl IHRoYXQgY2hhbmdlOyB0aGFua3MuDQo+Pj4+PiANCj4+Pj4+IENvb2wuIE90aGVycz8gTGlzdD8N Cj4+Pj4+IA0KPj4+Pj4gQ2hlZXJzLA0KPj4+Pj4gTWljaGFlbA0KPj4+Pj4gDQo+Pj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gVGFwcyBt YWlsaW5nIGxpc3QNCj4+Pj4+IFRhcHNAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdGFwcw0KPj4+PiANCj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gVGFwcyBtYWlsaW5nIGxpc3QNCj4+ Pj4gVGFwc0BpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RhcHMNCj4+IA0KPj4gDQo+PiANCj4+IC0tDQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+PiBEaXBsLi1J bmcuIE1pcmphIEvDvGhsZXdpbmQNCj4+IEluc3RpdHV0ZSBvZiBDb21tdW5pY2F0aW9uIE5ldHdv cmtzIGFuZCBDb21wdXRlciBFbmdpbmVlcmluZyAoSUtSKSANCj4+IFVuaXZlcnNpdHkgb2YgU3R1 dHRnYXJ0LCBHZXJtYW55IFBmYWZmZW53YWxkcmluZyA0NywgRC03MDU2OSANCj4+IFN0dXR0Z2Fy dA0KPj4gDQo+PiB0ZWw6ICs0OSgwKTcxMS82ODUtNjc5NzMNCj4+IGVtYWlsOiBtaXJqYS5rdWVo bGV3aW5kQGlrci51bmktc3R1dHRnYXJ0LmRlDQo+PiB3ZWI6IHd3dy5pa3IudW5pLXN0dXR0Z2Fy dC5kZQ0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj4gVGFwcyBtYWlsaW5nIGxpc3QNCj4+IFRhcHNAaWV0Zi5v cmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGFwcw0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gVGFwcyBt YWlsaW5nIGxpc3QNCj4gVGFwc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3RhcHMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NClRhcHMgbWFpbGluZyBsaXN0DQpUYXBzQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RhcHMNCg== From nobody Fri Jun 13 00:10:11 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74E71B28E4 for ; Fri, 13 Jun 2014 00:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 GQLTaaztZhjD for ; Fri, 13 Jun 2014 00:10:04 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC3B11A00DD for ; Fri, 13 Jun 2014 00:10:03 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WvLcf-00071S-2J; Fri, 13 Jun 2014 09:10:01 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WvLce-0008Jn-Cr; Fri, 13 Jun 2014 09:10:01 +0200 From: Michael Welzl Content-Type: multipart/alternative; boundary="Apple-Mail=_9206F87E-FEC2-4EA3-87E2-65AC99CA3E5F" Date: Fri, 13 Jun 2014 09:09:59 +0200 Message-Id: To: Spencer Dawkins Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 5 sum msgs/h 3 total rcpts 17652 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: DE985BD11BC91E0874C42F35C4B32B34E370CE09 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 5623 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/ECkcsp04vkEZ3rj6TOWONv4Gztk Cc: taps@ietf.org Subject: [Taps] Today's shipment: the TAPS charter! X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 07:10:09 -0000 --Apple-Mail=_9206F87E-FEC2-4EA3-87E2-65AC99CA3E5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear Spencer, Finally I'm in a position to ship the fully list-agreed version of the = TAPS charter. It's at: https://sites.google.com/site/transportprotocolservices/charter-proposal and at the bottom of this email. Cheers, Michael =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Transport Services (TAPS) Status: Proposed Working Group Last Updated: 2014-06-10 Chair(s): TBD Transport Area Director(s): Spencer Dawkins Martin Stiemerling Transport Area Advisor: TBD Mailing Lists: taps@ietf.org Description of Working Group Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite, and = the LEDBAT congestion control mechanism extend the set of transport = services that are available to applications, beyond those provided by = TCP and UDP. For example, SCTP provides potentially faster reliable = delivery for applications that can accept blocks of data out of order, = and LEDBAT provides low-priority "scavenger" communication. For an application programmer, it is hard to use protocols other than = TCP or UDP: most network stacks only support TCP and UDP, many firewalls = only pass TCP and UDP, and requiring other transport protocols risks = having an application not work in many environments. Applications, = therefore, must always be able to fall back to TCP or UDP.=20 Further, different protocols can provide the same services in different = ways. Layering decisions must be made (for example, whether a protocol = is used natively or tunneled through UDP). Because of these complications, programmers often resort to either using = TCP or implementing their own customized solution over UDP. That can = result in applications re-implementing features already available = elsewhere, and chances of benefiting from other transport protocols are = lost. There are many ways in which this problem could be addressed; while it = may not yet be clear what the best way forward could be, any approach to = provide a richer set of transport services to applications will have to = begin with the identification of the services that current transport = protocols provide. The Working Group will: =95 identify services provided by existing IETF transport = protocols and congestion control mechanisms. The resulting document will = provide guidance on making a choice among available mechanisms and = protocols to obtain a certain transport service. =95 specify a subset of those services identified in item 1, = which end systems supporting TAPS need to provide and provide guidance = on choosing among available mechanisms and protocols to obtain a given = transport service. =95 specify experimental mechanisms to deliver a transport = service. This will explain how to select and engage a protocol, and how = to discover the availability of protocols on an interface (both end = system and path support), in order to provide a basis for incremental = deployment. The Working Group will coordinate closely with other Working Groups and = IRTF Research Groups. The following topics are out of scope of this Working Group: =95 Quality-of-Service (QoS) and tunneling mechanisms and = services =95 Definition of new encapsulations and tunneling mechanisms Milestones: =95 M7: Submit summary of the services provided by IETF = transport protocols and congestion control mechanisms to IESG. =95 M13: Submit end system transport services to IESG. =95 M14: Submit specification of how the transport services can = be provided to IESG.= --Apple-Mail=_9206F87E-FEC2-4EA3-87E2-65AC99CA3E5F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = Spencer,

Finally I'm in a position to ship the fully = list-agreed version of the TAPS charter. It's at:
and at the bottom of this = email.

Cheers,
Michael


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



Transport Services (TAPS)

Status: Proposed = Working Group
Last Updated: = 2014-06-10

Chair(s):
TBD

Transport Area = Director(s):
Spencer Dawkins <spencerdawkins.ietf@gmail.co= m>
Martin Stiemerling <mls.ietf@gmail.com>

Trans= port Area Advisor:
TBD

Mailing Lists: taps@ietf.org


Description = of Working Group

Conjointly, transport protocols such as SCTP, = DCCP, MPTCP, UDP-Lite, and the LEDBAT congestion control mechanism = extend the set of transport services that are available to applications, = beyond those provided by TCP and UDP. For example, SCTP provides = potentially faster reliable delivery for applications that can accept = blocks of data out of order, and LEDBAT provides low-priority = "scavenger" communication.

For an application programmer, it is = hard to use protocols other than TCP or UDP: most network stacks only = support TCP and UDP, many firewalls only pass TCP and UDP, and requiring = other transport protocols risks having an application not work in many = environments. Applications, therefore, must always be able to fall back = to TCP or UDP. 
Further, different protocols can provide the = same services in different ways. Layering decisions must be made (for = example, whether a protocol is used natively or tunneled through = UDP).

Because of these complications, = programmers often resort to either using TCP or implementing their own = customized solution over UDP. That can result in applications = re-implementing features already available elsewhere, and chances of = benefiting from other transport protocols are lost.


There = are many ways in which this problem could be addressed; while it may not = yet be clear what the best way forward could be, any approach to provide = a richer set of transport services to applications will have to begin = with the identification of the services that current transport protocols = provide.

The Working Group will:
=95 = identify services provided by existing IETF transport protocols and = congestion control mechanisms. The resulting document will provide = guidance on making a choice among available mechanisms and protocols to = obtain a certain transport service.
=95 = specify a subset of those services identified in item 1, which end = systems supporting TAPS need to provide and provide guidance on = choosing among available mechanisms and protocols to obtain a given = transport service.
=95 specify experimental = mechanisms to deliver a transport service. This will explain how to = select and engage a protocol, and how to discover the availability of = protocols on an interface (both end system and path support), in order = to provide a basis for incremental deployment.

The Working = Group will coordinate closely with other Working Groups and IRTF = Research Groups.

The following topics are out of scope of this = Working Group:
=95 Quality-of-Service (QoS) and = tunneling mechanisms and services
=95 = Definition of new encapsulations and tunneling = mechanisms

Milestones:
=95 M7: Submit summary of the = services provided by IETF transport protocols and congestion control = mechanisms to IESG.
=95 M13: Submit end system = transport services to IESG.
=95 M14: Submit = specification of how the transport services can be provided to = IESG.
= --Apple-Mail=_9206F87E-FEC2-4EA3-87E2-65AC99CA3E5F-- From nobody Fri Jun 13 20:45:33 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014D81B2B35 for ; Fri, 13 Jun 2014 20:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 hKktbslxSder for ; Fri, 13 Jun 2014 20:45:30 -0700 (PDT) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C236F1B27E0 for ; Fri, 13 Jun 2014 20:45:30 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id n16so3741726oag.20 for ; Fri, 13 Jun 2014 20:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=TNeNqrJDtGW/XA2VLeyqWdO8tXHWzbDh07EnUCRIh1I=; b=rY/eW95ngx3b7WBPbRvaBQnItMinXIN5Yu37DshUhZXVUOm91H7K7zLnMyNAIbTwCs psAXZl+X0MnwfUXV7B8fcWR1z18rYSpWM1WeuF9PyVs5DbY1l2gxz0iX2WDFgyYGMCR5 5XuozR5+Ol62dCQFcuwcCsXmiX4kIgkxrWE29n+4wbcqxShvZuyTRj7GIsOl+gjJzOCN fLM1E5no+pCn8H159tF7SfDfyx8pdJ5QCR/vsHBis+cnQxZpwy6fieOXkxQY4SkXoOTN +0XGDB2smenuHW991FnBk6+cq75N05MAJxKrnPOoFDvAYcSF9XztZ2QznxXruobZ/QWc 0TPA== X-Received: by 10.60.45.233 with SMTP id q9mr6718568oem.37.1402717530064; Fri, 13 Jun 2014 20:45:30 -0700 (PDT) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id g3sm12108275obd.18.2014.06.13.20.45.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Jun 2014 20:45:29 -0700 (PDT) Message-ID: <539BC558.7090400@gmail.com> Date: Fri, 13 Jun 2014 22:45:28 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Michael Welzl References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/v3TUpBpdr2YZPYbmJgCVhV8oHhE Cc: taps@ietf.org Subject: Re: [Taps] Today's shipment: the TAPS charter! X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 03:45:32 -0000 On 06/13/2014 02:09 AM, Michael Welzl wrote: > Dear Spencer, > > Finally I'm in a position to ship the fully list-agreed version of the > TAPS charter. It's at: > https://sites.google.com/site/transportprotocolservices/charter-proposal > and at the bottom of this email. I put this on the telechat agenda two weeks hence for INTERNAL review. Then it goes for IETF Last Call, if I understand correctly. Spencer From nobody Thu Jun 19 08:08:05 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA5C1A026E for ; Thu, 19 Jun 2014 08:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 KIlIrqgc8Zzd for ; Thu, 19 Jun 2014 08:08:02 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32B0C1A0274 for ; Thu, 19 Jun 2014 08:08:02 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WxdwW-0002XM-8b for taps@ietf.org; Thu, 19 Jun 2014 17:08:00 +0200 Received: from 089144223153.atnat0032.highway.bob.at ([89.144.223.153] helo=[192.168.1.4]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1WxdwV-0005dN-3G for taps@ietf.org; Thu, 19 Jun 2014 17:08:00 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <539BC558.7090400@gmail.com> Date: Thu, 19 Jun 2014 17:07:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4D387002-EF51-4B47-B015-627947FD8862@ifi.uio.no> References: <539BC558.7090400@gmail.com> To: taps@ietf.org X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 4 sum msgs/h 2 total rcpts 17797 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: ABAC6C1CE7B999C823F883B77E1A25BAA15F6214 X-UiO-SPAM-Test: remote_host: 89.144.223.153 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 16 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/fK11DnpZ6JVlTHRLBmHfQVNoNMk Subject: Re: [Taps] Today's shipment: the TAPS charter! X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2014 15:08:04 -0000 Dear all, Note that we asked for a TAPS BOF slot too, to be able to reserve a = meeting slot before the deadline; this was approved, see = http://wiki.tools.ietf.org/bof/trac/ So I think TAPS will meet, in some form, with some purpose. I don't = quite know how to prepare for this yet, but I do know that anyone = interested in TAPS should consider travelling to Toronto. So prepare a = trip! :) Cheers, Michael On 14. juni 2014, at 05:45, Spencer Dawkins = wrote: >=20 > On 06/13/2014 02:09 AM, Michael Welzl wrote: >> Dear Spencer, >>=20 >> Finally I'm in a position to ship the fully list-agreed version of = the TAPS charter. It's at: >> = https://sites.google.com/site/transportprotocolservices/charter-proposal >> and at the bottom of this email. >=20 > I put this on the telechat agenda two weeks hence for INTERNAL review. = Then it goes for IETF Last Call, if I understand correctly. >=20 > Spencer From nobody Tue Jun 24 09:34:35 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02ADB1B2AB4; Tue, 24 Jun 2014 09:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 e_eSVw9qaWJD; Tue, 24 Jun 2014 09:12:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 467701B2B0B; Tue, 24 Jun 2014 09:11:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Joel Jaeggli" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140624161112.6927.44446.idtracker@ietfa.amsl.com> Date: Tue, 24 Jun 2014 09:11:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/S9Td7_MN0v0iIujA_UoL90PhcoM X-Mailman-Approved-At: Tue, 24 Jun 2014 09:34:34 -0700 Cc: taps@ietf.org Subject: [Taps] Joel Jaeggli's No Objection on charter-ietf-taps-00-00: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 16:12:34 -0000 Joel Jaeggli has entered the following ballot position for charter-ietf-taps-00-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: http://datatracker.ietf.org/doc/charter-ietf-taps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am tempted to ask that it be made explicit that this be ipv6 only. I think that's an important concession for recognizing the ipv4 internet has substantially ossified to the point that stack inovation that is generally useful is confined being above transport. likewise interactions that involve transition technologies should be off the table. From nobody Tue Jun 24 09:38:19 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092821B2A4C; Tue, 24 Jun 2014 09:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 fqyeyTXBgD5M; Tue, 24 Jun 2014 09:38:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C04D31B2B3B; Tue, 24 Jun 2014 09:38:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Joel Jaeggli" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140624163814.6923.57901.idtracker@ietfa.amsl.com> Date: Tue, 24 Jun 2014 09:38:14 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/UfpOPyjvH86bOV_GbUpgLNspIdw Cc: taps@ietf.org Subject: [Taps] Joel Jaeggli's No Objection on charter-ietf-taps-00-00: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 16:38:16 -0000 Joel Jaeggli has entered the following ballot position for charter-ietf-taps-00-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: http://datatracker.ietf.org/doc/charter-ietf-taps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I am tempted to ask that it be made explicit that this be ipv6 only. I think that's an important concession for recognizing the ipv4 internet has substantially ossified to the point that stack inovation that is generally useful is confined being above transport. likewise interactions that involve transition technologies should be off the table. From nobody Tue Jun 24 13:33:29 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB8C1B282A; Tue, 24 Jun 2014 13:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 k6HhBuGFabAh; Tue, 24 Jun 2014 13:33:23 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 788581B27FB; Tue, 24 Jun 2014 13:33:23 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id va2so980148obc.4 for ; Tue, 24 Jun 2014 13:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=b6TiFcfrgNTJUTEJbGL09IEAgGLSBid/qSggp9DrMeo=; b=QhaJH1lwgI8El2lqpZCZp49lPntWkEcmQ0blTPsvxqhkFRsGB3Qmvht1hH/TAqm4P2 CzdCUKqXIGrWkWKdGtcsD5rrSAC7hBl++1K4VjiIxn2oRa5c3OA8I63xkqM9eQVojsRJ Fj703oU5f3Np3W7NibOTGQk+sVQIWKkdAMgD57VoXL6NVlbF6FnK5um10jhHPvJ2ZGOA hq/5HlHqyigd0m4ijcGsxj3Ka3v1uMZ7eA2WqOuMg61k3U6yvdSYHKgzyJb97oqMDtEW xU/jaVo+ZTsY0HpKpD0Fch7ZzP34wN3qT86hg3rmfhWR3PJXukrL7lNbpYbEB456Cbuh FoMw== X-Received: by 10.60.35.104 with SMTP id g8mr3477321oej.41.1403642002917; Tue, 24 Jun 2014 13:33:22 -0700 (PDT) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id ys16sm2334954obc.15.2014.06.24.13.33.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Jun 2014 13:33:21 -0700 (PDT) Message-ID: <53A9E08F.8060706@gmail.com> Date: Tue, 24 Jun 2014 15:33:19 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joel Jaeggli , The IESG References: <20140624163814.6923.57901.idtracker@ietfa.amsl.com> In-Reply-To: <20140624163814.6923.57901.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/7YDs1I4XgBsBgsCNg5-ocKYulsI Cc: taps@ietf.org Subject: Re: [Taps] Joel Jaeggli's No Objection on charter-ietf-taps-00-00: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 20:33:25 -0000 On 06/24/2014 11:38 AM, Joel Jaeggli wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I am tempted to ask that it be made explicit that this be ipv6 only. > > I think that's an important concession for recognizing the ipv4 internet > has substantially ossified to the point that stack inovation that is > generally useful is confined being above transport. > > likewise interactions that involve transition technologies should be off > the table. So, two questions ... Dave Thaler provided comments during internal review that went the other way - suggesting that TAPS should not be limited to the transport layer, but should also include things like websockets, precisely because of the point Joel made. I'm thinking this question needs to go back to the mailing list where we worked out the TAPS charter proposal. Does that sound right? Or should the charter go for external review, and then get munged? Second - I've seen some email today about tools.ietf.org e-mail addresses not working, but Joel's ballot e-mail was pointed directly to the TAPS mailing list, and it's not in the archive yet. That could be in moderator hold, but don't the IESG addresses get whitelisted automatically? Or are other people seeing ietf.org e-mail problems, too? Spencer From nobody Tue Jun 24 14:29:05 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677B51B27D6 for ; Tue, 24 Jun 2014 14:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 lJz7CXP3sDkG for ; Tue, 24 Jun 2014 14:28:58 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B29D1B2813 for ; Tue, 24 Jun 2014 14:28:05 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id wm4so1038682obc.7 for ; Tue, 24 Jun 2014 14:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=HNgDkvJ/1bytlKqZWl8gBTBpnqpIHcEP6lrNnCJundo=; b=WUVulat1fNFY27nSbR18rkRj3EznhobBm1nyeFR3qyDKj1+bHuUvJn0KZkYDc6qhNa c+2zBHNc1Ui3XjoyjuWDERGT0ZMRd1AHaQdRqsyWfmtpybS+5oScgutwU3pRHzp3otcY f3Ln0pFwLYD0zDvKf2vyjlBIf/5z3sYqOE4ZGGAxeuP4p495bju6I+gxh1wF2PYzHjOD KFJNyyFRxKEQBSfJSAX0Pfu/g08GtGbasawFNnVbHagYFtBD0CltdUlpkGKIAY003Zi8 fIu0w1iJ521Vz4gfse+r3TdDQRlMa1VfXsc2qtQV5FtLv/hMdrBSSV5QvzY902brKbfD 2+EQ== X-Received: by 10.182.228.163 with SMTP id sj3mr3822606obc.72.1403645284688; Tue, 24 Jun 2014 14:28:04 -0700 (PDT) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id a9sm2566865obh.24.2014.06.24.14.28.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Jun 2014 14:28:03 -0700 (PDT) Message-ID: <53A9ED60.7090905@gmail.com> Date: Tue, 24 Jun 2014 16:28:00 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "taps@ietf.org" References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: multipart/alternative; boundary="------------080502010106090205070908" Archived-At: http://mailarchive.ietf.org/arch/msg/taps/1ai8qoUpK_P8knCjIhiFjqTFVWs Cc: "tsv-ads@tools.ietf.org" Subject: [Taps] Feedback from Internal WG Review: Transport Services (taps) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 21:29:01 -0000 This is a multi-part message in MIME format. --------------080502010106090205070908 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear TAPSters, I've gotten two pieces of feedback during Internal WG review. They both raise the same issue, but head in opposite directions in resolving that issue. Joel Jaeggli asked whether TAPS should be IPv6-only, given that stack innovation only happens above transport for IPv4 because it's so ossified. Dave Thaler suggested (below) that if the work wasn't constrained to TCP/UDPish transports, it could also address all the stuff that's falling back to HTTP proxy traversal (websockets, etc), and that would be IP version-agnostic anyway. Does the group have thoughts on this? Thanks, Spencer -------- Original Message -------- Subject: RE: [IAB] Internal WG Review: Transport Services (taps) Date: Tue, 17 Jun 2014 16:24:14 +0000 From: Dave Thaler To: iesg@ietf.org , iab@iab.org My feedback below... > -----Original Message----- > From: IAB [mailto:iab-bounces@iab.org] On Behalf Of IESG Secretary > Sent: Monday, June 16, 2014 8:01 AM > To: iesg@ietf.org; iab@iab.org > Subject: [IAB] Internal WG Review: Transport Services (taps) > > A new IETF working group is being considered in the Transport Area. The > draft charter for this working group is provided > below for your review and comment. > > Review time is one week. > > The IETF Secretariat > > Transport Services (taps) > -------------------------------------------------- > Current Status: Proposed Working Group > > Chairs: > > TBD > > Area Director: > > Spencer Dawkins > > Mailing List > Address: taps@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/taps > Archive: http://www.ietf.org/mail-archive/web/taps/ > > Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and the > LEDBAT congestion control mechanism extend the set of transport services > that are available to applications, beyond those provided by TCP and UDP. > For example, SCTP provides potentially faster reliable delivery for > applications that can accept blocks of data out of order, and LEDBAT provides > low-priority "scavenger" communication. > > For an application programmer, it is hard to use protocols other than TCP or > UDP: most network stacks only support TCP and UDP, many firewalls only > pass TCP and UDP, As the IAB discussed at our retreat (and in various RFCs) many firewalls only pass HTTP. As such, I believe it's critical that this work not be constrained to assume TCP or UDP, but must also deal with things needing to go through HTTP proxies (e.g., websockets). > and requiring other transport protocols risks having an > application not work in many environments. Applications, therefore, must > always be able to fall back to TCP or UDP. Same issue here. Falling back to TCP or UDP is not sufficient. > Further, different protocols can > provide the same services in different ways. > Layering decisions must be made (for example, whether a protocol is used > natively or tunneled through UDP). > > Because of these complications, programmers often resort to either using > TCP or implementing their own customized solution over UDP. ... or over HTTP > That can > result in applications re-implementing features already available elsewhere, > and chances of benefiting from other transport protocols are lost. > > There are many ways in which this problem could be addressed; while it may > not yet be clear what the best way forward could be, any approach to > provide a richer set of transport services to applications will have to begin > with the identification of the services that current transport protocols > provide. > > The Working Group will: > > - Identify services provided by existing IETF transport protocols > and congestion control mechanisms. The resulting document will > provide guidance on making a choice among available mechanisms > and protocols to obtain a certain transport service. > > - Specify a subset of those services identified in item 1, which > end systems supporting TAPS need to provide and provide guidance > on choosing among available mechanisms and protocols to obtain > a given transport service. > > - Specify experimental mechanisms to deliver a transport service. > This will explain how to select and engage a protocol, and how > to discover the availability of protocols on an interface (both > end system and path support), in order to provide a basis for > incremental deployment. > > The Working Group will coordinate closely with other Working Groups and > IRTF Research Groups. The above sentence is useless. Either remove it or name specific WGs/RGs. > > The following topics are out of scope of this Working Group: > > - Quality-of-Service (QoS) and tunneling mechanisms and services > > - Definition of new encapsulations and tunneling mechanisms I wonder if the charter should also specifically state that it will not do any concrete (i.e. programming language specific) APIs. I'm thinking it should say so, to avoid lots of discussion on that topic, which seemed to derail the bof. > > Milestones: > M7: Submit summary of the services provided by IETF transport > protocols and congestion control mechanisms to IESG. > M13: Submit end system transport services to IESG. > M14: Submit specification of how the transport services can be > provided to IESG. -Dave --------------080502010106090205070908 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Dear TAPSters,

I've gotten two pieces of feedback during Internal WG review. They both raise the same issue, but head in opposite directions in resolving that issue.

Joel Jaeggli asked whether TAPS should be IPv6-only, given that stack innovation only happens above transport for IPv4 because it's so ossified.

Dave Thaler suggested (below) that if the work wasn't constrained to TCP/UDPish transports, it could also address all the stuff that's falling back to HTTP proxy traversal (websockets, etc), and that would be IP version-agnostic anyway.

Does the group have thoughts on this?

Thanks,

Spencer

-------- Original Message --------
Subject: RE: [IAB] Internal WG Review: Transport Services (taps)
Date: Tue, 17 Jun 2014 16:24:14 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: iesg@ietf.org <iesg@ietf.org>, iab@iab.org <iab@iab.org> 


My feedback below...

> -----Original Message-----
> From: IAB [mailto:iab-bounces@iab.org] On Behalf Of IESG Secretary
> Sent: Monday, June 16, 2014 8:01 AM
> To: iesg@ietf.org; iab@iab.org
> Subject: [IAB] Internal WG Review: Transport Services (taps)
> 
> A new IETF working group is being considered in the Transport Area.  The
> draft charter for this working group is provided
> below for your review and comment.
> 
> Review time is one week.
> 
> The IETF Secretariat
> 
> Transport Services (taps)
> --------------------------------------------------
> Current Status: Proposed Working Group
> 
> Chairs:
> 
> TBD
> 
> Area Director:
> 
> Spencer Dawkins <spencerdawkins.ietf@gmail.com>
> 
> Mailing List
>   Address:	taps@ietf.org
>   To Subscribe:	https://www.ietf.org/mailman/listinfo/taps
>   Archive: 	http://www.ietf.org/mail-archive/web/taps/
> 
> Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and the
> LEDBAT congestion control mechanism extend the set of transport services
> that are available to applications, beyond those provided by TCP and UDP.
> For example, SCTP provides potentially faster reliable delivery for
> applications that can accept blocks of data out of order, and LEDBAT provides
> low-priority "scavenger" communication.
> 
> For an application programmer, it is hard to use protocols other than TCP or
> UDP: most network stacks only support TCP and UDP, many firewalls only
> pass TCP and UDP, 

As the IAB discussed at our retreat (and in various RFCs) many firewalls
only pass HTTP.  As such, I believe it's critical that this work not be constrained
to assume TCP or UDP, but must also deal with things needing to go through
HTTP proxies (e.g., websockets).

> and requiring other transport protocols risks having an
> application not work in many environments. Applications, therefore, must
> always be able to fall back to TCP or UDP.

Same issue here.  Falling back to TCP or UDP is not sufficient.

>  Further, different protocols can
> provide the same services in different ways.
> Layering decisions must be made (for example, whether a protocol is used
> natively or tunneled through UDP).
> 
> Because of these complications, programmers often resort to either using
> TCP or implementing their own customized solution over UDP. 

... or over HTTP

> That can
> result in applications re-implementing features already available elsewhere,
> and chances of benefiting from other transport protocols are lost.
> 
> There are many ways in which this problem could be addressed; while it may
> not yet be clear what the best way forward could be, any approach to
> provide a richer set of transport services to applications will have to begin
> with the identification of the services that current transport protocols
> provide.
> 
> The Working Group will:
> 
> - Identify services provided by existing IETF transport protocols
>   and congestion control mechanisms. The resulting document will
>   provide guidance on making a choice among available mechanisms
>   and protocols to obtain a certain transport service.
> 
> - Specify a subset of those services identified in item 1, which
>   end systems supporting TAPS need to provide and provide guidance
>   on choosing among available mechanisms and protocols to obtain
>   a given transport service.
> 
> - Specify experimental mechanisms to deliver a transport service.
>   This will explain how to select and engage a protocol, and how
>   to discover the availability of protocols on an interface (both
>   end system and path support), in order to provide a basis for
>   incremental deployment.
> 
> The Working Group will coordinate closely with other Working Groups and
> IRTF Research Groups.

The above sentence is useless.  Either remove it or name specific
WGs/RGs.

> 
> The following topics are out of scope of this Working Group:
> 
> - Quality-of-Service (QoS) and tunneling mechanisms and services
> 
> - Definition of new encapsulations and tunneling mechanisms


I wonder if the charter should also specifically state that it will not do
any concrete (i.e. programming language specific) APIs.  I'm thinking
it should say so, to avoid lots of discussion on that topic, which seemed
to derail the bof.

> 
> Milestones:
> M7:  Submit summary of the services provided by IETF transport
>      protocols and congestion control mechanisms to IESG.
> M13: Submit end system transport services to IESG.
> M14: Submit specification of how the transport services can be
>      provided to IESG.

-Dave


--------------080502010106090205070908-- From nobody Tue Jun 24 17:41:53 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9893F1B29EE for ; Tue, 24 Jun 2014 17:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.286 X-Spam-Level: * X-Spam-Status: No, score=1.286 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_AU=0.377, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001] autolearn=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 Yxv_pcaobRXC for ; Tue, 24 Jun 2014 17:41:47 -0700 (PDT) Received: from atp-mxout1.it.nicta.com.au (nicta00008004025056fffe024888.ptr-ipv6.nicta.net [IPv6:2402:1800:0:8004:250:56ff:fe02:4888]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27A91B29F5 for ; Tue, 24 Jun 2014 17:41:46 -0700 (PDT) Received: from atp-exchmbx1.it.nicta.com.au ([221.199.216.119] helo=atp-exchmbx1.in.nicta.com.au) by atp-mxout1.it.nicta.com.au with esmtp (Exim 4.80) (envelope-from ) id 1WzbHM-0006mr-Ie; Wed, 25 Jun 2014 10:41:41 +1000 Received: from ATP-EXCHCAS1.in.nicta.com.au (221.199.216.118) by atp-exchmbx1.in.nicta.com.au (221.199.216.119) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Jun 2014 10:41:35 +1000 Received: from cancey (221.199.216.112) by atp-exchcas1.in.nicta.com.au (221.199.216.118) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Jun 2014 10:41:34 +1000 Received: by cancey (sSMTP sendmail emulation); Wed, 25 Jun 2014 10:41:34 +1000 Date: Wed, 25 Jun 2014 10:41:34 +1000 From: Olivier Mehani To: Spencer Dawkins Message-ID: <20140625004134.GF6242@cancey.nicta.com.au> References: <53A9ED60.7090905@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="/QKKmeG/X/bPShih" Content-Disposition: inline In-Reply-To: <53A9ED60.7090905@gmail.com> X-Accept-Language: fr, en, es User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-7.500.1017-20776.007 X-TM-AS-Result: No--18.686300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Archived-At: http://mailarchive.ietf.org/arch/msg/taps/mhDIR3FwDqKCR4-zke-_P1bvJdc Cc: "tsv-ads@tools.ietf.org" , "taps@ietf.org" Subject: Re: [Taps] Feedback from Internal WG Review: Transport Services (taps) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 00:41:51 -0000 --/QKKmeG/X/bPShih Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, (First post on taps@: I heard of this group yesterday, and it resonates with problems that have been bugging me for a while. I hope my comments are not out of line.) On Tue, Jun 24, 2014 at 04:28:00PM -0500, Spencer Dawkins wrote: > Joel Jaeggli asked whether TAPS should be IPv6-only, given that > stack innovation only happens above transport for IPv4 because it's > so ossified. One of the reason IPv4 is so ossified is for the same reasons that current transports are: the socket API is too specific in selecting an address family, much in the same way as it is too specific in selecting a transport protocol at the moment. =46rom experience porting applications to use IPv6, most of the time changes consist in adding some address family flexibility in the connection management code. However, this flexibility needs to be re-implemented for each application, while it (c|sh)ould be abstracted in lower layers. And we have domain names to map human-friendly strings to network addresses. I think this is a single problem: applications should not have to specifically chose the address family they use, much in the same way as they shouldn't have to chose the transport by name.=20 > Dave Thaler suggested (below) that if the work wasn't constrained to > TCP/UDPish transports, it could also address all the stuff that's > falling back to HTTP proxy traversal (websockets, etc), and that > would be IP version-agnostic anyway. I agree. Assuming IPv6-only feels like creating headaches for the future, when(ever) IPv6 is not the only solution around. On the other hand, being network-agnostic would allow to create some practical migration paths, and transparent upgradability, to IPv6 or other network-ish layers. --=20 Olivier Mehani PGP fingerprint: 4435 CF6A 7C8D DD9B E2DE F5F9 F012 A6E2 98C6 6655 Confidentiality cannot be guaranteed on emails sent or received unencrypted. --/QKKmeG/X/bPShih Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJTqhq+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5MzA1NjQ3NTk5QUQ1MUVBNTkxREJDRkRF OTU2NkI5RDA5NTdEMkQzAAoJEOlWa50JV9LTUOwIAJabvw0crLjyIgpRJCkaWftQ 5jIpTXaVzRWRDTWCfbmGFIfnHWEbpkMgYf1q0SouZoR8viBZu9ng9mTltsTay5J5 GDnCr7JoSI/ua0Zf8YKuDWO/fV4xWaEPotWiyKjvNCYRZV43PcABwCN1k8xPYVDF XScVUQGAxLPjIb4zIrqDq/M0NlzTtsGw+LNsGoXJL9DJAmmOWRduH13uF+5QwTEz ay29AV4XC56lGWxClC6N5+S9gbiETOb/OZWr4rFTViWDT/r/IbVfO3VP6CbgrU/z pom3H0eE3uCRmhmjn6tFA9KrAWsJVJ/ANh+idQiU13DX3GHMuGDaAeHwf3bOp9U= =cQjq -----END PGP SIGNATURE----- --/QKKmeG/X/bPShih-- From nobody Wed Jun 25 00:55:04 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901611B2851 for ; Wed, 25 Jun 2014 00:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 Bhczmvy0wAn1 for ; Wed, 25 Jun 2014 00:55:00 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE80B1A00D8 for ; Wed, 25 Jun 2014 00:54:59 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Wzi2Z-00064b-Dx; Wed, 25 Jun 2014 09:54:47 +0200 Received: from 089144238254.atnat0047.highway.bob.at ([89.144.238.254] helo=[192.168.0.100]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Wzi2U-0007w2-3G; Wed, 25 Jun 2014 09:54:47 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <20140625004134.GF6242@cancey.nicta.com.au> Date: Wed, 25 Jun 2014 09:54:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <66732D5E-EA2E-43AF-941A-8FD97D85B4E3@ifi.uio.no> References: <53A9ED60.7090905@gmail.com> <20140625004134.GF6242@cancey.nicta.com.au> To: Olivier Mehani X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 7 sum msgs/h 3 total rcpts 17870 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D5F82526F18779987E3A84248DA9533C3CE23751 X-UiO-SPAM-Test: remote_host: 89.144.238.254 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 30 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/GmcC4SHr_-q0avrEmTSRPkpWq4c Cc: "tsv-ads@tools.ietf.org" , Spencer Dawkins , "taps@ietf.org" Subject: Re: [Taps] Feedback from Internal WG Review: Transport Services (taps) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 07:55:03 -0000 Hi, I'll give my views below, thinking/hoping that they match what the group = thinks. In this email, I try to answer not only Olivier's points, but = also the points raised by Joel Jaeggli and Dave Thaler. On 25. juni 2014, at 02:41, Olivier Mehani = wrote: > Hi, >=20 > (First post on taps@: I heard of this group yesterday, and it = resonates with > problems that have been bugging me for a while. I hope my comments are > not out of line.) >=20 > On Tue, Jun 24, 2014 at 04:28:00PM -0500, Spencer Dawkins wrote: >> Joel Jaeggli asked whether TAPS should be IPv6-only, given that >> stack innovation only happens above transport for IPv4 because it's >> so ossified. >=20 > One of the reason IPv4 is so ossified is for the same reasons that > current transports are: the socket API is too specific in selecting an > address family, much in the same way as it is too specific in = selecting > a transport protocol at the moment. Indeed. So the ossification problem is related to the API, and = orthogonal to the ossification of transport-over-IPv4 that Joel notes = above (note, I'm not saying it's orthogonal to the *IPv6 deployment* = problem - I agree with you that "this is a single problem" - but more on = that below). =3D> Answering Joel's point: imagine we had IPv6 everywhere. Imagine that, e.g., native SCTP would = seamlessly operate over that IPv6 network. Then, the problem that TAPS = intends to address would still exist: many applications won't use SCTP = because TCP and UDP are exposed, and today, applications are bound to = the services offered by these two protocols. Application programmers = would have to start using the - rather complex - SCTP interface. = Granted, in this scenario, at least the programmer wouldn't have to = implement a fall-back to TCP - but (s)he'd end up with an application = that e.g. works well in FreeBSD but not in Linux (because the = kernel-level Linux SCTP implementation is pretty bad). So, how to solve = this? Maybe run SCTP in user-space. But then, what about another = protocol that's available there - e.g. what about QUIC, doesn't that do = a better job for what I'm trying to solve? Also note: whatever decision = the app programmer takes means that the app would have to be updated in = the future if a new, better protocol comes along. It's really the strict = app - transport protocol binding that must be broken. We want application (or middleware!) programmers to be able to specify = the service they're interested in: Unordered yet faster reliable packet = delivery. Priorities. Partial (timer-bound) reliability. etc. etc., so = that the decisions + work of the application programmer in the above = example can be delegated to a system that automatically tries to do the = best possible job. Architecturally, what such a system would look like isn't necessarily = agreed upon; what we do all seem to agree is that we need to identify = the services provided by today's transports if we want to move in this = direction. This is what TAPS wants to do. > =46rom experience porting applications to use IPv6, most of the time > changes consist in adding some address family flexibility in the > connection management code. However, this flexibility needs to be > re-implemented for each application, while it (c|sh)ould be abstracted > in lower layers. And we have domain names to map human-friendly = strings > to network addresses. >=20 > I think this is a single problem: applications should not have to > specifically chose the address family they use, much in the same way = as > they shouldn't have to chose the transport by name.=20 If we were the POSIX group in charge of updating the socket interface = once and for all, I would agree with you: let's do this whole thing = right, and update the API such that addresses are hidden too. The problem is that TAPS isn't about updating the socket interface = (anymore). We can't "fix the API" for the whole Internet, we can only = hope that people implementing APIs get this right (some already do - = e.g., IIRC, Java only exposes names but not the IP address). To get the transport part right, one needs to first identify the = services provided by today's protocols, and have some idea about how to = use them. To get the "abstract away the address" part right, one might = need guidance as in RFC 6555, but given that this RFC already exists, = what else would you want us to do towards solving that problem? >> Dave Thaler suggested (below) that if the work wasn't constrained to >> TCP/UDPish transports, it could also address all the stuff that's >> falling back to HTTP proxy traversal (websockets, etc), and that >> would be IP version-agnostic anyway. >=20 > I agree. Assuming IPv6-only feels like creating headaches for the > future, when(ever) IPv6 is not the only solution around. On the other > hand, being network-agnostic would allow to create some practical > migration paths, and transparent upgradability, to IPv6 or other > network-ish layers. =3D> Answering Dave's point: I hope I'm not getting this wrong, but this seems to be an architectural = point. The way it stands now, I don't think TAPS is bound to one such = architectural direction - e.g., there could be a TAPS implementation = that uses HTTP proxy traversal etc., and there could be one that = doesn't. But let me be more specific here: the TAPS charter has 3 items listed = under "The Working Group will". The first two (identifying the services, = specifying a subset of these services) shouldn't be limited to one = specific architecture. The third, however, is: *** - Specify experimental mechanisms to deliver a transport service.=20 This will explain how to select and engage a protocol, and how=20 to discover the availability of protocols on an interface (both=20 end system and path support), in order to provide a basis for=20 incremental deployment. *** ...but the idea here is that the group would specify *one* way of doing = it, not the only possible way. Thus, I think we should discuss things like "should this be able to fall = back to HTTP proxy traversal etc.?" in the WG, when we deal with this = work item. I hope this was helpful. In case anything I wrote here doesn't match = what others in the group think, please do speak up! Cheers, Michael From nobody Wed Jun 25 02:05:16 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411AD1B2B26 for ; Wed, 25 Jun 2014 02:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 383_0OK-duzG for ; Wed, 25 Jun 2014 02:05:09 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 162F91B2B20 for ; Wed, 25 Jun 2014 02:05:09 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id CDBD72B40E1; Wed, 25 Jun 2014 10:05:07 +0100 (BST) Received: from 139.133.204.42 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Wed, 25 Jun 2014 10:05:08 +0100 Message-ID: <8855edfcc5bb851a5ad1d40d5fd7805f.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <66732D5E-EA2E-43AF-941A-8FD97D85B4E3@ifi.uio.no> References: <53A9ED60.7090905@gmail.com> <20140625004134.GF6242@cancey.nicta.com.au> <66732D5E-EA2E-43AF-941A-8FD97D85B4E3@ifi.uio.no> Date: Wed, 25 Jun 2014 10:05:08 +0100 From: gorry@erg.abdn.ac.uk To: "Michael Welzl" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/taps/HGEZixN2Bx2C72JcKB0JJbl7gO8 Cc: "tsv-ads@tools.ietf.org" , "taps@ietf.org" , Spencer Dawkins , Olivier Mehani Subject: Re: [Taps] Feedback from Internal WG Review: Transport Services (taps) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 09:05:14 -0000 I think I mostly agree with Michael, in that I think the initial goals need to be focussed, and while there are many things that may spring from this ... some of which would be really good, we shouldn't attempt a redesign of everything at once. See in-line. > Hi, > > I'll give my views below, thinking/hoping that they match what the group > thinks. In this email, I try to answer not only Olivier's points, but also > the points raised by Joel Jaeggli and Dave Thaler. > > > On 25. juni 2014, at 02:41, Olivier Mehani > wrote: > >> Hi, >> >> (First post on taps@: I heard of this group yesterday, and it resonates >> with >> problems that have been bugging me for a while. I hope my comments are >> not out of line.) >> >> On Tue, Jun 24, 2014 at 04:28:00PM -0500, Spencer Dawkins wrote: >>> Joel Jaeggli asked whether TAPS should be IPv6-only, given that >>> stack innovation only happens above transport for IPv4 because it's >>> so ossified. >> >> One of the reason IPv4 is so ossified is for the same reasons that >> current transports are: the socket API is too specific in selecting an >> address family, much in the same way as it is too specific in selecting >> a transport protocol at the moment. > > Indeed. So the ossification problem is related to the API, and orthogonal > to the ossification of transport-over-IPv4 that Joel notes above (note, > I'm not saying it's orthogonal to the *IPv6 deployment* problem - I agree > with you that "this is a single problem" - but more on that below). > > => Answering Joel's point: > imagine we had IPv6 everywhere. Imagine that, e.g., native SCTP would > seamlessly operate over that IPv6 network. Then, the problem that TAPS > intends to address would still exist: many applications won't use SCTP > because TCP and UDP are exposed, and today, applications are bound to the > services offered by these two protocols. Application programmers would > have to start using the - rather complex - SCTP interface. Granted, in > this scenario, at least the programmer wouldn't have to implement a > fall-back to TCP - but (s)he'd end up with an application that e.g. works > well in FreeBSD but not in Linux (because the kernel-level Linux SCTP > implementation is pretty bad). So, how to solve this? Maybe run SCTP in > user-space. But then, what about another protocol that's available there - > e.g. what about QUIC, doesn't that do a better job for what I'm trying to > solve? Also note: whatever decision the app programmer takes means that > the app would have to be updated in the future if a new, better > protocol comes along. It's really the strict app - transport protocol > binding that must be broken. > > We want application (or middleware!) programmers to be able to specify the > service they're interested in: Unordered yet faster reliable packet > delivery. Priorities. Partial (timer-bound) reliability. etc. etc., so > that the decisions + work of the application programmer in the above > example can be delegated to a system that automatically tries to do the > best possible job. > > Architecturally, what such a system would look like isn't necessarily > agreed upon; what we do all seem to agree is that we need to identify the > services provided by today's transports if we want to move in this > direction. This is what TAPS wants to do. > I'd say it was fine to specifically say this will be designed for IPv6 - but then I do not see the rationale about why this couldn't support IPv4 as well. It would seem wrong to constrain yourself to just an IPv6 layer 3, when the focus is on providing the best choice for network traversal. Preferring IPv6 over IPv4 may be a logical choice when both networks can support the same transport services. > >> From experience porting applications to use IPv6, most of the time >> changes consist in adding some address family flexibility in the >> connection management code. However, this flexibility needs to be >> re-implemented for each application, while it (c|sh)ould be abstracted >> in lower layers. And we have domain names to map human-friendly strings >> to network addresses. >> >> I think this is a single problem: applications should not have to >> specifically chose the address family they use, much in the same way as >> they shouldn't have to chose the transport by name. > > If we were the POSIX group in charge of updating the socket interface once > and for all, I would agree with you: let's do this whole thing right, and > update the API such that addresses are hidden too. > > The problem is that TAPS isn't about updating the socket interface > (anymore). We can't "fix the API" for the whole Internet, we can only > hope that people implementing APIs get this right (some already do - e.g., > IIRC, Java only exposes names but not the IP address). > > To get the transport part right, one needs to first identify the services > provided by today's protocols, and have some idea about how to use them. > To get the "abstract away the address" part right, one might need guidance > as in RFC 6555, but given that this RFC already exists, what else would > you want us to do towards solving that problem? > I brought up the API, and it seems we have moved away from the this to focus initial energy on mechanisms - I now really think this is the correct piece of work to progress first - and one that clearly has a strong need for transport expertise. >>> Dave Thaler suggested (below) that if the work wasn't constrained to >>> TCP/UDPish transports, it could also address all the stuff that's >>> falling back to HTTP proxy traversal (websockets, etc), and that >>> would be IP version-agnostic anyway. >> >> I agree. Assuming IPv6-only feels like creating headaches for the >> future, when(ever) IPv6 is not the only solution around. On the other >> hand, being network-agnostic would allow to create some practical >> migration paths, and transparent upgradability, to IPv6 or other >> network-ish layers. > Yes - IPv6 can be important, but binding transport to only be layered directly on IPv6 seems wrong. > => Answering Dave's point: > > I hope I'm not getting this wrong, but this seems to be an architectural > point. The way it stands now, I don't think TAPS is bound to one such > architectural direction - e.g., there could be a TAPS implementation that > uses HTTP proxy traversal etc., and there could be one that doesn't. > > But let me be more specific here: the TAPS charter has 3 items listed > under "The Working Group will". The first two (identifying the services, > specifying a subset of these services) shouldn't be limited to one > specific architecture. The third, however, is: > > *** > - Specify experimental mechanisms to deliver a transport service. > This will explain how to select and engage a protocol, and how > to discover the availability of protocols on an interface (both > end system and path support), in order to provide a basis for > incremental deployment. > *** > > ...but the idea here is that the group would specify *one* way of doing > it, not the only possible way. > Indeed. And any "way" will rely upon workable robust protocol mechanisms... > Thus, I think we should discuss things like "should this be able to fall > back to HTTP proxy traversal etc.?" in the WG, when we deal with this work > item. > > > I hope this was helpful. In case anything I wrote here doesn't match what > others in the group think, please do speak up! > > Cheers, > Michael > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > Gorry From nobody Wed Jun 25 06:19:21 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027691B2C66; Wed, 25 Jun 2014 06:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 tlYBq_3NN-KR; Wed, 25 Jun 2014 06:15:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B2A1B2C61; Wed, 25 Jun 2014 06:15:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> Date: Wed, 25 Jun 2014 06:15:49 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/78rY45IGp86AGjZRyGR2uun6-kk X-Mailman-Approved-At: Wed, 25 Jun 2014 06:19:18 -0700 Cc: taps@ietf.org Subject: [Taps] Benoit Claise's Block on charter-ietf-taps-00-00: (with BLOCK and COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 13:15:52 -0000 Benoit Claise has entered the following ballot position for charter-ietf-taps-00-00: Block 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: http://datatracker.ietf.org/doc/charter-ietf-taps/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- I support the work, but I have a BLOCK anyway. The charter needs to clarify a few points. 1. (somehow similar to Alissa's COMMENT) The charter should mention that the WG will first analyze the set of relevant criteria. I guess that this is what's meant by "services" in this entry but "services" is an overloaded term. Identify services provided by existing IETF transport protocols and congestion control mechanisms. The resulting document will provide guidance on making a choice among available mechanisms and protocols to obtain a certain transport service. Brian Trammell, during his IESG/IAB retreat presentation called that "dimensions of transport": - message atomicity - stream fragmentation - sequence preservation - head-of-line blocking avoidance - sub-channels - full reliability - latency-limited reliability - loss-sensitive congestion control - delay-sensitive congestion control - endpoint address agility - privacy and integrity - path-state propagation (NAT/FW) I don't know if this list is correct or complete. This should be the WG job to compile it. Btw, adding this list to the charter, as a starting point, would make sense. I'm an application designer, I care for a transport that will provide me: - message atomicity - head-of-line blocking avoidance - sub-channels - full reliability - loss-sensitive congestion control How do we call those 5 things? criteria? How do we call the transport that support those 5 things? a transport protocol? a transport service? The "services" term is used multiple times within the charter. Sometimes I understand it as a "transport protocol" (like in the first sentence in the charter), And sometimes I may interpret it as Brian's "dimensions of transport" or criteria. Potentially use "criteria" and "transport protocol" Alternatively, only use "transport services" when it means "criteria, and "transport protocol". I tried to do the latter below. OLD: Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion control mechanism extend the set of transport services that are available to applications, beyond those provided by TCP and UDP. For example, SCTP provides potentially faster reliable delivery for applications that can accept blocks of data out of order, and LEDBAT provides low-priority "scavenger" communication. NEW: Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion control mechanism extend the set of transport protocols that are available to applications, beyond those provided by TCP and UDP. For example, SCTP provides potentially faster reliable delivery for applications that can accept blocks of data out of order, and LEDBAT provides low-priority "scavenger" communication. OLD: - Identify services provided by existing IETF transport protocols and congestion control mechanisms. The resulting document will provide guidance on making a choice among available mechanisms and protocols to obtain a certain transport service. NEW: - Identify transport services provided by existing IETF transport protocols and congestion control mechanisms. The resulting document will provide guidance on making a choice among available mechanisms and protocols to obtain a certain transport service. As a starting point for transport services, the working group can consider: message atomicity, stream fragmentation, sequence preservation, head-of-line blocking avoidance, sub-channels, full reliability, latency-limited reliability, loss-sensitive congestion control, delay-sensitive congestion control, endpoint address agility, privacy and integrity, and path-state propagation (NAT/Firewall). OLD: - Specify a subset of those services identified in item 1, which end systems supporting TAPS need to provide and provide guidance on choosing among available mechanisms and protocols to obtain a given transport service. NEW: - Specify a subset of those transport services identified in item 1, which end systems supporting TAPS need to provide and provide guidance on choosing among available mechanisms and protocols. OLD: - Specify experimental mechanisms to deliver a transport service. This will explain how to select and engage a protocol, and how to discover the availability of protocols on an interface (both end system and path support), in order to provide a basis for incremental deployment. NEW: - Specify experimental mechanisms to deliver a transport protocol. This will explain how to select and engage a protocol, and how to discover the availability of protocol services on an interface (both end system and path support), in order to provide a basis for incremental deployment. 2. - Specify experimental mechanisms to deliver a transport service. This will explain how to select and engage a protocol, and how to discover the availability of protocols on an interface (both end system and path support), in order to provide a basis for incremental deployment. I don't understand what "deliver" mean in the first sentence. 3. It seems that there are multiple problem statements, with two different solution tracks: one for existing transport protocols, another one for new transport protocols. Both rely on the identifying the transport services/criteria, which is good. - existing transport protocols: as you wrote "different protocols can provide the same services in different ways" - existing transport protocols: how do we know if endpoints and the path support those? - new transport protocol development (I got this from my discussion with Brian, true it's not really mentioned in the charter) In your paragraph to which problem statement "this problem" refers to? There are many ways in which this problem could be addressed; while it may not yet be clear what the best way forward could be, any approach to provide a richer set of transport services to applications will have to begin with the identification of the services that current transport protocols provide. Depending on what "this problem" refers to, the solution might be new transport middle layer API services discovery OAM services discovery etc. Discussing with Spencer, it means: "which transport building blocks work for me". So this paragraph should be rephrased. Possible solution OLD: There are many ways in which this problem could be addressed; while it may not yet be clear what the best way forward could be, any approach to provide a richer set of transport services to applications will have to begin with the identification of the services that current transport protocols provide. NEW (this paragraph would make more sense after the 3 bullet points "the Working Group will") The Working Group deliverables will help an application programmer identify the important transport services for his application and determine if those transport services are available on the end points and along the path in the network. An approach to provide a richer set of transport services to applications (which could be part of a future charter) has to begin with the identification of the services that current transport protocols provide. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "The Working Group will coordinate closely with other Working Groups and IRTF Research Groups." You should list the WGs you have in mind. From nobody Wed Jun 25 22:49:06 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEFD1B2F18; Wed, 25 Jun 2014 19:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 yr3FxvFNfMju; Wed, 25 Jun 2014 19:42:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 669BF1B2A35; Wed, 25 Jun 2014 19:42:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140626024225.15756.42862.idtracker@ietfa.amsl.com> Date: Wed, 25 Jun 2014 19:42:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/dJ7n5LzjX_mWS-YrLZrYa2w3mus X-Mailman-Approved-At: Wed, 25 Jun 2014 22:49:02 -0700 Cc: taps@ietf.org Subject: [Taps] Pete Resnick's No Objection on charter-ietf-taps-00-00: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 02:42:27 -0000 Pete Resnick has entered the following ballot position for charter-ietf-taps-00-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: http://datatracker.ietf.org/doc/charter-ietf-taps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This could go for external review as-is. Some things to consider, either now or during external review: I am not as concerned about Benoit that these clarifications need to be made; they won't hurt, but I don't think they're strictly necessary. That said, I do think I'd like to see the word "applications" occur sometime in the work items and the section on coordination. :-) Can someone describe for me the difference between providing a set of "transport services" and providing a "session layer"? Does such a description need to go in here? From nobody Wed Jun 25 22:49:08 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD251B2A58; Wed, 25 Jun 2014 19:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 ncWMiW05iwx6; Wed, 25 Jun 2014 19:52:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE0C1B2A2A; Wed, 25 Jun 2014 19:52:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140626025206.21718.18664.idtracker@ietfa.amsl.com> Date: Wed, 25 Jun 2014 19:52:06 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/CmcpSuNXp55ENa83dmYJKFtaE3w X-Mailman-Approved-At: Wed, 25 Jun 2014 22:49:03 -0700 Cc: taps@ietf.org Subject: [Taps] Pete Resnick's No Objection on charter-ietf-taps-00-00: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 02:52:08 -0000 Pete Resnick has entered the following ballot position for charter-ietf-taps-00-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: http://datatracker.ietf.org/doc/charter-ietf-taps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [Fixing a typo] This could go for external review as-is. Some things to consider, either now or during external review: I am not as concerned as Benoit that his clarifications need to be made; they won't hurt, but I don't think they're strictly necessary. That said, I do think I'd like to see the word "applications" occur sometime in the work items and the section on coordination. :-) Can someone describe for me the difference between providing a set of "transport services" and providing a "session layer"? Does such a description need to go in here? From nobody Thu Jun 26 05:39:17 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58171B2B98; Thu, 26 Jun 2014 05:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham 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 tRj2zKFCiaqV; Thu, 26 Jun 2014 05:39:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDE81B2BA2; Thu, 26 Jun 2014 05:39:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140626123912.25234.16014.idtracker@ietfa.amsl.com> Date: Thu, 26 Jun 2014 05:39:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/EdzHa23XQga8G3qJN315wWgBN9I Cc: taps@ietf.org Subject: [Taps] Spencer Dawkins' Yes on charter-ietf-taps-00-00: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 12:39:15 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-taps-00-00: Yes 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: http://datatracker.ietf.org/doc/charter-ietf-taps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Dave Thaler provided feedback about including HTTP during internal review that I've shared with the mailing list, but it wasn't captured in the datatracker. It's at http://www.ietf.org/mail-archive/web/taps/current/msg00186.html. From nobody Thu Jun 26 06:00:39 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D9E1B2B7D; Thu, 26 Jun 2014 05:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 NeWI3kqovFvr; Thu, 26 Jun 2014 05:13:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2CB41B2B78; Thu, 26 Jun 2014 05:13:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140626121354.7135.81882.idtracker@ietfa.amsl.com> Date: Thu, 26 Jun 2014 05:13:54 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/0fQk9x5nek6xdwVh4O4fbqV4774 X-Mailman-Approved-At: Thu, 26 Jun 2014 06:00:37 -0700 Cc: taps@ietf.org Subject: [Taps] Stephen Farrell's No Objection on charter-ietf-taps-00-00: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 12:13:57 -0000 Stephen Farrell has entered the following ballot position for charter-ietf-taps-00-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: http://datatracker.ietf.org/doc/charter-ietf-taps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Also along the lines of Alissa's comment, I'd be interested in whether and how the security properties of transports are to be handled here. I hope they are, but it'd be good for a final charter to mention that. One specific instance of that that'd be useful to consider could be tcpinc. That might lead to tricky timing, but OTOH, it'd be a pain if tcpinc were ignored here. Many applications actually fall back to (or just stick with) HTTP for the reasons stated here, I don't know if it makes sense to de-scope those applications here or not, but hope that that's discussed during chartering (maybe it has been already?). Stupidly, I find paragraphs and sentences that start with an adverb, comma are harder to read. Annoyingly, for me, this charter does that. Politely, I'd ask you to consider fixing that:-) From nobody Thu Jun 26 09:18:55 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E8A1B2DE4; Thu, 26 Jun 2014 09:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham 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 29wHxaKP-kqV; Thu, 26 Jun 2014 09:06:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 106A81B2DDA; Thu, 26 Jun 2014 08:10:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Adrian Farrel" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140626151022.2107.14750.idtracker@ietfa.amsl.com> Date: Thu, 26 Jun 2014 08:10:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/coXFBJPjpMEkYBSzKcynWmWXq1s X-Mailman-Approved-At: Thu, 26 Jun 2014 09:18:47 -0700 Cc: taps@ietf.org Subject: [Taps] Adrian Farrel's No Objection on charter-ietf-taps-00-00: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 16:06:16 -0000 Adrian Farrel has entered the following ballot position for charter-ietf-taps-00-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: http://datatracker.ietf.org/doc/charter-ietf-taps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Is it really necessary to begin the charter with an adverb, and one that every non-native speaker will need to look up in a dictionary before trying to parse the sentence and work out to what it applies? From nobody Thu Jun 26 15:44:24 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2BF71B2FC3; Thu, 26 Jun 2014 15:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham 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 FSYEuaCKp-sT; Thu, 26 Jun 2014 15:44:14 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.141]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7524F1B278B; Thu, 26 Jun 2014 15:44:14 -0700 (PDT) Received: from [195.245.231.67:41694] by server-5.bemta-5.messagelabs.com id E1/6C-23588-C32ACA35; Thu, 26 Jun 2014 22:44:12 +0000 X-Env-Sender: l.wood@surrey.ac.uk X-Msg-Ref: server-7.tower-82.messagelabs.com!1403822651!26711121!1 X-Originating-IP: [131.227.200.31] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25773 invoked from network); 26 Jun 2014 22:44:11 -0000 Received: from exht011p.surrey.ac.uk (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-7.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 26 Jun 2014 22:44:11 -0000 Received: from EXHY022V.surrey.ac.uk (131.227.201.104) by exht011p.surrey.ac.uk (131.227.200.31) with Microsoft SMTP Server (TLS) id 8.3.348.2; Thu, 26 Jun 2014 23:44:11 +0100 Received: from emea01-am1-obe.outbound.protection.outlook.com (131.227.201.241) by EXHY022v.surrey.ac.uk (131.227.201.104) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 26 Jun 2014 23:44:11 +0100 Received: from AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) by AMSPR06MB437.eurprd06.prod.outlook.com (10.242.23.11) with Microsoft SMTP Server (TLS) id 15.0.969.15; Thu, 26 Jun 2014 22:44:10 +0000 Received: from AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) by AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) with mapi id 15.00.0969.007; Thu, 26 Jun 2014 22:44:10 +0000 From: To: , Thread-Topic: [Taps] Stephen Farrell's No Objection on charter-ietf-taps-00-00: (with COMMENT) Thread-Index: AQHPkT7BFRNFhF6TekqCLK+74ayWm5uD+wVb Date: Thu, 26 Jun 2014 22:44:09 +0000 Message-ID: <1403822649004.74706@surrey.ac.uk> References: <20140626121354.7135.81882.idtracker@ietfa.amsl.com> In-Reply-To: <20140626121354.7135.81882.idtracker@ietfa.amsl.com> Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [124.149.114.231] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 02543CD7CD x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(52044002)(377454003)(189002)(199002)(106356001)(15202345003)(76482001)(79102001)(106116001)(77982001)(74662001)(74502001)(85306003)(66066001)(80022001)(107046002)(92726001)(15395725005)(92566001)(2656002)(46102001)(21056001)(95666004)(87936001)(99396002)(81342001)(36756003)(15198665003)(81542001)(54356999)(4396001)(15975445006)(101416001)(19580405001)(83072002)(31966008)(85852003)(86362001)(76176999)(50986999)(20776003)(83322001)(105586002)(19580395003)(74482001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR06MB437; H:AMSPR06MB439.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: AMSPR06MB437.eurprd06.prod.outlook.com X-CrossPremisesHeadersFiltered: EXHY022v.surrey.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/taps/oo-hEMQZ7bAQOqSeSIFx9Tig-OU Cc: taps@ietf.org Subject: Re: [Taps] Stephen Farrell's No Objection on charter-ietf-taps-00-00: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 22:44:19 -0000 Security is out of scope for this charter - just as QoS is. =0A= =0A= A working group focused on future new security-focused=0A= encapsulations would also be out of scope.=0A= =0A= I have seen emphasis on security above all else derail work on transports e= lsewhere,=0A= to the detriment to getting any decent transport work done. While there's a= lways a=0A= security context to protocol work, explicitly putting security in the chart= er moves=0A= this group to yet another security group, and derails the stated purpose of= the=0A= workgroup.=0A= =0A= I have no objection to the charter - as it stands.=0A= =0A= Sincerely,=0A= =0A= Lloyd Wood=0A= http://about.me/lloydwood=0A= ________________________________________=0A= From: Taps on behalf of Stephen Farrell =0A= Sent: Thursday, 26 June 2014 10:13 PM=0A= To: The IESG=0A= Cc: taps@ietf.org=0A= Subject: [Taps] Stephen Farrell's No Objection on charter-ietf-taps-00-00: = (with COMMENT)=0A= =0A= Stephen Farrell has entered the following ballot position for=0A= charter-ietf-taps-00-00: No Objection=0A= =0A= When responding, please keep the subject line intact and reply to all=0A= email addresses included in the To and CC lines. (Feel free to cut this=0A= introductory paragraph, however.)=0A= =0A= =0A= =0A= The document, along with other ballot positions, can be found here:=0A= http://datatracker.ietf.org/doc/charter-ietf-taps/=0A= =0A= =0A= =0A= ----------------------------------------------------------------------=0A= COMMENT:=0A= ----------------------------------------------------------------------=0A= =0A= =0A= Also along the lines of Alissa's comment, I'd be interested in=0A= whether and how the security properties of transports are to=0A= be handled here. I hope they are, but it'd be good for a final=0A= charter to mention that. One specific instance of that that'd=0A= be useful to consider could be tcpinc. That might lead to=0A= tricky timing, but OTOH, it'd be a pain if tcpinc were ignored=0A= here.=0A= =0A= Many applications actually fall back to (or just stick with) HTTP=0A= for the reasons stated here, I don't know if it makes sense=0A= to de-scope those applications here or not, but hope that=0A= that's discussed during chartering (maybe it has been already?).=0A= =0A= Stupidly, I find paragraphs and sentences that start with=0A= an adverb, comma are harder to read. Annoyingly, for me,=0A= this charter does that. Politely, I'd ask you to consider fixing=0A= that:-)=0A= =0A= =0A= _______________________________________________=0A= Taps mailing list=0A= Taps@ietf.org=0A= https://www.ietf.org/mailman/listinfo/taps= From nobody Thu Jun 26 16:26:13 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49AD1B2803; Thu, 26 Jun 2014 16:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 5_k_yT0MJAMq; Thu, 26 Jun 2014 16:26:08 -0700 (PDT) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 114D71B2FE3; Thu, 26 Jun 2014 16:26:07 -0700 (PDT) Received: by mail-ob0-f171.google.com with SMTP id nu7so4740399obb.2 for ; Thu, 26 Jun 2014 16:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=Eb9ICu2qvsTFlvzDEc4EhppYhUK4qiGSgrUwMm/xgFM=; b=Irn4kpo85kYUc2LBO1Sva6N3f7HeQpN9QyLuUaHIPm/aA1cm4EgfIGY5dyL4OV+5q2 TwXDQ99c4TLtenjUqXyyTv3aaeN/qqQIQUu1xzfRn7p9NwOxv889bTwQcD/wumvaCRBg LGULb50BabswOyM5f4NeSofXQE0bR4yBMLb8+pOusMpCnfriFzWz0gzmrmtmGkGIVX8Y 4vozWQ2OC+5FCpb2CnahulNVrqHk+pqNPcchX+W4WaPN1rwnp9bQp/BNb623MoNuGiuZ Tbmg9yCvnJKieQtyes3Jo8l0jAr6SkShYtaGps0sAF9eFJzrMvQ+Pvf6KpdhNTaaJPJJ dc0A== X-Received: by 10.60.33.199 with SMTP id t7mr14488222oei.73.1403825166309; Thu, 26 Jun 2014 16:26:06 -0700 (PDT) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id w2sm29684997oec.11.2014.06.26.16.26.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Jun 2014 16:26:05 -0700 (PDT) Message-ID: <53ACAC0A.3030406@gmail.com> Date: Thu, 26 Jun 2014 18:26:02 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: l.wood@surrey.ac.uk, stephen.farrell@cs.tcd.ie, iesg@ietf.org References: <20140626121354.7135.81882.idtracker@ietfa.amsl.com> <1403822649004.74706@surrey.ac.uk> In-Reply-To: <1403822649004.74706@surrey.ac.uk> Content-Type: multipart/alternative; boundary="------------070704030403080204040609" Archived-At: http://mailarchive.ietf.org/arch/msg/taps/3nQIFhtGY6F8A0Yso3AyvZlK7sM Cc: taps@ietf.org Subject: [Taps] TAPS relationship with security (was: Re: Stephen Farrell's No Objection on charter-ietf-taps-00-00: (with COMMENT)) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 23:26:10 -0000 This is a multi-part message in MIME format. --------------070704030403080204040609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/26/2014 05:44 PM, l.wood@surrey.ac.uk wrote: > Security is out of scope for this charter - just as QoS is. So, just to try to keep things straight ... the theory is that no matter how one Lego-assembles one's transport, one could use TLS or DTLS above that transport, if one is relying on the aspects of security those mechanisms provide? Does TAPS need to go beyond that? I take Stephen's point about TCPINC happening in parallel with TAPS. I'm wondering if relying on something like TCPINC-ng that would provide TCPINC-style unauthenticated encryption and integrity protection for non-TCP transports would make sense, if that turned out to be feasible, rather than trying to fly in formation with TCPINC, which was approved on the formal telechat earlier today, so it already has a head start ... Spencer > A working group focused on future new security-focused > encapsulations would also be out of scope. > > I have seen emphasis on security above all else derail work on transports elsewhere, > to the detriment to getting any decent transport work done. While there's always a > security context to protocol work, explicitly putting security in the charter moves > this group to yet another security group, and derails the stated purpose of the > workgroup. > > I have no objection to the charter - as it stands. > > Sincerely, > > Lloyd Wood > http://about.me/lloydwood > ________________________________________ > From: Taps on behalf of Stephen Farrell > Sent: Thursday, 26 June 2014 10:13 PM > To: The IESG > Cc: taps@ietf.org > Subject: [Taps] Stephen Farrell's No Objection on charter-ietf-taps-00-00: (with COMMENT) > > Stephen Farrell has entered the following ballot position for > charter-ietf-taps-00-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: > http://datatracker.ietf.org/doc/charter-ietf-taps/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Also along the lines of Alissa's comment, I'd be interested in > whether and how the security properties of transports are to > be handled here. I hope they are, but it'd be good for a final > charter to mention that. One specific instance of that that'd > be useful to consider could be tcpinc. That might lead to > tricky timing, but OTOH, it'd be a pain if tcpinc were ignored > here. > > Many applications actually fall back to (or just stick with) HTTP > for the reasons stated here, I don't know if it makes sense > to de-scope those applications here or not, but hope that > that's discussed during chartering (maybe it has been already?). > > Stupidly, I find paragraphs and sentences that start with > an adverb, comma are harder to read. Annoyingly, for me, > this charter does that. Politely, I'd ask you to consider fixing > that:-) > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --------------070704030403080204040609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 06/26/2014 05:44 PM, l.wood@surrey.ac.uk wrote:
Security is out of scope for this charter - just as QoS is.

So, just to try to keep things straight ... the theory is that no matter how one Lego-assembles one's transport, one could use TLS or DTLS above that transport, if one is relying on the aspects of security those mechanisms provide? Does TAPS need to go beyond that?

I take Stephen's point about TCPINC happening in parallel with TAPS.

I'm wondering if relying on something like TCPINC-ng that would provide TCPINC-style unauthenticated encryption and integrity protection for non-TCP transports would make sense, if that turned out to be feasible, rather than trying to fly in formation with TCPINC, which was approved on the formal telechat earlier today, so it already has a head start ...

Spencer

A working group focused on future new security-focused
encapsulations would also be out of scope.

I have seen emphasis on security above all else derail work on transports elsewhere,
to the detriment to getting any decent transport work done. While there's always a
security context to protocol work, explicitly putting security in the charter moves
this group to yet another security group, and derails the stated purpose of the
workgroup.

I have no objection to the charter - as it stands.

Sincerely,

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: Taps <taps-bounces@ietf.org> on behalf of Stephen Farrell <stephen.farrell@cs.tcd.ie>
Sent: Thursday, 26 June 2014 10:13 PM
To: The IESG
Cc: taps@ietf.org
Subject: [Taps] Stephen Farrell's No Objection on charter-ietf-taps-00-00: (with COMMENT)

Stephen Farrell has entered the following ballot position for
charter-ietf-taps-00-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:
http://datatracker.ietf.org/doc/charter-ietf-taps/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


Also along the lines of Alissa's comment, I'd be interested in
whether and how the security properties of transports are to
be handled here. I hope they are, but it'd be good for a final
charter to mention that. One specific instance of that that'd
be useful to consider could be tcpinc. That might lead to
tricky timing, but OTOH, it'd be a pain if tcpinc were ignored
here.

Many applications actually fall back to (or just stick with) HTTP
for the reasons stated here, I don't know if it makes sense
to de-scope those applications here or not, but hope that
that's discussed during chartering (maybe it has been already?).

Stupidly, I find paragraphs and sentences that start with
an adverb, comma are harder to read. Annoyingly, for me,
this charter does that. Politely, I'd ask you to consider fixing
that:-)


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

--------------070704030403080204040609-- From nobody Thu Jun 26 16:37:23 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA8AF1B2830; Thu, 26 Jun 2014 16:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 ad5vzd2Mdpa9; Thu, 26 Jun 2014 16:37:09 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86A371B2828; Thu, 26 Jun 2014 16:37:08 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id z11so3395543lbi.24 for ; Thu, 26 Jun 2014 16:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ECNf87uU5lscE4TfEEI6pEUrQF+hXVpNEmGarwLOvJo=; b=wtpsngwhazX/jN1nsiwj3nYJW6BuX0KXXEaOKO1IvcorsxeGzHkm3UL6V/YmnoMS9i CIlAT4lFlNQ8LObEAFRhkCZq/zyAI4RPWroGhb6J0an+h3Eva/d+jI2sMFlIc/qJx3AF YHK2ISK8SuWDBzJf0DAQJcTRMyod+sseTNODWvk+SgrO+GUGfM38Y+E0ffeazYY1Ms0m Av4n1OA9glGeURgIHdf2fd8omTyOL2wX6mm0kL/0iFa9V0WwfWvFuniVDlQFY+3bA+4P MSYcW/QXW4KtaJFUmrUyi5EvTALZeG1MVFk/G33RUfIqavYM0H4xDahCGhDscqVva12q OsqA== MIME-Version: 1.0 X-Received: by 10.113.3.69 with SMTP id bu5mr12667729lbd.29.1403825826648; Thu, 26 Jun 2014 16:37:06 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Thu, 26 Jun 2014 16:37:06 -0700 (PDT) In-Reply-To: <53ACAC0A.3030406@gmail.com> References: <20140626121354.7135.81882.idtracker@ietfa.amsl.com> <1403822649004.74706@surrey.ac.uk> <53ACAC0A.3030406@gmail.com> Date: Thu, 26 Jun 2014 19:37:06 -0400 X-Google-Sender-Auth: pCIFiYLzyb3qWcUpZOpVn01FCJE Message-ID: From: Barry Leiba To: Spencer Dawkins Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/U_4FBR0QNi3RxsYyK5TlKXijAtg Cc: taps@ietf.org, IESG , l.wood@surrey.ac.uk, Stephen Farrell Subject: Re: [Taps] TAPS relationship with security (was: Re: Stephen Farrell's No Objection on charter-ietf-taps-00-00: (with COMMENT)) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 23:37:10 -0000 > So, just to try to keep things straight ... the theory is that no matter how > one Lego-assembles one's transport, one could use TLS or DTLS above that > transport, if one is relying on the aspects of security those mechanisms > provide? Does TAPS need to go beyond that? I think it should. I think that encryption, TLS-style server authentication, and the like are just as much transport services as are congestion control and in-order delivery. The whole point here is to remove the specification of what services are needed from the specifics of the transport protocols that provide them. And TLS as we know it today requires TCP. In a TAPS world, it would, itself (if it were not part of the transport layer), have to specify what transport services it requires. I would like to see "transport layer security" become a true part of the transport layer, not in name only. Barry From nobody Thu Jun 26 16:42:36 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0409C1B2830 for ; Thu, 26 Jun 2014 16:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 f-8n8iIXbhsb for ; Thu, 26 Jun 2014 16:42:30 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68B221B3017 for ; Thu, 26 Jun 2014 16:42:22 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id l6so4765119oag.14 for ; Thu, 26 Jun 2014 16:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=x2hqK+5gGQpLHGkueQVn+j4LyDwi7Jul8DP2vtcS4Qc=; b=gj2aX8Q9ek6ur5pT8NnpwftQcct8rB0qQjrR/MUMeM/OaczY7QqLAIOCVlkfXSmWF5 vRUdszPHNfXJBfKsjB1cBh8WXrgXzvwAikDZO4g7tyMlw0PV/RFch93MaZKah3JP+VAZ g5UtCzCqkvdd1P01/dG0YVf58wG7g3iqxWdKJLy9g0bJS4KQn7CyM3lkGuBuDb++IMdz +9gAKi3QZKsPCs4sN5kGxyeDTh7dE/DRUnO2DE98yobq2m3Wq+GBpmrp5bqrocO4EExM K7BPRdEaeo4BhvQ9Vye7avI5ZvzgNBIWcacTAjrebzHl2xdYofDcropO9jPtQUsRJ0TR 3JzQ== X-Received: by 10.60.94.169 with SMTP id dd9mr19352923oeb.58.1403826141715; Thu, 26 Jun 2014 16:42:21 -0700 (PDT) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id jr2sm15445255obb.8.2014.06.26.16.42.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Jun 2014 16:42:20 -0700 (PDT) Message-ID: <53ACAFDA.3060303@gmail.com> Date: Thu, 26 Jun 2014 18:42:18 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: taps@ietf.org References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> In-Reply-To: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/KgPyFl9MiHsVcyshFUWMx-ZcL7Q Cc: Benoit Claise Subject: [Taps] Charter bikeshed #1 - "transport service" (was: Re: Benoit Claise's Block on charter-ietf-taps-00-00: (with BLOCK and COMMENT)) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 23:42:33 -0000 As you'll notice in Benoit's comments below, he's finding "service" and "transport service" to be fairly vague. He ends up proposing that the charter would not use "service" without an adjective, and that the charter use "transport service" to describe "transport protocol + criterion", so in a fairly constrained way. I'd like to use terms in the charter that won't confuse the heck out of the average reader, so I'm curious what the folks on the TAPS mailing list think (after looking at his proposed text changes below, of course, because we would never express an opinion without considering context). I should also mention that a couple of ADs have asked me if TAPS can be described as a session layer. One of my definitions of "session layer" is "surviving transport-layer disconnections and reconnections", and I haven't seen people talking about that on e-mail, so I'm thinking calling it a session layer wouldn't help (replacing a confusing term with another confusing term). I kept Benoit on as CC:, so he can say "yes, that helps", or "no, that's worse", but dropped the rest of the IESG from this part of the conversation, in case this turns out to be a bikeshed. Spencer On 06/25/2014 08:15 AM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > charter-ietf-taps-00-00: Block > > 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: > http://datatracker.ietf.org/doc/charter-ietf-taps/ > > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > I support the work, but I have a BLOCK anyway. The charter needs to > clarify a few points. > > 1. (somehow similar to Alissa's COMMENT) > The charter should mention that the WG will first analyze the set of > relevant criteria. > I guess that this is what's meant by "services" in this entry but > "services" is an overloaded term. > > Identify services provided by existing IETF transport protocols > and congestion control mechanisms. The resulting document will > provide guidance on making a choice among available mechanisms > and protocols to obtain a certain transport service. > > Brian Trammell, during his IESG/IAB retreat presentation called that > "dimensions of transport": > - message atomicity > - stream fragmentation > - sequence preservation > - head-of-line blocking avoidance > - sub-channels > - full reliability > - latency-limited reliability > - loss-sensitive congestion control > - delay-sensitive congestion control > - endpoint address agility > - privacy and integrity > - path-state propagation (NAT/FW) > > I don't know if this list is correct or complete. This should be the WG > job to compile it. > Btw, adding this list to the charter, as a starting point, would make > sense. > > I'm an application designer, I care for a transport that will provide > me: > - message atomicity > - head-of-line blocking avoidance > - sub-channels > - full reliability > - loss-sensitive congestion control > > How do we call those 5 things? criteria? > How do we call the transport that support those 5 things? a transport > protocol? a transport service? > The "services" term is used multiple times within the charter. > Sometimes I understand it as a "transport protocol" (like in the first > sentence in the charter), > And sometimes I may interpret it as Brian's "dimensions of transport" or > criteria. > > Potentially use "criteria" and "transport protocol" > Alternatively, only use "transport services" when it means "criteria, and > "transport protocol". > I tried to do the latter below. > > > OLD: > > Conjointly, transport protocols such as SCTP, DCCP, MPTCP, > UDP-Lite and the LEDBAT congestion control mechanism extend > the set of transport services that are available to > applications, beyond those provided by TCP and UDP. For > example, SCTP provides potentially faster reliable delivery > for applications that can accept blocks of data out of order, > and LEDBAT provides low-priority "scavenger" communication. > > NEW: > Conjointly, transport protocols such as SCTP, DCCP, MPTCP, > UDP-Lite and the LEDBAT congestion control mechanism extend > the set of transport protocols that are available to > applications, beyond those provided by TCP and UDP. For > example, SCTP provides potentially faster reliable delivery > for applications that can accept blocks of data out of order, > and LEDBAT provides low-priority "scavenger" communication. > > OLD: > > - Identify services provided by existing IETF transport protocols > and congestion control mechanisms. The resulting document will > provide guidance on making a choice among available mechanisms > and protocols to obtain a certain transport service. > > > NEW: > > - Identify transport services provided by existing IETF transport > protocols > and congestion control mechanisms. The resulting document will > provide guidance on making a choice among available mechanisms > and protocols to obtain a certain transport service. As a starting > point > for transport services, the working group can consider: message > atomicity, > stream fragmentation, sequence preservation, head-of-line blocking > avoidance, > sub-channels, full reliability, latency-limited reliability, > loss-sensitive > congestion control, delay-sensitive congestion control, endpoint > address agility, > privacy and integrity, and path-state propagation (NAT/Firewall). > > OLD: > > - Specify a subset of those services identified in item 1, which > end systems supporting TAPS need to provide and provide guidance > on choosing among available mechanisms and protocols to obtain > a given transport service. > > NEW: > - Specify a subset of those transport services identified in item 1, > which > end systems supporting TAPS need to provide and provide guidance > on choosing among available mechanisms and protocols. > > > OLD: > - Specify experimental mechanisms to deliver a transport service. > This will explain how to select and engage a protocol, and how > to discover the availability of protocols on an interface (both > end system and path support), in order to provide a basis for > incremental deployment. > > NEW: > - Specify experimental mechanisms to deliver a transport protocol. > This will explain how to select and engage a protocol, and how > to discover the availability of protocol services on an interface (both > > end system and path support), in order to provide a basis for > incremental deployment. > > > 2. > > - Specify experimental mechanisms to deliver a transport service. > This will explain how to select and engage a protocol, and how > to discover the availability of protocols on an interface (both > end system and path support), in order to provide a basis for > incremental deployment. > > I don't understand what "deliver" mean in the first sentence. > > > 3. > It seems that there are multiple problem statements, with two different > solution tracks: one for existing transport protocols, another one for > new transport protocols. > Both rely on the identifying the transport services/criteria, which is > good. > - existing transport protocols: as you wrote "different protocols can > provide the same services in different ways" > - existing transport protocols: how do we know if endpoints and the path > support those? > - new transport protocol development (I got this from my discussion with > Brian, true it's not really mentioned in the charter) > > In your paragraph to which problem statement "this problem" refers to? > > There are many ways in which this problem could be addressed; > while it may not yet be clear what the best way forward could > be, any approach to provide a richer set of transport services > to applications will have to begin with the identification of > the services that current transport protocols provide. > > Depending on what "this problem" refers to, the solution might be > new transport middle layer > API services discovery > OAM services discovery > etc. > > Discussing with Spencer, it means: "which transport building blocks work > for me". > So this paragraph should be rephrased. > Possible solution > > OLD: > > There are many ways in which this problem could be addressed; > while it may not yet be clear what the best way forward could > be, any approach to provide a richer set of transport services > to applications will have to begin with the identification of > the services that current transport protocols provide. > > NEW (this paragraph would make more sense after the 3 bullet points "the > Working Group will") > > The Working Group deliverables will help an application > programmer identify the important transport services for his > application and determine if those transport services are available > on the end points and along the path in the network. An approach to > provide a richer set of transport services to applications (which > could be part of a future charter) has to begin with the > identification of > the services that current transport protocols provide. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > "The Working Group will coordinate closely with other Working Groups and > IRTF Research Groups." > You should list the WGs you have in mind. > > From nobody Thu Jun 26 16:51:11 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E99F1B2AEE; Thu, 26 Jun 2014 16:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 xmo7XYlhiGwT; Thu, 26 Jun 2014 16:51:01 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 252A91B2883; Thu, 26 Jun 2014 16:51:01 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id l6so4773042oag.14 for ; Thu, 26 Jun 2014 16:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=wJq0Wj8DgROjbBD7ArvUAlmyVRvEEJVJiKd3R2unmJc=; b=pFuYJJ6DHtu/VdI1JS0rYuhOP2UiY/zTR3ExhiTHtebqkLfqo4umLip4iNxfks19Q0 gnqfwOFVAAQz9Q5Eto4djQLikGoTEELE/CzlgKmc6lKxg9VpptQy1F1pAC6YLMoJmqdf cv5r7vrQ1/HWpd5qAxKYePG10uEil5uuH9JYZMYdllfrhII+2CSkPPDB2BRNrhotxZTP zFXpkci3RP8X4DBi/RiHHMZijSc0jDOO8f1p7IVm/JkkLX0baFhYmClmFhuO1fc4H+vP 9Kknh+KaG7wd5ME15Gho1fksK/7QpO4ZqiopIK7UZ8nqj1uGxcMFkYsheq4PZCGevb0O YKWg== X-Received: by 10.60.63.3 with SMTP id c3mr19455922oes.16.1403826660626; Thu, 26 Jun 2014 16:51:00 -0700 (PDT) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id pz8sm15477917obc.11.2014.06.26.16.50.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Jun 2014 16:50:59 -0700 (PDT) Message-ID: <53ACB1E1.2000206@gmail.com> Date: Thu, 26 Jun 2014 18:50:57 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: taps@ietf.org References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> In-Reply-To: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/BRcwEw7IHuHFxwYKxeCudeyL1LE Cc: The IESG Subject: [Taps] ANY limit on scope? (was: Re: Benoit Claise's Block on charter-ietf-taps-00-00: (with BLOCK and COMMENT)) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 23:51:03 -0000 On 06/25/2014 08:15 AM, Benoit Claise wrote: > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- ... > 1. (somehow similar to Alissa's COMMENT) > The charter should mention that the WG will first analyze the set of > relevant criteria. > I guess that this is what's meant by "services" in this entry but > "services" is an overloaded term. > > Identify services provided by existing IETF transport protocols > and congestion control mechanisms. The resulting document will > provide guidance on making a choice among available mechanisms > and protocols to obtain a certain transport service. Keeping in mind that most of you haven't seen the TAPS-related slide deck that the IESG and IAB discussed during our day together in Cancun ... there's probably not an INFINITE number of transport services to think about. I'm fine with the resulting working group coming up with the list it will use for subsequent work, but perhaps including a proposed list as a starting point might be helpful. > Brian Trammell, during his IESG/IAB retreat presentation called that > "dimensions of transport": > - message atomicity > - stream fragmentation > - sequence preservation > - head-of-line blocking avoidance > - sub-channels > - full reliability > - latency-limited reliability > - loss-sensitive congestion control > - delay-sensitive congestion control > - endpoint address agility > - privacy and integrity > - path-state propagation (NAT/FW) > > I don't know if this list is correct or complete. This should be the WG > job to compile it. > Btw, adding this list to the charter, as a starting point, would make > sense. If we added this list, or something close to it, to the charter, would someone object (with reasoned objections, of course)? Thanks, Spencer From nobody Thu Jun 26 18:52:20 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB1D1B30CD; Thu, 26 Jun 2014 18:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 6J8Oxfg7ULoq; Thu, 26 Jun 2014 18:52:16 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C3B11B30CC; Thu, 26 Jun 2014 18:52:15 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id va2so4848714obc.4 for ; Thu, 26 Jun 2014 18:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=OO3+jgb1ktoP/FB90D4sGjo4K3CWUh6OVrFiS8+d/S0=; b=LDGJrzFUMc5g95ogPNfRhsanznPdw+apj6o/K274+QC/yn19CJA2QTPIGy48vJ5Fuo fjSSp+mltp11ZtsAyunrV4pFYzced4hn1SmlmK2apo06thjPLddNEN1D19ZE+hJ8P1Sw +/WOY2dKxtfViJUUuLaiM6HIAHejlkXxospy8qmYyXlIhIivBMyFtsMqGN3NRYEYH1GS oABT2hkABXqHRpaynBVyALuix6Qi39cAJn8s4U+iHXnYJhiDbvCzWRUYbGoMnPpYf4Vh jplAScxzxpXzDsch6COAiiENeJhGKbkc4wcJbHOpswZc7T3z55JyPLhZTlTfchBCA4DO BkTg== X-Received: by 10.60.141.67 with SMTP id rm3mr7421337oeb.78.1403833935366; Thu, 26 Jun 2014 18:52:15 -0700 (PDT) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id v7sm16006905obx.0.2014.06.26.18.52.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Jun 2014 18:52:14 -0700 (PDT) Message-ID: <53ACCE4B.3000802@gmail.com> Date: Thu, 26 Jun 2014 20:52:11 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Barry Leiba References: <20140626121354.7135.81882.idtracker@ietfa.amsl.com> <1403822649004.74706@surrey.ac.uk> <53ACAC0A.3030406@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/eN3Z6TGN6NiH9HLPHrk3bw-eUeo Cc: taps@ietf.org, IESG , l.wood@surrey.ac.uk, Stephen Farrell Subject: Re: [Taps] TAPS relationship with security X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 01:52:18 -0000 On 06/26/2014 06:37 PM, Barry Leiba wrote: >> So, just to try to keep things straight ... the theory is that no matter how >> one Lego-assembles one's transport, one could use TLS or DTLS above that >> transport, if one is relying on the aspects of security those mechanisms >> provide? Does TAPS need to go beyond that? > I think it should. I think that encryption, TLS-style server > authentication, and the like are just as much transport services as > are congestion control and in-order delivery. The whole point here is > to remove the specification of what services are needed from the > specifics of the transport protocols that provide them. I get that. What I'm wondering might break into two questions: - How much awareness of security do we expect (and let's say "new") applications to have? and - Is the security part of "transport services" factorable, or do we have to do it in TAPS? I should emphasize that I don't have opinions about the right answer to either of these questions. I'm just holding the pen, and trying to get a charter written that's worth carrying out. Spencer > And TLS as we know it today requires TCP. In a TAPS world, it would, > itself (if it were not part of the transport layer), have to specify > what transport services it requires. > > I would like to see "transport layer security" become a true part of > the transport layer, not in name only. > > Barry From nobody Thu Jun 26 23:49:09 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CC01B3175; Thu, 26 Jun 2014 23:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 6OANzLPOb2ha; Thu, 26 Jun 2014 23:48:59 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06AB71B3165; Thu, 26 Jun 2014 23:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3814; q=dns/txt; s=iport; t=1403851741; x=1405061341; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TfP5Yvnr/IS2l90u4uuKKM3U0ZV0pOaHXuw0AhrHF7Y=; b=GkTgFuLnCQTYc05SGZF7OoESXaSB5DPucaoiEbgIt7veZ2Oetjbuq8Ag RKipRosY/+dJfsnpjAHA8O5XtO9sNhLmOAKQnoCGC7XaQYQVU0ykMy3b+ R8BH/eNuiSrQD0b+uCgsxjK1UwHF7cET1DW0Wk/L88Xei+uWGCF4ZPEJs M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUFADkTrVOtJV2S/2dsb2JhbABbgw1SWoJup0QBAQEBAQEFAW2RPYdAARlwFnWEAwEBAQQBAQEgEToEBxACAQgSBgICJgICAh8GCxUCDgIEAQ0FiC4DEQ2lRZZZDYZQEwSBK4Q5hneBchgbB4J3gUwFlkSCGIF9jWaGD4NCgjA X-IronPort-AV: E=Sophos;i="5.01,558,1400025600"; d="scan'208";a="56381936" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP; 27 Jun 2014 06:49:00 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s5R6mwWa003068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jun 2014 06:48:58 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Fri, 27 Jun 2014 01:48:57 -0500 From: "Joe Hildebrand (jhildebr)" To: Spencer Dawkins , Barry Leiba Thread-Topic: [Taps] TAPS relationship with security Thread-Index: AQHPkapvuTwBBiuUwEuXxOwHAb/KB5uEc6AA Date: Fri, 27 Jun 2014 06:48:57 +0000 Message-ID: References: <20140626121354.7135.81882.idtracker@ietfa.amsl.com> <1403822649004.74706@surrey.ac.uk> <53ACAC0A.3030406@gmail.com> <53ACCE4B.3000802@gmail.com> In-Reply-To: <53ACCE4B.3000802@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [10.82.224.102] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/uKp-flB9eHb5mvEeRDtk9AOo3Rs Cc: Stephen Farrell , IESG , "l.wood@surrey.ac.uk" , "taps@ietf.org" Subject: Re: [Taps] TAPS relationship with security X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 06:49:02 -0000 V2l0aCB0aGlzIHByb3Bvc2VkIGNoYXJ0ZXIsIEkgdGhvdWdodCBUQVBTIHdhc24ndCBnb2luZyB0 byBiZSBidWlsZGluZw0KcHJvdG9jb2xzIGl0c2VsZiwgb3RoZXIgdGhhbiB0aGUgZXhwZXJpbWVu dGFsIHByb3RvY29sIHRvIGNob29zZSBhbW9uZw0KZGlmZmVyZW50IHRyYW5zcG9ydHMgKHdoYXQg d2UndmUgYmVlbiBjYWxsaW5nICJhbmdyeSBleWViYWxscyIgYmVjYXVzZSBvZg0KdGhlIG51bWJl ciBvZiBkaWZmZXJlbnQgY29tYmluYXRpb25zIHlvdSB3b3VsZCBoYXZlIHRvIGNoZWNrIGlmIHlv dSBqdXN0DQpleHRlbmQgaGFwcHkgZXllYmFsbHMgbmFpdmVseSkuDQoNClNvbWUgb2YgdGhlIHRy YW5zcG9ydCBjaGFyYWN0ZXJpc3RpY3Mgd2lsbCBiZSBtb3JlIHNlY3VyaXR5LXJlbGV2YW50IHRo YW4NCm90aGVycywgYW5kIHNob3VsZCBsaWtlbHkgaGF2ZSBhIG5vdGUgdG8gdGhhdCBlZmZlY3Qg aW4gdGhlaXIgZGVzY3JpcHRpb24uDQogT25jZSB3ZSBoYXZlIGEgY2xvc2UtdG8tZXhoYXVzdGl2 ZSBsaXN0IG9mIGNoYXJhY3RlcmlzdGljcyB3aXRoIHRoZWlyIHVzZQ0KY2FzZXMsIGl0IHdpbGwg YmUgbXVjaCBlYXNpZXIgdG8gZG8gYXJjaGl0ZWN0dXJlIG9uIGhvdyB0byBjb21wb3NlIHRob3Nl DQpjaGFyYWN0ZXJpc3RpY3MgaW50byBhIHRyYW5zcG9ydCBpbiBhIHNlY3VyZSBtYW5uZXIuICBJ dCdzICp3YXkqIHRvbyBlYXJseQ0KdG8gZG8gdGhhdCBub3cgYnkgZGVjaWRpbmcgd2hpY2ggY2hh cmFjdGVyaXN0aWNzIGFyZSByZXF1aXJlZC4NCg0KSWYgd2UgbmVlZCB0byBtb2RpZnkgdGhlIHRl eHQgaW4gdGhlIGdyb3VwJ3MgdGhpcmQgYWN0aW9uIGl0ZW0gKCJTcGVjaWZ5DQpleHBlcmltZW50 YWwgbWVjaGFuaXNtcy4uLiIpIHRvIG1ha2UgaXQgbW9yZSBjbGVhciB0aGF0IHRoZXJlIHdvbid0 IGJlIGFueQ0KYWN0dWFsIHRyYW5zcG9ydCBwcm90b2NvbCBkZXZlbG9wbWVudCwgYnV0IG9ubHkg dGhlIGFuZ3J5LWV5ZWJhbGxzIGJpdCwgaXQNCm1pZ2h0IG1ha2UgdGhlIElFU0cgbW9yZSBjb21m b3J0YWJsZS4NCg0KDQpPbiA2LzI2LzE0LCA3OjUyIFBNLCAiU3BlbmNlciBEYXdraW5zIiA8c3Bl bmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20+DQp3cm90ZToNCg0KPg0KPk9uIDA2LzI2LzIwMTQg MDY6MzcgUE0sIEJhcnJ5IExlaWJhIHdyb3RlOg0KPj4+IFNvLCBqdXN0IHRvIHRyeSB0byBrZWVw IHRoaW5ncyBzdHJhaWdodCAuLi4gdGhlIHRoZW9yeSBpcyB0aGF0IG5vDQo+Pj5tYXR0ZXIgaG93 DQo+Pj4gb25lIExlZ28tYXNzZW1ibGVzIG9uZSdzIHRyYW5zcG9ydCwgb25lIGNvdWxkIHVzZSBU TFMgb3IgRFRMUyBhYm92ZQ0KPj4+dGhhdA0KPj4+IHRyYW5zcG9ydCwgaWYgb25lIGlzIHJlbHlp bmcgb24gdGhlIGFzcGVjdHMgb2Ygc2VjdXJpdHkgdGhvc2UNCj4+Pm1lY2hhbmlzbXMNCj4+PiBw cm92aWRlPyBEb2VzIFRBUFMgbmVlZCB0byBnbyBiZXlvbmQgdGhhdD8NCj4+IEkgdGhpbmsgaXQg c2hvdWxkLiAgSSB0aGluayB0aGF0IGVuY3J5cHRpb24sIFRMUy1zdHlsZSBzZXJ2ZXINCj4+IGF1 dGhlbnRpY2F0aW9uLCBhbmQgdGhlIGxpa2UgYXJlIGp1c3QgYXMgbXVjaCB0cmFuc3BvcnQgc2Vy dmljZXMgYXMNCj4+IGFyZSBjb25nZXN0aW9uIGNvbnRyb2wgYW5kIGluLW9yZGVyIGRlbGl2ZXJ5 LiAgVGhlIHdob2xlIHBvaW50IGhlcmUgaXMNCj4+IHRvIHJlbW92ZSB0aGUgc3BlY2lmaWNhdGlv biBvZiB3aGF0IHNlcnZpY2VzIGFyZSBuZWVkZWQgZnJvbSB0aGUNCj4+IHNwZWNpZmljcyBvZiB0 aGUgdHJhbnNwb3J0IHByb3RvY29scyB0aGF0IHByb3ZpZGUgdGhlbS4NCj4NCj5JIGdldCB0aGF0 LiBXaGF0IEknbSB3b25kZXJpbmcgbWlnaHQgYnJlYWsgaW50byB0d28gcXVlc3Rpb25zOg0KPg0K Pi0gSG93IG11Y2ggYXdhcmVuZXNzIG9mIHNlY3VyaXR5IGRvIHdlIGV4cGVjdCAoYW5kIGxldCdz IHNheSAibmV3IikNCj5hcHBsaWNhdGlvbnMgdG8gaGF2ZT8gYW5kDQo+DQo+LSBJcyB0aGUgc2Vj dXJpdHkgcGFydCBvZiAidHJhbnNwb3J0IHNlcnZpY2VzIiBmYWN0b3JhYmxlLCBvciBkbyB3ZSBo YXZlDQo+dG8gZG8gaXQgaW4gVEFQUz8NCj4NCj5JIHNob3VsZCBlbXBoYXNpemUgdGhhdCBJIGRv bid0IGhhdmUgb3BpbmlvbnMgYWJvdXQgdGhlIHJpZ2h0IGFuc3dlciB0bw0KPmVpdGhlciBvZiB0 aGVzZSBxdWVzdGlvbnMuDQo+DQo+SSdtIGp1c3QgaG9sZGluZyB0aGUgcGVuLCBhbmQgdHJ5aW5n IHRvIGdldCBhIGNoYXJ0ZXIgd3JpdHRlbiB0aGF0J3MNCj53b3J0aCBjYXJyeWluZyBvdXQuDQo+ DQo+U3BlbmNlcg0KPg0KPj4gQW5kIFRMUyBhcyB3ZSBrbm93IGl0IHRvZGF5IHJlcXVpcmVzIFRD UC4gIEluIGEgVEFQUyB3b3JsZCwgaXQgd291bGQsDQo+PiBpdHNlbGYgKGlmIGl0IHdlcmUgbm90 IHBhcnQgb2YgdGhlIHRyYW5zcG9ydCBsYXllciksIGhhdmUgdG8gc3BlY2lmeQ0KPj4gd2hhdCB0 cmFuc3BvcnQgc2VydmljZXMgaXQgcmVxdWlyZXMuDQo+Pg0KPj4gSSB3b3VsZCBsaWtlIHRvIHNl ZSAidHJhbnNwb3J0IGxheWVyIHNlY3VyaXR5IiBiZWNvbWUgYSB0cnVlIHBhcnQgb2YNCj4+IHRo ZSB0cmFuc3BvcnQgbGF5ZXIsIG5vdCBpbiBuYW1lIG9ubHkuDQo+Pg0KPj4gQmFycnkNCj4NCj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPlRhcHMgbWFp bGluZyBsaXN0DQo+VGFwc0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdGFwcw0KPg0KDQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0KDQoNCg== From nobody Fri Jun 27 00:56:00 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132241B2F2A; Fri, 27 Jun 2014 00:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 dp_JJpMQZidq; Fri, 27 Jun 2014 00:55:54 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA64C1A02E3; Fri, 27 Jun 2014 00:55:53 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id u10so3764954lbd.33 for ; Fri, 27 Jun 2014 00:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Nto//9c3UAUdvU8/2onwsSDhxohOExom3LeRDvsM5Bk=; b=okpnd4lfQTk9HHogkJcGxWsev/aRmE/HDKJ20Z+86i1zIfs7pb3JYzIFljgvKnCZHI mK0K0yMmQ1GbNxv2DEio6cfgXz798Mu/EUg8PoheIsy0ozDKPE0WcmfD5kTyECPu8NmL BGwBIP1sx3RrydnsiX5T1GlHOvlQ+j/mWSKsSBrfWn9UZMBUZtOHYkza0lkC/K0dvYlr 1RzXRC1e+8nNaXIppqCw28xX+BfDNJf4GZsUSVxMtH7f3Xsf6Qh9vFG/GlKtc63ZuXLU 0BdUTdQoWrCrDXemEe3qL8e7kyzV40zgi0zMutH7fY59EZ7jsjYuV6KnELtDCX9nXGyZ Nrqg== MIME-Version: 1.0 X-Received: by 10.112.84.199 with SMTP id b7mr12349062lbz.25.1403855752076; Fri, 27 Jun 2014 00:55:52 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.104.80 with HTTP; Fri, 27 Jun 2014 00:55:52 -0700 (PDT) In-Reply-To: References: <20140626121354.7135.81882.idtracker@ietfa.amsl.com> <1403822649004.74706@surrey.ac.uk> <53ACAC0A.3030406@gmail.com> <53ACCE4B.3000802@gmail.com> Date: Fri, 27 Jun 2014 03:55:52 -0400 X-Google-Sender-Auth: KZktQ12Kk4w1Dby18BQC4olWSzk Message-ID: From: Barry Leiba To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/eXHyPgdjl9_nQvVzyf8xa7oj4pk Cc: IESG , Stephen Farrell , Spencer Dawkins , "l.wood@surrey.ac.uk" , "taps@ietf.org" Subject: Re: [Taps] TAPS relationship with security X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 07:55:55 -0000 > If we need to modify the text in the group's third action item ("Specify > experimental mechanisms...") to make it more clear that there won't be any > actual transport protocol development, but only the angry-eyeballs bit, it > might make the IESG more comfortable. That would certainly do it for me -- though I was comfortable before, as well. Barry From nobody Fri Jun 27 01:02:15 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280F81B3129; Fri, 27 Jun 2014 01:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 0HlM0hfy75KI; Fri, 27 Jun 2014 01:02:09 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f41]) (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 516FF1B2F2A; Fri, 27 Jun 2014 01:02:09 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from s235i161.wolfson.cam.ac.uk ([128.232.235.161]:43580 helo=[10.0.1.2]) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1X0R6l-00061C-Ql (Exim 4.82_3-c0e5623) (return-path ); Fri, 27 Jun 2014 09:02:07 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Toby Moncaster In-Reply-To: <53ACB1E1.2000206@gmail.com> Date: Fri, 27 Jun 2014 09:02:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACB1E1.2000206@gmail.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.1878.2) Sender: "T. Moncaster" Archived-At: http://mailarchive.ietf.org/arch/msg/taps/lylp4T41ZHek-C1_D0euM2DGyi4 Cc: The IESG , taps@ietf.org Subject: Re: [Taps] ANY limit on scope? (was: Re: Benoit Claise's Block on charter-ietf-taps-00-00: (with BLOCK and COMMENT)) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 08:02:12 -0000 I would have no strong objection so long as it is made really clear that = this is a starting point and not an exhaustive list. Also these are to = some extent a list of desired outcomes that the actual transport = services will provide. Toby On 27 Jun 2014, at 00:50, Spencer Dawkins = wrote: >=20 > On 06/25/2014 08:15 AM, Benoit Claise wrote: >> = ---------------------------------------------------------------------- >> BLOCK: >> = ---------------------------------------------------------------------- >=20 > ... >=20 >> 1. (somehow similar to Alissa's COMMENT) >> The charter should mention that the WG will first analyze the set of >> relevant criteria. >> I guess that this is what's meant by "services" in this entry but >> "services" is an overloaded term. >>=20 >> Identify services provided by existing IETF transport protocols >> and congestion control mechanisms. The resulting document will >> provide guidance on making a choice among available mechanisms >> and protocols to obtain a certain transport service. >=20 > Keeping in mind that most of you haven't seen the TAPS-related slide = deck that the IESG and IAB discussed during our day together in Cancun = ... there's probably not an INFINITE number of transport services to = think about. I'm fine with the resulting working group coming up with = the list it will use for subsequent work, but perhaps including a = proposed list as a starting point might be helpful. >=20 >> Brian Trammell, during his IESG/IAB retreat presentation called that >> "dimensions of transport": >> - message atomicity >> - stream fragmentation >> - sequence preservation >> - head-of-line blocking avoidance >> - sub-channels >> - full reliability >> - latency-limited reliability >> - loss-sensitive congestion control >> - delay-sensitive congestion control >> - endpoint address agility >> - privacy and integrity >> - path-state propagation (NAT/FW) >>=20 >> I don't know if this list is correct or complete. This should be the = WG >> job to compile it. >> Btw, adding this list to the charter, as a starting point, would make >> sense. >=20 > If we added this list, or something close to it, to the charter, would = someone object (with reasoned objections, of course)? >=20 > Thanks, >=20 > Spencer >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Jun 27 01:14:56 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2001A02DE; Fri, 27 Jun 2014 01:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 P4mXmz-y85Rp; Fri, 27 Jun 2014 01:14:32 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 749CE1A02E3; Fri, 27 Jun 2014 01:14:32 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1X0RIk-0001e7-95; Fri, 27 Jun 2014 10:14:30 +0200 Received: from 089144238254.atnat0047.highway.bob.at ([89.144.238.254] helo=[192.168.0.100]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1X0RIj-0004p6-BB; Fri, 27 Jun 2014 10:14:30 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: Date: Fri, 27 Jun 2014 10:14:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <12D0B36B-AEE0-48CC-B1FA-6CBA32DA1780@ifi.uio.no> References: <20140626121354.7135.81882.idtracker@ietfa.amsl.com> <1403822649004.74706@surrey.ac.uk> <53ACAC0A.3030406@gmail.com> <53ACCE4B.3000802@gmail.com> To: Barry Leiba X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 1 sum rcpts/h 8 sum msgs/h 1 total rcpts 17923 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 9D11F06BF77D7800C3601A7422557A82BCE183DB X-UiO-SPAM-Test: remote_host: 89.144.238.254 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 56 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/XEef_gApgas5oarhqKlx2z_R-94 Cc: "l.wood@surrey.ac.uk" , Spencer Dawkins , "Joe Hildebrand \(jhildebr\)" , IESG , Stephen Farrell , "taps@ietf.org" Subject: Re: [Taps] TAPS relationship with security X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 08:14:38 -0000 On 27. juni 2014, at 09:55, Barry Leiba wrote: >> If we need to modify the text in the group's third action item = ("Specify >> experimental mechanisms...") to make it more clear that there won't = be any >> actual transport protocol development, but only the angry-eyeballs = bit, it >> might make the IESG more comfortable. >=20 > That would certainly do it for me -- though I was comfortable before, = as well. And myself, I'm more comfortable with leaving that item as it is :-) Cheers, Michael From nobody Fri Jun 27 02:34:13 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8373D1B2F37 for ; Fri, 27 Jun 2014 02:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 3jYos_fyUJcK for ; Fri, 27 Jun 2014 02:34:04 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE1B1B2CF5 for ; Fri, 27 Jun 2014 02:34:04 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1X0SXi-0001Am-BM; Fri, 27 Jun 2014 11:34:02 +0200 Received: from 089144238254.atnat0047.highway.bob.at ([89.144.238.254] helo=[192.168.0.100]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1X0SXX-0007CU-Pl; Fri, 27 Jun 2014 11:34:02 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_A9EA54FB-02F8-42F6-940F-135B4EE6C3B2" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <53ACAFDA.3060303@gmail.com> Date: Fri, 27 Jun 2014 11:33:46 +0200 Message-Id: <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACAFDA.3060303@gmail.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 7 sum msgs/h 2 total rcpts 17928 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C5BA3F3E1A6A23AC1CD4E152A2D2D594EEBA68B4 X-UiO-SPAM-Test: remote_host: 89.144.238.254 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 59 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/obNhOCqxcEiciEA78ZJVHytLJZs Cc: Benoit Claise , taps@ietf.org Subject: Re: [Taps] Charter bikeshed #1 - "transport service" (was: Re: Benoit Claise's Block on charter-ietf-taps-00-00: (with BLOCK and COMMENT)) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 09:34:11 -0000 --Apple-Mail=_A9EA54FB-02F8-42F6-940F-135B4EE6C3B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I'm afraid this'll have to be long; in line: On 27. juni 2014, at 01:42, Spencer Dawkins = wrote: > As you'll notice in Benoit's comments below, he's finding "service" = and "transport service" to be fairly vague. He ends up proposing that = the charter would not use "service" without an adjective, and that the = charter use "transport service" to describe "transport protocol + = criterion", so in a fairly constrained way. Well, frankly, I don't think that's moving the charter in a good = direction. Talking about services rather than protocols makes it clearer = that we don't want to bind applications to protocols anymore, but rather = to what protocols provide to applications that use them (see, even that = sentence gets a bit strange if I avoid the word service - and if we = don't use that word here, what else is it that a protocol offers / = provides to applications?). > I'd like to use terms in the charter that won't confuse the heck out = of the average reader, so I'm curious what the folks on the TAPS mailing = list think (after looking at his proposed text changes below, of course, = because we would never express an opinion without considering context). I know that the word "service" is very often vaguely used and dislike = the word myself for that - but in fact, here, I think it really is the = best choice. It's about what an application gets from a protocol - e.g. = "characteristics" describes a protocol, i.e. is about internals that may = not be relevant to an application. Indeed, the email below shows some of = that misunderstanding, based on Brian's list. I'll explain below. As for avoiding confusion, having a shortened version of Brian's list as = examples should do it - you see the list, you know what this is about. > I should also mention that a couple of ADs have asked me if TAPS can = be described as a session layer. One of my definitions of "session = layer" is "surviving transport-layer disconnections and reconnections", = and I haven't seen people talking about that on e-mail, so I'm thinking = calling it a session layer wouldn't help (replacing a confusing term = with another confusing term). +1 to your opinion! > I kept Benoit on as CC:, so he can say "yes, that helps", or "no, = that's worse", but dropped the rest of the IESG from this part of the = conversation, in case this turns out to be a bikeshed. >=20 > Spencer >=20 > On 06/25/2014 08:15 AM, Benoit Claise wrote: >> Benoit Claise has entered the following ballot position for >> charter-ietf-taps-00-00: Block >>=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: >> http://datatracker.ietf.org/doc/charter-ietf-taps/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> BLOCK: >> = ---------------------------------------------------------------------- >>=20 >> I support the work, but I have a BLOCK anyway. The charter needs to >> clarify a few points. >>=20 >> 1. (somehow similar to Alissa's COMMENT) >> The charter should mention that the WG will first analyze the set of >> relevant criteria. >> I guess that this is what's meant by "services" in this entry but >> "services" is an overloaded term. >>=20 >> Identify services provided by existing IETF transport protocols >> and congestion control mechanisms. The resulting document will >> provide guidance on making a choice among available mechanisms >> and protocols to obtain a certain transport service. >>=20 >> Brian Trammell, during his IESG/IAB retreat presentation called that >> "dimensions of transport": There you go, he called it "dimensions", not "services", so the list is = broader in scope. I agree with including parts of his list in the = charter, as examples of services, but not the whole list because IMO = some items don't belong there. I'll go through them item by item below, = applying the following criterion: would an application programmer ever = want to say "yes" or "no" to this, without trying to optimize for = specific environment conditions? First, we don't want to replace = complexity with more complexity, so not exposing absolutely every detail = is part of the point here. Second, programmers who prefer to write code = themselves that optimizes for specific environments are probably not the = typical "customers" of TAPS - probably such folks will want to continue = choosing and configuring their protocol directly. I'm not saying TAPS is = meant to be sub-optimal :-) I'm saying it's meant to be able to = automatize optimizing for the path, and so we should probably only = expose things that are related to application requirements, irrespective = of the path. Obviously, we're getting into a sort of discussion that we should have = in the WG-to-be, not now. But my point is: if the group should at some = point decide that what I say above is the way to go, then replacing = "service" with "protocol" etc. gets in the way, and so does the full = list of Brian. As I go through the list, I also raise questions about the items I = criticize, but I don't want to discuss them yet: this is just to = highlight that these items can create a confusion and should be removed = from the list that goes in the charter. >> - message atomicity What's that? That multiple messages are not combined into one packet? = This plays a role for an application only when there is significant loss = (I think). Wouldn't it be nice to have a system that provides atomicity = only when needed and otherwise saves header overhead? I would vote = against exposing that. Either way, I vote it off the list that goes in = the charter, it's not an obvious service to me. >> - stream fragmentation Is this the opposite of atomicity? (then, why is it "stream", not = "message" fragmentation?). If it is, I wouldn't want to include it in = the list for the reasons I gave about atomicity above. >> - sequence preservation Definitely a service! This absolutely depends on your application and = nothing else. >> - head-of-line blocking avoidance Not a service at all, and potentially harmful to expose. This is a = performance optimization, a benefit that you can get if a protocol, set = of protocols, "session layer", whatever you want to call it, does its = job right. Why do I say "potentially harmful"? If an application would = select "I don't need sequence preservation" and "you must give me HOL = blocking avoidance", then this combination can be provided with SCTP, = but we have no way to use normal TCP as a fall-back because it comes = with HOL blocking. So the whole system is limited by this set of = choices. How harmful is such a fall-back however? It's just some extra = delay in a best effort Internet. Just the kind of flexibility that we = may want to have. >> - sub-channels Not a service. You can get the benefits of sub-channels without exposing = them. See: http://heim.ifi.uio.no/michawe/research/publications/globecom2011.pdf for a proof of concept. Indeed, on what basis does an application say "a = sub-channel please"? This is like saying "over UDP please". You = shouldn't have to care. >> - full reliability >> - latency-limited reliability >=20 Yes, reliability is a service, and fine to include in the list. But I'd = rather replace this with any of: "various degrees of reliability" or "various forms of reliability" or = "full / latency-limited / no reliability" ...or something like that. One item, not two, anyway. >> - loss-sensitive congestion control >> - delay-sensitive congestion control "loss-sensitive congestion control" isn't a good name for a service = because it indicates that there would be less loss, but in fact = delay-sensitive congestion controllers tend to lose less :-) The = choice of a loss-sensitive vs. delay-sensitive congestion controller (to = use things that are in RFCs: LEDBAT vs. TCP's AIMD CC.) is a choice of a = trade-off between throughput (potentially less, with LEDBAT) vs. delay = (also potentially less, with LEDBAT). So, first of all, I'd remove "loss-sensitive congestion control" from = the list. Second, using the phrase "congestion control" binds the application = requirement to a specific mechanism. I'd rather use something like "low = delay vs. high throughput". >> - endpoint address agility I'm not sure. Unsure enough to recommend removing it from the list. >> - privacy and integrity See the discussion on security: I'd rather have it removed (given that = this is just a list of examples, we can be rather restrictive about what = goes in it). >> - path-state propagation (NAT/FW) As with security, not sure how much of this / in which form we'd want to = expose, and so I'd feel better if it were removed. >> I don't know if this list is correct or complete. This should be the = WG >> job to compile it. >> Btw, adding this list to the charter, as a starting point, would make >> sense. So, to summarize, here's the complete list that I suggest: - sequence preservation - various degrees of reliability - low delay vs. high throughput Yes it's short, but for a list of examples, that could be ok? >> I'm an application designer, I care for a transport that will provide >> me: >> - message atomicity >> - head-of-line blocking avoidance >> - sub-channels >> - full reliability >> - loss-sensitive congestion control Wouldn't you rather say: - high throughput (don't care so much about low delay) - full reliability - sequence preservation doesn't matter to me ... and have a system underneath automatically gives you head-of-line = blocking avoidance and uses loss-sensitive congestion control? (Ideally, that system would also use sub-channels if they do improve = performance, and provides message atomicity only if this is a benefit, = i.e. only if there is significant loss) >> How do we call those 5 things? criteria? A mess? >> How do we call the transport that support those 5 things? a transport >> protocol? a transport service? >> The "services" term is used multiple times within the charter. >> Sometimes I understand it as a "transport protocol" (like in the = first >> sentence in the charter), >> And sometimes I may interpret it as Brian's "dimensions of transport" = or >> criteria. >>=20 >> Potentially use "criteria" and "transport protocol" >> Alternatively, only use "transport services" when it means "criteria, = and >> "transport protocol". >> I tried to do the latter below. >>=20 >>=20 Again, detailed comments in line: >> OLD: >>=20 >> Conjointly, transport protocols such as SCTP, DCCP, MPTCP, >> UDP-Lite and the LEDBAT congestion control mechanism extend >> the set of transport services that are available to >> applications, beyond those provided by TCP and UDP. For >> example, SCTP provides potentially faster reliable delivery >> for applications that can accept blocks of data out of order, >> and LEDBAT provides low-priority "scavenger" communication. >>=20 >> NEW: >> Conjointly, transport protocols such as SCTP, DCCP, MPTCP, >> UDP-Lite and the LEDBAT congestion control mechanism extend >> the set of transport protocols that are available to >> applications, beyond those provided by TCP and UDP. For >> example, SCTP provides potentially faster reliable delivery >> for applications that can accept blocks of data out of order, >> and LEDBAT provides low-priority "scavenger" communication. Disagree, I'd rather leave it as it is to stress that applications use = services, not protocols. >> OLD: >>=20 >> - Identify services provided by existing IETF transport protocols >> and congestion control mechanisms. The resulting document will >> provide guidance on making a choice among available mechanisms >> and protocols to obtain a certain transport service. >>=20 >>=20 >> NEW: >>=20 >> - Identify transport services provided by existing IETF transport >> protocols >> and congestion control mechanisms. The resulting document will >> provide guidance on making a choice among available mechanisms >> and protocols to obtain a certain transport service. As a starting >> point >> for transport services, the working group can consider: message >> atomicity, >> stream fragmentation, sequence preservation, head-of-line blocking >> avoidance, >> sub-channels, full reliability, latency-limited reliability, >> loss-sensitive >> congestion control, delay-sensitive congestion control, endpoint >> address agility, >> privacy and integrity, and path-state propagation (NAT/Firewall). Sentence 1: "transport services provided by .. transport protocols" = doesn't seem to make things clearer. I'd rather keep "services" in this = sentence - what this means gets concrete anyway due to the list that = follows in sentence 3, and there the phrase "transport services" is used = anyway. The list should be changed, as I argued above. I suggest: NEW: - Identify services provided by existing IETF transport protocols and congestion control mechanisms. The resulting document will provide guidance on making a choice among available mechanisms and protocols to obtain a certain transport service. As a starting = point for transport services, the working group can consider: sequence preservation, various degrees of reliability, low delay vs. high = throughput. >> OLD: >>=20 >> - Specify a subset of those services identified in item 1, which >> end systems supporting TAPS need to provide and provide guidance >> on choosing among available mechanisms and protocols to obtain >> a given transport service. >>=20 >> NEW: >> - Specify a subset of those transport services identified in item 1, >> which >> end systems supporting TAPS need to provide and provide guidance >> on choosing among available mechanisms and protocols. Agreed. >> OLD: >> - Specify experimental mechanisms to deliver a transport service. >> This will explain how to select and engage a protocol, and how >> to discover the availability of protocols on an interface (both >> end system and path support), in order to provide a basis for >> incremental deployment. >>=20 >> NEW: >> - Specify experimental mechanisms to deliver a transport protocol. >> This will explain how to select and engage a protocol, and how >> to discover the availability of protocol services on an interface = (both >>=20 >> end system and path support), in order to provide a basis for >> incremental deployment. Disagree. "deliver a transport protocol" is weird. The intention was to = say "provide a transport service", maybe "deliver" is a bad choice of = words here? So I suggest: NEW: - Specify experimental mechanisms to provide a transport service. This will explain how to select and engage a protocol, and how to discover the availability of protocols on an interface (both end system and path support), in order to provide a basis for incremental deployment. >> 2. >>=20 >> - Specify experimental mechanisms to deliver a transport service. >> This will explain how to select and engage a protocol, and how >> to discover the availability of protocols on an interface (both >> end system and path support), in order to provide a basis for >> incremental deployment. >>=20 >> I don't understand what "deliver" mean in the first sentence. - hence I replaced it with "provide" above. >> 3. >> It seems that there are multiple problem statements, with two = different >> solution tracks: one for existing transport protocols, another one = for >> new transport protocols. >> Both rely on the identifying the transport services/criteria, which = is >> good. >> - existing transport protocols: as you wrote "different protocols can >> provide the same services in different ways" >> - existing transport protocols: how do we know if endpoints and the = path >> support those? >> - new transport protocol development (I got this from my discussion = with >> Brian, true it's not really mentioned in the charter) >>=20 >> In your paragraph to which problem statement "this problem" refers = to? >>=20 >> There are many ways in which this problem could be addressed; >> while it may not yet be clear what the best way forward could >> be, any approach to provide a richer set of transport services >> to applications will have to begin with the identification of >> the services that current transport protocols provide. >>=20 >> Depending on what "this problem" refers to, the solution might be >> new transport middle layer >> API services discovery >> OAM services discovery >> etc. >>=20 >> Discussing with Spencer, it means: "which transport building blocks = work >> for me". This block above has me a bit confused, I think I lack context, so I = won't comment on it. >> So this paragraph should be rephrased. >> Possible solution >>=20 >> OLD: >>=20 >> There are many ways in which this problem could be addressed; >> while it may not yet be clear what the best way forward could >> be, any approach to provide a richer set of transport services >> to applications will have to begin with the identification of >> the services that current transport protocols provide. >>=20 >> NEW (this paragraph would make more sense after the 3 bullet points = "the >> Working Group will") >>=20 >> The Working Group deliverables will help an application >> programmer identify the important transport services for his >> application and determine if those transport services are = available >> on the end points and along the path in the network. An approach = to >> provide a richer set of transport services to applications (which >> could be part of a future charter) has to begin with the >> identification of >> the services that current transport protocols provide. Agreed; I like this change a lot, it's much more concrete and reflects = our intention IMO. >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> "The Working Group will coordinate closely with other Working Groups = and >> IRTF Research Groups." >> You should list the WGs you have in mind. I agree that it looks odd as it stands. I'm not sure what the right = approach is here (simply remove? or what are these groups?) - e.g. = Spencer would know better than me... Cheers, Michael --Apple-Mail=_A9EA54FB-02F8-42F6-940F-135B4EE6C3B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

I'm afraid this'll have to be = long; in line:


On 27. = juni 2014, at 01:42, Spencer Dawkins <spencerdawkins.ietf@gmail.co= m> wrote:

As you'll notice in Benoit's comments below, he's finding = "service" and "transport service" to be fairly vague. He ends up = proposing that the charter would not use "service" without an adjective, = and that the charter use "transport service" to describe "transport = protocol + criterion", so in a fairly constrained = way.

Well, frankly, I don't think = that's moving the charter in a good direction. Talking about services = rather than protocols makes it clearer that we don't want to bind = applications to protocols anymore, but rather to what protocols provide = to applications that use them (see, even that sentence gets a bit = strange if I avoid the word service - and if we don't use that word = here, what else is it that a protocol offers / provides to = applications?).


I'd like to use terms in the charter that won't confuse = the heck out of the average reader, so I'm curious what the folks on the = TAPS mailing list think (after looking at his proposed text changes = below, of course, because we would never express an opinion without = considering context).

I know that = the word "service" is very often vaguely used and dislike the word = myself for that - but in fact, here, I think it really is the best = choice. It's about what an application gets from a protocol - e.g. = "characteristics" describes a protocol, i.e. is about internals that may = not be relevant to an application. Indeed, the email below shows some of = that misunderstanding, based on Brian's list. I'll explain = below.

As for avoiding confusion, having a = shortened version of Brian's list as examples should do it - you see the = list, you know what this is about.


I should also mention that a couple of ADs have asked me = if TAPS can be described as a session layer. One of my definitions of = "session layer" is "surviving transport-layer disconnections and = reconnections", and I haven't seen people talking about that on e-mail, = so I'm thinking calling it a session layer wouldn't help (replacing a = confusing term with another confusing = term).

+1 to your = opinion!


I kept = Benoit on as CC:, so he can say "yes, that helps", or "no, that's = worse", but dropped the rest of the IESG from this part of the = conversation, in case this turns out to be a = bikeshed.

Spencer

On 06/25/2014 08:15 AM, Benoit Claise = wrote:
Benoit Claise has entered the = following ballot position for
charter-ietf-taps-00-00: = Block

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:
http://datatra= cker.ietf.org/doc/charter-ietf-taps/



------------------= ----------------------------------------------------
BLOCK:
--------= --------------------------------------------------------------

I = support the work, but I have a BLOCK anyway. The charter needs = to
clarify a few points.

1. (somehow similar to Alissa's = COMMENT)
The charter should mention that the WG will first analyze = the set of
relevant criteria.
I guess that this is what's meant by = "services" in this entry but
"services" is an overloaded = term.

  Identify services provided by existing IETF = transport protocols
  and congestion control mechanisms. = The resulting document will
  provide guidance on making a = choice among available mechanisms
  and protocols to = obtain a certain transport service.

Brian Trammell, during his = IESG/IAB retreat presentation called that
"dimensions of = transport":

There you go, he = called it "dimensions", not "services", so the list is broader in scope. = I agree with including parts of his list in the charter, as examples of = services, but not the whole list because IMO some items don't belong = there. I'll go through them item by item below, applying the following = criterion: would an application programmer ever want to say "yes" or = "no" to this, without trying to optimize for specific environment = conditions? First, we don't want to replace complexity with more = complexity, so not exposing absolutely every detail is part of the point = here. Second, programmers who prefer to write code themselves that = optimizes for specific environments are probably not the typical = "customers" of TAPS - probably such folks will want to continue choosing = and configuring their protocol directly. I'm not saying TAPS is meant to = be sub-optimal :-)  I'm saying it's meant to be able to automatize = optimizing for the path, and so we should probably only expose things = that are related to application requirements, irrespective of the = path.

Obviously, we're getting into a sort of = discussion that we should have in the WG-to-be, not now. But my point = is: if the group should at some point decide that what I say above is = the way to go, then replacing "service" with "protocol" etc. gets in the = way, and so does the full list of Brian.

As I = go through the list, I also raise questions about the items I criticize, = but I don't want to discuss them yet: this is just to highlight that = these items can create a confusion and should be removed from the list = that goes in the charter.


    - = message = atomicity

What's that? = That multiple messages are not combined into one packet? This plays a = role for an application only when there is significant loss (I think). = Wouldn't it be nice to have a system that provides atomicity only when = needed and otherwise saves header overhead? I would vote against = exposing that. Either way, I vote it off the list that goes in the = charter, it's not an obvious service to = me.


    - stream = fragmentation

Is this = the opposite of atomicity? (then, why is it "stream", not "message" = fragmentation?). If it is, I wouldn't want to include it in the list for = the reasons I gave about atomicity = above.


    - sequence = preservation

Definitely a = service! This absolutely depends on your application and nothing = else.


    - head-of-line blocking = avoidance

Not a service = at all, and potentially harmful to expose. This is a performance = optimization, a benefit that you can get if a protocol, set of = protocols, "session layer", whatever you want to call it, does its job = right. Why do I say "potentially harmful"? If an application would = select "I don't need sequence preservation" and "you must give me HOL = blocking avoidance", then this combination can be provided with SCTP, = but we have no way to use normal TCP as a fall-back because it comes = with HOL blocking. So the whole system is limited by this set of = choices. How harmful is such a fall-back however? It's just some extra = delay in a best effort Internet. Just the kind of flexibility that we = may want to have.


    - = sub-channels

Not a = service. You can get the benefits of sub-channels without exposing them. = See:
for a proof of concept. = Indeed, on what basis does an application say "a sub-channel please"? = This is like saying "over UDP please". You shouldn't have to = care.


    - full = reliability
    - latency-limited = reliability

Yes, = reliability is a service, and fine to include in the list. But I'd = rather replace this with any of:
"various degrees of = reliability" or "various forms of reliability" or "full / = latency-limited / no reliability"
...or something like that. =  One item, not two, = anyway.


    - = loss-sensitive congestion control
    - = delay-sensitive congestion = control

"loss-sensitive = congestion control" isn't a good name for a service because it indicates = that there would be less loss, but in fact delay-sensitive congestion = controllers tend to lose less  :-)    The choice of a = loss-sensitive vs. delay-sensitive congestion controller (to use things = that are in RFCs: LEDBAT vs. TCP's AIMD CC.) is a choice of a trade-off = between throughput (potentially less, with LEDBAT) vs. delay (also = potentially less, with LEDBAT).

So, first of = all, I'd remove "loss-sensitive congestion control" from the = list.

Second, using the phrase "congestion = control" binds the application requirement to a specific mechanism. I'd = rather use something like "low delay vs. high = throughput".


    - endpoint address = agility

I'm not sure. = Unsure enough to recommend removing it from the = list.


    - privacy and = integrity

See the = discussion on security: I'd rather have it removed (given that this is = just a list of examples, we can be rather restrictive about what goes in = it).


    - path-state propagation = (NAT/FW)

As with = security, not sure how much of this / in which form we'd want to expose, = and so I'd feel better if it were = removed.


I don't know if this list is correct or complete. This = should be the WG
job to compile it.
Btw, adding this list to the = charter, as a starting point, would = make
sense.

So, to = summarize, here's the complete list that I = suggest:

- sequence preservation
- = various degrees of reliability
- low delay vs. high = throughput

Yes it's short, but for a list of = examples, that could be ok?


I'm an application designer, I = care for a transport that will provide
me:
=     - message atomicity
=     - head-of-line blocking avoidance
=     - sub-channels
    - = full reliability
    - loss-sensitive congestion = control

Wouldn't you = rather say:
- high throughput (don't care so much about low = delay)
- full reliability
- sequence preservation = doesn't matter to me
... and have a system underneath = automatically gives you head-of-line blocking avoidance and uses = loss-sensitive congestion control?
(Ideally, that system would = also use sub-channels if they do improve performance, and provides = message atomicity only if this is a benefit, i.e. only if there is = significant loss)


How do we call those 5 things? = criteria?

A = mess?


How do we call the transport = that support those 5 things? a transport
protocol? a transport = service?
The "services" term is used multiple times within the = charter.
Sometimes I understand it as a "transport protocol" (like in = the first
sentence in the charter),
And sometimes I may interpret = it as Brian's "dimensions of transport" = or
criteria.

Potentially use "criteria" and "transport = protocol"
Alternatively, only use "transport services" when it means = "criteria, and
"transport protocol".
I tried to do the latter = below.



Again, = detailed comments in line:


OLD:

Conjointly, = transport protocols such as SCTP, DCCP, MPTCP,
UDP-Lite and the = LEDBAT congestion control mechanism extend
the set of transport = services that are available to
applications, beyond those provided by = TCP and UDP. For
example, SCTP provides potentially faster reliable = delivery
for applications that can accept blocks of data out of = order,
and LEDBAT provides low-priority "scavenger" = communication.

NEW:
Conjointly, transport protocols such as = SCTP, DCCP, MPTCP,
UDP-Lite and the LEDBAT congestion control = mechanism extend
the set of transport protocols that are available = to
applications, beyond those provided by TCP and UDP. = For
example, SCTP provides potentially faster reliable = delivery
for applications that can accept blocks of data out of = order,
and LEDBAT provides low-priority "scavenger" = communication.

Disagree, I'd = rather leave it as it is to stress that applications use services, not = protocols.


OLD:

- Identify services = provided by existing IETF transport protocols
  and = congestion control mechanisms. The resulting document will
=   provide guidance on making a choice among available = mechanisms
  and protocols to obtain a certain transport = service.


NEW:

- Identify transport services provided = by existing IETF transport
protocols
  and congestion = control mechanisms. The resulting document will
  provide = guidance on making a choice among available mechanisms
=   and protocols to obtain a certain transport service. As a = starting
point
  for transport services, the working = group can consider: message
atomicity,
  stream = fragmentation, sequence preservation, head-of-line = blocking
avoidance,
  sub-channels, full reliability, = latency-limited reliability,
loss-sensitive
=   congestion control, delay-sensitive congestion control, = endpoint
address agility,
  privacy and integrity, and = path-state propagation = (NAT/Firewall).

Sentence = 1: "transport services provided by ..  transport protocols" doesn't = seem to make things clearer. I'd rather keep "services" in this sentence = - what this means gets concrete anyway due to the list that follows in = sentence 3, and there the phrase "transport services" is used anyway. = The list should be changed, as I argued above. I = suggest:

NEW:

- = Identify services provided by existing IETF transport = protocols
  and congestion control mechanisms. The resulting = document will
  provide guidance on making a choice among = available mechanisms
  and protocols to obtain a certain = transport service. As a starting point
  for transport = services, the working group can consider: sequence
  = preservation, various degrees of reliability, low delay vs. high = throughput.



OLD:

- Specify a subset = of those services identified in item 1, which
  end = systems supporting TAPS need to provide and provide guidance
=   on choosing among available mechanisms and protocols to = obtain
  a given transport service.

NEW:
- = Specify a subset of those transport services identified in item = 1,
which
  end systems supporting TAPS need to provide = and provide guidance
  on choosing among available = mechanisms and = protocols.

Agreed.
<= /div>


OLD:
- Specify experimental mechanisms to deliver a = transport service.
  This will explain how to select and = engage a protocol, and how
  to discover the availability = of protocols on an interface (both
  end system and path = support), in order to provide a basis for
  incremental = deployment.

NEW:
- Specify experimental mechanisms to deliver = a transport protocol.
  This will explain how to select = and engage a protocol, and how
  to discover the = availability of protocol services on an interface (both

=   end system and path support), in order to provide a basis = for
  incremental = deployment.


Dis= agree. "deliver a transport protocol" is weird. The intention was to say = "provide a transport service", maybe "deliver" is a bad choice of words = here? So I suggest:

NEW:
- Specify = experimental mechanisms to provide a transport service.
  This = will explain how to select and engage a protocol, and how
  to = discover the availability of protocols on an interface (both
  = end system and path support), in order to provide a basis for
  = incremental deployment.


2.

- Specify experimental = mechanisms to deliver a transport service.
  This will = explain how to select and engage a protocol, and how
  to = discover the availability of protocols on an interface (both
=   end system and path support), in order to provide a basis = for
  incremental deployment.

I don't understand = what "deliver" mean in the first = sentence.

- hence I replaced = it with "provide" above.


3.
It seems that there are = multiple problem statements, with two different
solution tracks: one = for existing transport protocols, another one for
new transport = protocols.
Both rely on the identifying the transport = services/criteria, which is
good.
- existing transport protocols: = as you wrote "different protocols can
provide the same services in = different ways"
- existing transport protocols: how do we know if = endpoints and the path
support those?
- new transport protocol = development (I got this from my discussion with
Brian, true it's not = really mentioned in the charter)

In your paragraph to which = problem statement "this problem" refers to?

=     There are many ways in which this problem could = be addressed;
    while it may not yet be clear = what the best way forward could
    be, any = approach to provide a richer set of transport services
=     to applications will have to begin with the = identification of
    the services that current = transport protocols provide.

Depending on what "this problem" = refers to, the solution might be
     new = transport middle layer
     API services = discovery
    OAM services discovery
=     etc.

Discussing with Spencer, it means: = "which transport building blocks work
for = me".

This block above = has me a bit confused, I think I lack context, so I won't comment on = it.


So this paragraph should be rephrased.
Possible = solution

OLD:

    There are many ways = in which this problem could be addressed;
=     while it may not yet be clear what the best way = forward could
    be, any approach to provide a = richer set of transport services
    to = applications will have to begin with the identification of
=     the services that current transport protocols = provide.

NEW (this paragraph would make more sense after the 3 = bullet points "the
Working Group will")

=     The Working Group deliverables will help an = application
    programmer identify the = important transport services for his
=     application and determine if those transport = services are available
    on the end points and = along the path in the network. An approach to
=     provide a richer set of transport services to = applications (which
    could be part of a = future charter) has to begin with the
identification of
=     the services that current transport protocols = provide.

Agreed; I like = this change a lot, it's much more concrete and reflects our intention = IMO.


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

 "The Working Group will coordinate = closely with other Working Groups and
IRTF Research Groups."
You = should list the WGs you have in = mind.

I agree that it = looks odd as it stands. I'm not sure what the right approach is here = (simply remove? or what are these groups?) - e.g. Spencer would know = better than = me...

Cheers,
Michael

= --Apple-Mail=_A9EA54FB-02F8-42F6-940F-135B4EE6C3B2-- From nobody Fri Jun 27 03:02:15 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2F51B2F29; Fri, 27 Jun 2014 03:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 493gc6qD-y68; Fri, 27 Jun 2014 03:02:12 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 CBB341B2F28; Fri, 27 Jun 2014 03:02:11 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1X0Syv-0002dj-Ul; Fri, 27 Jun 2014 12:02:09 +0200 Received: from 089144238254.atnat0047.highway.bob.at ([89.144.238.254] helo=[192.168.0.100]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1X0Sym-0002bW-VP; Fri, 27 Jun 2014 12:02:09 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: Date: Fri, 27 Jun 2014 12:01:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <58D9406C-D581-44F1-A1A3-A6593EE5924A@ifi.uio.no> References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACB1E1.2000206@gmail.com> To: Toby Moncaster X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 7 sum msgs/h 1 total rcpts 17932 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F4CF2385E640709B92E2C4BF2E24E927C58AA917 X-UiO-SPAM-Test: remote_host: 89.144.238.254 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 60 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/6Rij_h1HCOg2cjQsEW5Thv9eA7I Cc: taps@ietf.org, Spencer Dawkins , The IESG Subject: Re: [Taps] ANY limit on scope? (was: Re: Benoit Claise's Block on charter-ietf-taps-00-00: (with BLOCK and COMMENT)) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 10:02:14 -0000 I have no problem with adding something close to it (for some definition = of "close" :-) ), but I don't want to add this list as it stands. = This is explained in another thread answering Benoit Claise, where I = explain how only a few items in Brian's list are what I would also call = a "service". While this discussion should happen later, it'd be nice to = have a shorter, more homogeneous list in the charter. For those = interested in the thread but not on the TAPS list, see: http://www.ietf.org/mail-archive/web/taps/current/msg00206.html It boils down to the following charter change: OLD: - Identify services provided by existing IETF transport protocols and congestion control mechanisms. The resulting document will provide guidance on making a choice among available mechanisms and protocols to obtain a certain transport service. NEW, PROPOSED BY BENOIT: - Identify transport services provided by existing IETF transport protocols and congestion control mechanisms. The resulting document will provide guidance on making a choice among available mechanisms and protocols to obtain a certain transport service. As a starting point for transport services, the working group can consider: message atomicity, stream fragmentation, sequence preservation, head-of-line blocking avoidance, sub-channels, full reliability, latency-limited reliability, loss-sensitive congestion control, delay-sensitive congestion control, endpoint address agility, privacy and integrity, and path-state propagation (NAT/Firewall). Sentence 1: "transport services provided by .. transport protocols" = doesn't seem to make things clearer. I'd rather keep "services" in this = sentence - what this means gets concrete anyway due to the list that = follows in sentence 3, and there the phrase "transport services" is used = anyway. The list should be changed, as I argued above. I suggest: NEW, PROPOSED BY ME: - Identify services provided by existing IETF transport protocols and congestion control mechanisms. The resulting document will provide guidance on making a choice among available mechanisms and protocols to obtain a certain transport service. As a starting = point for transport services, the working group can consider: sequence preservation, various degrees of reliability, low delay vs. high = throughput. Cheers, Michael On 27. juni 2014, at 10:02, Toby Moncaster = wrote: > I would have no strong objection so long as it is made really clear = that this is a starting point and not an exhaustive list. Also these are = to some extent a list of desired outcomes that the actual transport = services will provide. >=20 > Toby >=20 > On 27 Jun 2014, at 00:50, Spencer Dawkins = wrote: >=20 >>=20 >> On 06/25/2014 08:15 AM, Benoit Claise wrote: >>> = ---------------------------------------------------------------------- >>> BLOCK: >>> = ---------------------------------------------------------------------- >>=20 >> ... >>=20 >>> 1. (somehow similar to Alissa's COMMENT) >>> The charter should mention that the WG will first analyze the set of >>> relevant criteria. >>> I guess that this is what's meant by "services" in this entry but >>> "services" is an overloaded term. >>>=20 >>> Identify services provided by existing IETF transport protocols >>> and congestion control mechanisms. The resulting document will >>> provide guidance on making a choice among available mechanisms >>> and protocols to obtain a certain transport service. >>=20 >> Keeping in mind that most of you haven't seen the TAPS-related slide = deck that the IESG and IAB discussed during our day together in Cancun = ... there's probably not an INFINITE number of transport services to = think about. I'm fine with the resulting working group coming up with = the list it will use for subsequent work, but perhaps including a = proposed list as a starting point might be helpful. >>=20 >>> Brian Trammell, during his IESG/IAB retreat presentation called that >>> "dimensions of transport": >>> - message atomicity >>> - stream fragmentation >>> - sequence preservation >>> - head-of-line blocking avoidance >>> - sub-channels >>> - full reliability >>> - latency-limited reliability >>> - loss-sensitive congestion control >>> - delay-sensitive congestion control >>> - endpoint address agility >>> - privacy and integrity >>> - path-state propagation (NAT/FW) >>>=20 >>> I don't know if this list is correct or complete. This should be the = WG >>> job to compile it. >>> Btw, adding this list to the charter, as a starting point, would = make >>> sense. >>=20 >> If we added this list, or something close to it, to the charter, = would someone object (with reasoned objections, of course)? >>=20 >> Thanks, >>=20 >> Spencer >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Jun 27 04:19:54 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE2F1B2B06; Fri, 27 Jun 2014 04:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham 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 U3iAw5uV2RvQ; Fri, 27 Jun 2014 04:19:43 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 435191B2F6B; Fri, 27 Jun 2014 04:19:42 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id E5A582B40DA; Fri, 27 Jun 2014 12:19:40 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Fri, 27 Jun 2014 12:19:41 +0100 Message-ID: In-Reply-To: References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACB1E1.2000206@gmail.com> Date: Fri, 27 Jun 2014 12:19:41 +0100 From: gorry@erg.abdn.ac.uk To: "Toby Moncaster" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/taps/ji-5XqUG_-lfpXdc09psVPqnpVM Cc: taps@ietf.org, Spencer Dawkins , The IESG Subject: Re: [Taps] ANY limit on scope? (was: Re: Benoit Claise's Block on charter-ietf-taps-00-00: (with BLOCK and COMMENT)) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 11:19:47 -0000 I kind of thought of this as "transport mechanisms" to support existing "transport protocols"? Gorry > I would have no strong objection so long as it is made really clear that > this is a starting point and not an exhaustive list. Also these are to > some extent a list of desired outcomes that the actual transport services > will provide. > > Toby > > On 27 Jun 2014, at 00:50, Spencer Dawkins > wrote: > >> >> On 06/25/2014 08:15 AM, Benoit Claise wrote: >>> ---------------------------------------------------------------------- >>> BLOCK: >>> ---------------------------------------------------------------------- >> >> ... >> >>> 1. (somehow similar to Alissa's COMMENT) >>> The charter should mention that the WG will first analyze the set of >>> relevant criteria. >>> I guess that this is what's meant by "services" in this entry but >>> "services" is an overloaded term. >>> >>> Identify services provided by existing IETF transport protocols >>> and congestion control mechanisms. The resulting document will >>> provide guidance on making a choice among available mechanisms >>> and protocols to obtain a certain transport service. >> >> Keeping in mind that most of you haven't seen the TAPS-related slide >> deck that the IESG and IAB discussed during our day together in Cancun >> ... there's probably not an INFINITE number of transport services to >> think about. I'm fine with the resulting working group coming up with >> the list it will use for subsequent work, but perhaps including a >> proposed list as a starting point might be helpful. >> >>> Brian Trammell, during his IESG/IAB retreat presentation called that >>> "dimensions of transport": >>> - message atomicity >>> - stream fragmentation >>> - sequence preservation >>> - head-of-line blocking avoidance >>> - sub-channels >>> - full reliability >>> - latency-limited reliability >>> - loss-sensitive congestion control >>> - delay-sensitive congestion control >>> - endpoint address agility >>> - privacy and integrity >>> - path-state propagation (NAT/FW) >>> >>> I don't know if this list is correct or complete. This should be the WG >>> job to compile it. >>> Btw, adding this list to the charter, as a starting point, would make >>> sense. >> >> If we added this list, or something close to it, to the charter, would >> someone object (with reasoned objections, of course)? >> >> Thanks, >> >> Spencer >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Fri Jun 27 06:43:02 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22EC1B31A2 for ; Fri, 27 Jun 2014 06:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 h7ZMeBRyHIxm for ; Fri, 27 Jun 2014 06:42:53 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ECB91B319F for ; Fri, 27 Jun 2014 06:42:53 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id uy5so5377962obc.8 for ; Fri, 27 Jun 2014 06:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=KEQAu3bvckondPSHrSy6WxWjYCeKgVPYl3M9h80ZU40=; b=F1mIGyE3Nhft4PCMj7ZTLZI98ATpbhie+sHfw8Dwjdxh6KFw3Tiqxxl83Of/SLEvcb XUJxd2+WWPQoRn0VijusitadIADulZakcVZVvTqbiKF1x2ajbdbv1FL20aPC+qKqwFnN u0nZmFwJnbWqrvDG5e+RvNfBhU4rWWTamSgvixu+JNY+aPFIsCj5YQ/96OyJnTnYxcF9 WAHWVUw2dotmG/mAFhTfBACdvm2Vof5nJzE4LYzAYtEJIdKkE3CN4YEA3yC9vk80JJ1R prTh4cfC9+/0PiMYuztQ5gw608uLCHK1/aYfE5jXRJJlrx7vBNbkcxzFWE5hJQVhnddw MCEw== X-Received: by 10.60.125.195 with SMTP id ms3mr23318974oeb.40.1403876573000; Fri, 27 Jun 2014 06:42:53 -0700 (PDT) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id tr1sm18902717obb.10.2014.06.27.06.42.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Jun 2014 06:42:51 -0700 (PDT) Message-ID: <53AD74D8.9010906@gmail.com> Date: Fri, 27 Jun 2014 08:42:48 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Michael Welzl References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACAFDA.3060303@gmail.com> <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> In-Reply-To: <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> Content-Type: multipart/alternative; boundary="------------050405030603040708060709" Archived-At: http://mailarchive.ietf.org/arch/msg/taps/hprL3Q0MW5_DUvIJRpO9M8SYKio Cc: Benoit Claise , taps@ietf.org Subject: Re: [Taps] Charter bikeshed #1 - "transport service" X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 13:42:59 -0000 This is a multi-part message in MIME format. --------------050405030603040708060709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 06/27/2014 04:33 AM, Michael Welzl wrote: > Hi, > > I'm afraid this'll have to be long; in line: Hi, Michael, This was long, but helpful. I agree with the point about the working group needing to work through the list, and that not being a requirement for actual charter approval. Would other folk be OK with naming a couple of examples, rather than a starting list, as Benoit and I had been discussing? On one point (that Michael said he was confused about below, so maybe worth explaining better), Benoit and I spent about 20 minutes talking before he balloted his block, and one thing we talked about was the difference between an application knowing what's available on a platform and knowing what's available on the path between two endpoints (so, if I can send UDP to any port to Benoit, but a firewall between me and Michael drops all UDP except for port 53, both of those facts are relevant). This is what we meant when Benoit said "which transport building blocks work for me" below. And thanks for staying engaged. I appreciate it. Spencer > On 27. juni 2014, at 01:42, Spencer Dawkins > > > wrote: > >> As you'll notice in Benoit's comments below, he's finding "service" >> and "transport service" to be fairly vague. He ends up proposing that >> the charter would not use "service" without an adjective, and that >> the charter use "transport service" to describe "transport protocol + >> criterion", so in a fairly constrained way. > > Well, frankly, I don't think that's moving the charter in a good > direction. Talking about services rather than protocols makes it > clearer that we don't want to bind applications to protocols anymore, > but rather to what protocols provide to applications that use them > (see, even that sentence gets a bit strange if I avoid the word > service - and if we don't use that word here, what else is it that a > protocol offers / provides to applications?). > > >> I'd like to use terms in the charter that won't confuse the heck out >> of the average reader, so I'm curious what the folks on the TAPS >> mailing list think (after looking at his proposed text changes below, >> of course, because we would never express an opinion without >> considering context). > > I know that the word "service" is very often vaguely used and dislike > the word myself for that - but in fact, here, I think it really is the > best choice. It's about what an application gets from a protocol - > e.g. "characteristics" describes a protocol, i.e. is about internals > that may not be relevant to an application. Indeed, the email below > shows some of that misunderstanding, based on Brian's list. I'll > explain below. > > As for avoiding confusion, having a shortened version of Brian's list > as examples should do it - you see the list, you know what this is about. > > >> I should also mention that a couple of ADs have asked me if TAPS can >> be described as a session layer. One of my definitions of "session >> layer" is "surviving transport-layer disconnections and >> reconnections", and I haven't seen people talking about that on >> e-mail, so I'm thinking calling it a session layer wouldn't help >> (replacing a confusing term with another confusing term). > > +1 to your opinion! > > >> I kept Benoit on as CC:, so he can say "yes, that helps", or "no, >> that's worse", but dropped the rest of the IESG from this part of the >> conversation, in case this turns out to be a bikeshed. >> >> Spencer >> >> On 06/25/2014 08:15 AM, Benoit Claise wrote: >>> Benoit Claise has entered the following ballot position for >>> charter-ietf-taps-00-00: Block >>> >>> 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: >>> http://datatracker.ietf.org/doc/charter-ietf-taps/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> BLOCK: >>> ---------------------------------------------------------------------- >>> >>> I support the work, but I have a BLOCK anyway. The charter needs to >>> clarify a few points. >>> >>> 1. (somehow similar to Alissa's COMMENT) >>> The charter should mention that the WG will first analyze the set of >>> relevant criteria. >>> I guess that this is what's meant by "services" in this entry but >>> "services" is an overloaded term. >>> >>> Identify services provided by existing IETF transport protocols >>> and congestion control mechanisms. The resulting document will >>> provide guidance on making a choice among available mechanisms >>> and protocols to obtain a certain transport service. >>> >>> Brian Trammell, during his IESG/IAB retreat presentation called that >>> "dimensions of transport": > > There you go, he called it "dimensions", not "services", so the list > is broader in scope. I agree with including parts of his list in the > charter, as examples of services, but not the whole list because IMO > some items don't belong there. I'll go through them item by item > below, applying the following criterion: would an application > programmer ever want to say "yes" or "no" to this, without trying to > optimize for specific environment conditions? First, we don't want to > replace complexity with more complexity, so not exposing absolutely > every detail is part of the point here. Second, programmers who prefer > to write code themselves that optimizes for specific environments are > probably not the typical "customers" of TAPS - probably such folks > will want to continue choosing and configuring their protocol > directly. I'm not saying TAPS is meant to be sub-optimal :-) I'm > saying it's meant to be able to automatize optimizing for the path, > and so we should probably only expose things that are related to > application requirements, irrespective of the path. > > Obviously, we're getting into a sort of discussion that we should have > in the WG-to-be, not now. But my point is: if the group should at some > point decide that what I say above is the way to go, then replacing > "service" with "protocol" etc. gets in the way, and so does the full > list of Brian. > > As I go through the list, I also raise questions about the items I > criticize, but I don't want to discuss them yet: this is just to > highlight that these items can create a confusion and should be > removed from the list that goes in the charter. > > >>> - message atomicity > > What's that? That multiple messages are not combined into one packet? > This plays a role for an application only when there is significant > loss (I think). Wouldn't it be nice to have a system that provides > atomicity only when needed and otherwise saves header overhead? I > would vote against exposing that. Either way, I vote it off the list > that goes in the charter, it's not an obvious service to me. > > >>> - stream fragmentation > > Is this the opposite of atomicity? (then, why is it "stream", not > "message" fragmentation?). If it is, I wouldn't want to include it in > the list for the reasons I gave about atomicity above. > > >>> - sequence preservation > > Definitely a service! This absolutely depends on your application and > nothing else. > > >>> - head-of-line blocking avoidance > > Not a service at all, and potentially harmful to expose. This is a > performance optimization, a benefit that you can get if a protocol, > set of protocols, "session layer", whatever you want to call it, does > its job right. Why do I say "potentially harmful"? If an application > would select "I don't need sequence preservation" and "you must give > me HOL blocking avoidance", then this combination can be provided with > SCTP, but we have no way to use normal TCP as a fall-back because it > comes with HOL blocking. So the whole system is limited by this set of > choices. How harmful is such a fall-back however? It's just some extra > delay in a best effort Internet. Just the kind of flexibility that we > may want to have. > > >>> - sub-channels > > Not a service. You can get the benefits of sub-channels without > exposing them. See: > http://heim.ifi.uio.no/michawe/research/publications/globecom2011.pdf > for a proof of concept. Indeed, on what basis does an application say > "a sub-channel please"? This is like saying "over UDP please". You > shouldn't have to care. > > >>> - full reliability >>> - latency-limited reliability >> > Yes, reliability is a service, and fine to include in the list. But > I'd rather replace this with any of: > "various degrees of reliability" or "various forms of reliability" or > "full / latency-limited / no reliability" > ...or something like that. One item, not two, anyway. > > >>> - loss-sensitive congestion control >>> - delay-sensitive congestion control > > "loss-sensitive congestion control" isn't a good name for a service > because it indicates that there would be less loss, but in fact > delay-sensitive congestion controllers tend to lose less :-) The > choice of a loss-sensitive vs. delay-sensitive congestion controller > (to use things that are in RFCs: LEDBAT vs. TCP's AIMD CC.) is a > choice of a trade-off between throughput (potentially less, with > LEDBAT) vs. delay (also potentially less, with LEDBAT). > > So, first of all, I'd remove "loss-sensitive congestion control" from > the list. > > Second, using the phrase "congestion control" binds the application > requirement to a specific mechanism. I'd rather use something like > "low delay vs. high throughput". > > >>> - endpoint address agility > > I'm not sure. Unsure enough to recommend removing it from the list. > > >>> - privacy and integrity > > See the discussion on security: I'd rather have it removed (given that > this is just a list of examples, we can be rather restrictive about > what goes in it). > > >>> - path-state propagation (NAT/FW) > > As with security, not sure how much of this / in which form we'd want > to expose, and so I'd feel better if it were removed. > > >>> I don't know if this list is correct or complete. This should be the WG >>> job to compile it. >>> Btw, adding this list to the charter, as a starting point, would make >>> sense. > > So, to summarize, here's the complete list that I suggest: > > - sequence preservation > - various degrees of reliability > - low delay vs. high throughput > > Yes it's short, but for a list of examples, that could be ok? > > >>> I'm an application designer, I care for a transport that will provide >>> me: >>> - message atomicity >>> - head-of-line blocking avoidance >>> - sub-channels >>> - full reliability >>> - loss-sensitive congestion control > > Wouldn't you rather say: > - high throughput (don't care so much about low delay) > - full reliability > - sequence preservation doesn't matter to me > ... and have a system underneath automatically gives you head-of-line > blocking avoidance and uses loss-sensitive congestion control? > (Ideally, that system would also use sub-channels if they do improve > performance, and provides message atomicity only if this is a benefit, > i.e. only if there is significant loss) > > >>> How do we call those 5 things? criteria? > > A mess? > > >>> How do we call the transport that support those 5 things? a transport >>> protocol? a transport service? >>> The "services" term is used multiple times within the charter. >>> Sometimes I understand it as a "transport protocol" (like in the first >>> sentence in the charter), >>> And sometimes I may interpret it as Brian's "dimensions of transport" or >>> criteria. >>> >>> Potentially use "criteria" and "transport protocol" >>> Alternatively, only use "transport services" when it means >>> "criteria, and >>> "transport protocol". >>> I tried to do the latter below. >>> >>> > > Again, detailed comments in line: > > >>> OLD: >>> >>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP, >>> UDP-Lite and the LEDBAT congestion control mechanism extend >>> the set of transport services that are available to >>> applications, beyond those provided by TCP and UDP. For >>> example, SCTP provides potentially faster reliable delivery >>> for applications that can accept blocks of data out of order, >>> and LEDBAT provides low-priority "scavenger" communication. >>> >>> NEW: >>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP, >>> UDP-Lite and the LEDBAT congestion control mechanism extend >>> the set of transport protocols that are available to >>> applications, beyond those provided by TCP and UDP. For >>> example, SCTP provides potentially faster reliable delivery >>> for applications that can accept blocks of data out of order, >>> and LEDBAT provides low-priority "scavenger" communication. > > Disagree, I'd rather leave it as it is to stress that applications use > services, not protocols. > > >>> OLD: >>> >>> - Identify services provided by existing IETF transport protocols >>> and congestion control mechanisms. The resulting document will >>> provide guidance on making a choice among available mechanisms >>> and protocols to obtain a certain transport service. >>> >>> >>> NEW: >>> >>> - Identify transport services provided by existing IETF transport >>> protocols >>> and congestion control mechanisms. The resulting document will >>> provide guidance on making a choice among available mechanisms >>> and protocols to obtain a certain transport service. As a starting >>> point >>> for transport services, the working group can consider: message >>> atomicity, >>> stream fragmentation, sequence preservation, head-of-line blocking >>> avoidance, >>> sub-channels, full reliability, latency-limited reliability, >>> loss-sensitive >>> congestion control, delay-sensitive congestion control, endpoint >>> address agility, >>> privacy and integrity, and path-state propagation (NAT/Firewall). > > Sentence 1: "transport services provided by .. transport protocols" > doesn't seem to make things clearer. I'd rather keep "services" in > this sentence - what this means gets concrete anyway due to the list > that follows in sentence 3, and there the phrase "transport services" > is used anyway. The list should be changed, as I argued above. I suggest: > > NEW: > > - Identify services provided by existing IETF transport protocols > and congestion control mechanisms. The resulting document will > provide guidance on making a choice among available mechanisms > and protocols to obtain a certain transport service. As a starting point > for transport services, the working group can consider: sequence > preservation, various degrees of reliability, low delay vs. high > throughput. > > > >>> OLD: >>> >>> - Specify a subset of those services identified in item 1, which >>> end systems supporting TAPS need to provide and provide guidance >>> on choosing among available mechanisms and protocols to obtain >>> a given transport service. >>> >>> NEW: >>> - Specify a subset of those transport services identified in item 1, >>> which >>> end systems supporting TAPS need to provide and provide guidance >>> on choosing among available mechanisms and protocols. > > Agreed. > > >>> OLD: >>> - Specify experimental mechanisms to deliver a transport service. >>> This will explain how to select and engage a protocol, and how >>> to discover the availability of protocols on an interface (both >>> end system and path support), in order to provide a basis for >>> incremental deployment. >>> >>> NEW: >>> - Specify experimental mechanisms to deliver a transport protocol. >>> This will explain how to select and engage a protocol, and how >>> to discover the availability of protocol services on an interface >>> (both >>> >>> end system and path support), in order to provide a basis for >>> incremental deployment. > > > Disagree. "deliver a transport protocol" is weird. The intention was > to say "provide a transport service", maybe "deliver" is a bad choice > of words here? So I suggest: > > NEW: > - Specify experimental mechanisms to provide a transport service. > This will explain how to select and engage a protocol, and how > to discover the availability of protocols on an interface (both > end system and path support), in order to provide a basis for > incremental deployment. > > >>> 2. >>> >>> - Specify experimental mechanisms to deliver a transport service. >>> This will explain how to select and engage a protocol, and how >>> to discover the availability of protocols on an interface (both >>> end system and path support), in order to provide a basis for >>> incremental deployment. >>> >>> I don't understand what "deliver" mean in the first sentence. > > - hence I replaced it with "provide" above. > > >>> 3. >>> It seems that there are multiple problem statements, with two different >>> solution tracks: one for existing transport protocols, another one for >>> new transport protocols. >>> Both rely on the identifying the transport services/criteria, which is >>> good. >>> - existing transport protocols: as you wrote "different protocols can >>> provide the same services in different ways" >>> - existing transport protocols: how do we know if endpoints and the path >>> support those? >>> - new transport protocol development (I got this from my discussion with >>> Brian, true it's not really mentioned in the charter) >>> >>> In your paragraph to which problem statement "this problem" refers to? >>> >>> There are many ways in which this problem could be addressed; >>> while it may not yet be clear what the best way forward could >>> be, any approach to provide a richer set of transport services >>> to applications will have to begin with the identification of >>> the services that current transport protocols provide. >>> >>> Depending on what "this problem" refers to, the solution might be >>> new transport middle layer >>> API services discovery >>> OAM services discovery >>> etc. >>> >>> Discussing with Spencer, it means: "which transport building blocks work >>> for me". > > This block above has me a bit confused, I think I lack context, so I > won't comment on it. > > >>> So this paragraph should be rephrased. >>> Possible solution >>> >>> OLD: >>> >>> There are many ways in which this problem could be addressed; >>> while it may not yet be clear what the best way forward could >>> be, any approach to provide a richer set of transport services >>> to applications will have to begin with the identification of >>> the services that current transport protocols provide. >>> >>> NEW (this paragraph would make more sense after the 3 bullet points "the >>> Working Group will") >>> >>> The Working Group deliverables will help an application >>> programmer identify the important transport services for his >>> application and determine if those transport services are available >>> on the end points and along the path in the network. An approach to >>> provide a richer set of transport services to applications (which >>> could be part of a future charter) has to begin with the >>> identification of >>> the services that current transport protocols provide. > > Agreed; I like this change a lot, it's much more concrete and reflects > our intention IMO. > > >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> "The Working Group will coordinate closely with other Working >>> Groups and >>> IRTF Research Groups." >>> You should list the WGs you have in mind. > > I agree that it looks odd as it stands. I'm not sure what the right > approach is here (simply remove? or what are these groups?) - e.g. > Spencer would know better than me... > > Cheers, > Michael > --------------050405030603040708060709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 06/27/2014 04:33 AM, Michael Welzl wrote:
Hi,

I'm afraid this'll have to be long; in line:

Hi, Michael,

This was long, but helpful.

I agree with the point about the working group needing to work through the list, and that not being a requirement for actual charter approval. Would other folk be OK with naming a couple of examples, rather than a starting list, as Benoit and I had been discussing?

On one point (that Michael said he was confused about below, so maybe worth explaining better), Benoit and I spent about 20 minutes talking before he balloted his block, and one thing we talked about was the difference between an application knowing what's available on a platform and knowing what's available on the path between two endpoints (so, if I can send UDP to any port to Benoit, but a firewall between me and Michael drops all UDP except for port 53, both of those facts are relevant).

This is what we meant when Benoit said "which transport building blocks work for me" below.

And thanks for staying engaged. I appreciate it.

Spencer

On 27. juni 2014, at 01:42, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:

As you'll notice in Benoit's comments below, he's finding "service" and "transport service" to be fairly vague. He ends up proposing that the charter would not use "service" without an adjective, and that the charter use "transport service" to describe "transport protocol + criterion", so in a fairly constrained way.

Well, frankly, I don't think that's moving the charter in a good direction. Talking about services rather than protocols makes it clearer that we don't want to bind applications to protocols anymore, but rather to what protocols provide to applications that use them (see, even that sentence gets a bit strange if I avoid the word service - and if we don't use that word here, what else is it that a protocol offers / provides to applications?).


I'd like to use terms in the charter that won't confuse the heck out of the average reader, so I'm curious what the folks on the TAPS mailing list think (after looking at his proposed text changes below, of course, because we would never express an opinion without considering context).

I know that the word "service" is very often vaguely used and dislike the word myself for that - but in fact, here, I think it really is the best choice. It's about what an application gets from a protocol - e.g. "characteristics" describes a protocol, i.e. is about internals that may not be relevant to an application. Indeed, the email below shows some of that misunderstanding, based on Brian's list. I'll explain below.

As for avoiding confusion, having a shortened version of Brian's list as examples should do it - you see the list, you know what this is about.


I should also mention that a couple of ADs have asked me if TAPS can be described as a session layer. One of my definitions of "session layer" is "surviving transport-layer disconnections and reconnections", and I haven't seen people talking about that on e-mail, so I'm thinking calling it a session layer wouldn't help (replacing a confusing term with another confusing term).

+1 to your opinion!


I kept Benoit on as CC:, so he can say "yes, that helps", or "no, that's worse", but dropped the rest of the IESG from this part of the conversation, in case this turns out to be a bikeshed.

Spencer

On 06/25/2014 08:15 AM, Benoit Claise wrote:
Benoit Claise has entered the following ballot position for
charter-ietf-taps-00-00: Block

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:
http://datatracker.ietf.org/doc/charter-ietf-taps/



----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

I support the work, but I have a BLOCK anyway. The charter needs to
clarify a few points.

1. (somehow similar to Alissa's COMMENT)
The charter should mention that the WG will first analyze the set of
relevant criteria.
I guess that this is what's meant by "services" in this entry but
"services" is an overloaded term.

  Identify services provided by existing IETF transport protocols
  and congestion control mechanisms. The resulting document will
  provide guidance on making a choice among available mechanisms
  and protocols to obtain a certain transport service.

Brian Trammell, during his IESG/IAB retreat presentation called that
"dimensions of transport":

There you go, he called it "dimensions", not "services", so the list is broader in scope. I agree with including parts of his list in the charter, as examples of services, but not the whole list because IMO some items don't belong there. I'll go through them item by item below, applying the following criterion: would an application programmer ever want to say "yes" or "no" to this, without trying to optimize for specific environment conditions? First, we don't want to replace complexity with more complexity, so not exposing absolutely every detail is part of the point here. Second, programmers who prefer to write code themselves that optimizes for specific environments are probably not the typical "customers" of TAPS - probably such folks will want to continue choosing and configuring their protocol directly. I'm not saying TAPS is meant to be sub-optimal :-)  I'm saying it's meant to be able to automatize optimizing for the path, and so we should probably only expose things that are related to application requirements, irrespective of the path.

Obviously, we're getting into a sort of discussion that we should have in the WG-to-be, not now. But my point is: if the group should at some point decide that what I say above is the way to go, then replacing "service" with "protocol" etc. gets in the way, and so does the full list of Brian.

As I go through the list, I also raise questions about the items I criticize, but I don't want to discuss them yet: this is just to highlight that these items can create a confusion and should be removed from the list that goes in the charter.


    - message atomicity

What's that? That multiple messages are not combined into one packet? This plays a role for an application only when there is significant loss (I think). Wouldn't it be nice to have a system that provides atomicity only when needed and otherwise saves header overhead? I would vote against exposing that. Either way, I vote it off the list that goes in the charter, it's not an obvious service to me.


    - stream fragmentation

Is this the opposite of atomicity? (then, why is it "stream", not "message" fragmentation?). If it is, I wouldn't want to include it in the list for the reasons I gave about atomicity above.


    - sequence preservation

Definitely a service! This absolutely depends on your application and nothing else.


    - head-of-line blocking avoidance

Not a service at all, and potentially harmful to expose. This is a performance optimization, a benefit that you can get if a protocol, set of protocols, "session layer", whatever you want to call it, does its job right. Why do I say "potentially harmful"? If an application would select "I don't need sequence preservation" and "you must give me HOL blocking avoidance", then this combination can be provided with SCTP, but we have no way to use normal TCP as a fall-back because it comes with HOL blocking. So the whole system is limited by this set of choices. How harmful is such a fall-back however? It's just some extra delay in a best effort Internet. Just the kind of flexibility that we may want to have.


    - sub-channels

Not a service. You can get the benefits of sub-channels without exposing them. See:
for a proof of concept. Indeed, on what basis does an application say "a sub-channel please"? This is like saying "over UDP please". You shouldn't have to care.


    - full reliability
    - latency-limited reliability

Yes, reliability is a service, and fine to include in the list. But I'd rather replace this with any of:
"various degrees of reliability" or "various forms of reliability" or "full / latency-limited / no reliability"
...or something like that.  One item, not two, anyway.


    - loss-sensitive congestion control
    - delay-sensitive congestion control

"loss-sensitive congestion control" isn't a good name for a service because it indicates that there would be less loss, but in fact delay-sensitive congestion controllers tend to lose less  :-)    The choice of a loss-sensitive vs. delay-sensitive congestion controller (to use things that are in RFCs: LEDBAT vs. TCP's AIMD CC.) is a choice of a trade-off between throughput (potentially less, with LEDBAT) vs. delay (also potentially less, with LEDBAT).

So, first of all, I'd remove "loss-sensitive congestion control" from the list.

Second, using the phrase "congestion control" binds the application requirement to a specific mechanism. I'd rather use something like "low delay vs. high throughput".


    - endpoint address agility

I'm not sure. Unsure enough to recommend removing it from the list.


    - privacy and integrity

See the discussion on security: I'd rather have it removed (given that this is just a list of examples, we can be rather restrictive about what goes in it).


    - path-state propagation (NAT/FW)

As with security, not sure how much of this / in which form we'd want to expose, and so I'd feel better if it were removed.


I don't know if this list is correct or complete. This should be the WG
job to compile it.
Btw, adding this list to the charter, as a starting point, would make
sense.

So, to summarize, here's the complete list that I suggest:

- sequence preservation
- various degrees of reliability
- low delay vs. high throughput

Yes it's short, but for a list of examples, that could be ok?


I'm an application designer, I care for a transport that will provide
me:
    - message atomicity
    - head-of-line blocking avoidance
    - sub-channels
    - full reliability
    - loss-sensitive congestion control

Wouldn't you rather say:
- high throughput (don't care so much about low delay)
- full reliability
- sequence preservation doesn't matter to me
... and have a system underneath automatically gives you head-of-line blocking avoidance and uses loss-sensitive congestion control?
(Ideally, that system would also use sub-channels if they do improve performance, and provides message atomicity only if this is a benefit, i.e. only if there is significant loss)


How do we call those 5 things? criteria?

A mess?


How do we call the transport that support those 5 things? a transport
protocol? a transport service?
The "services" term is used multiple times within the charter.
Sometimes I understand it as a "transport protocol" (like in the first
sentence in the charter),
And sometimes I may interpret it as Brian's "dimensions of transport" or
criteria.

Potentially use "criteria" and "transport protocol"
Alternatively, only use "transport services" when it means "criteria, and
"transport protocol".
I tried to do the latter below.



Again, detailed comments in line:


OLD:

Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
UDP-Lite and the LEDBAT congestion control mechanism extend
the set of transport services that are available to
applications, beyond those provided by TCP and UDP. For
example, SCTP provides potentially faster reliable delivery
for applications that can accept blocks of data out of order,
and LEDBAT provides low-priority "scavenger" communication.

NEW:
Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
UDP-Lite and the LEDBAT congestion control mechanism extend
the set of transport protocols that are available to
applications, beyond those provided by TCP and UDP. For
example, SCTP provides potentially faster reliable delivery
for applications that can accept blocks of data out of order,
and LEDBAT provides low-priority "scavenger" communication.

Disagree, I'd rather leave it as it is to stress that applications use services, not protocols.


OLD:

- Identify services provided by existing IETF transport protocols
  and congestion control mechanisms. The resulting document will
  provide guidance on making a choice among available mechanisms
  and protocols to obtain a certain transport service.


NEW:

- Identify transport services provided by existing IETF transport
protocols
  and congestion control mechanisms. The resulting document will
  provide guidance on making a choice among available mechanisms
  and protocols to obtain a certain transport service. As a starting
point
  for transport services, the working group can consider: message
atomicity,
  stream fragmentation, sequence preservation, head-of-line blocking
avoidance,
  sub-channels, full reliability, latency-limited reliability,
loss-sensitive
  congestion control, delay-sensitive congestion control, endpoint
address agility,
  privacy and integrity, and path-state propagation (NAT/Firewall).

Sentence 1: "transport services provided by ..  transport protocols" doesn't seem to make things clearer. I'd rather keep "services" in this sentence - what this means gets concrete anyway due to the list that follows in sentence 3, and there the phrase "transport services" is used anyway. The list should be changed, as I argued above. I suggest:

NEW:

- Identify services provided by existing IETF transport protocols
  and congestion control mechanisms. The resulting document will
  provide guidance on making a choice among available mechanisms
  and protocols to obtain a certain transport service. As a starting point
  for transport services, the working group can consider: sequence
  preservation, various degrees of reliability, low delay vs. high throughput.



OLD:

- Specify a subset of those services identified in item 1, which
  end systems supporting TAPS need to provide and provide guidance
  on choosing among available mechanisms and protocols to obtain
  a given transport service.

NEW:
- Specify a subset of those transport services identified in item 1,
which
  end systems supporting TAPS need to provide and provide guidance
  on choosing among available mechanisms and protocols.

Agreed.


OLD:
- Specify experimental mechanisms to deliver a transport service.
  This will explain how to select and engage a protocol, and how
  to discover the availability of protocols on an interface (both
  end system and path support), in order to provide a basis for
  incremental deployment.

NEW:
- Specify experimental mechanisms to deliver a transport protocol.
  This will explain how to select and engage a protocol, and how
  to discover the availability of protocol services on an interface (both

  end system and path support), in order to provide a basis for
  incremental deployment.


Disagree. "deliver a transport protocol" is weird. The intention was to say "provide a transport service", maybe "deliver" is a bad choice of words here? So I suggest:

NEW:
- Specify experimental mechanisms to provide a transport service.
  This will explain how to select and engage a protocol, and how
  to discover the availability of protocols on an interface (both
  end system and path support), in order to provide a basis for
  incremental deployment.


2.

- Specify experimental mechanisms to deliver a transport service.
  This will explain how to select and engage a protocol, and how
  to discover the availability of protocols on an interface (both
  end system and path support), in order to provide a basis for
  incremental deployment.

I don't understand what "deliver" mean in the first sentence.

- hence I replaced it with "provide" above.


3.
It seems that there are multiple problem statements, with two different
solution tracks: one for existing transport protocols, another one for
new transport protocols.
Both rely on the identifying the transport services/criteria, which is
good.
- existing transport protocols: as you wrote "different protocols can
provide the same services in different ways"
- existing transport protocols: how do we know if endpoints and the path
support those?
- new transport protocol development (I got this from my discussion with
Brian, true it's not really mentioned in the charter)

In your paragraph to which problem statement "this problem" refers to?

    There are many ways in which this problem could be addressed;
    while it may not yet be clear what the best way forward could
    be, any approach to provide a richer set of transport services
    to applications will have to begin with the identification of
    the services that current transport protocols provide.

Depending on what "this problem" refers to, the solution might be
     new transport middle layer
     API services discovery
    OAM services discovery
    etc.

Discussing with Spencer, it means: "which transport building blocks work
for me".

This block above has me a bit confused, I think I lack context, so I won't comment on it.


So this paragraph should be rephrased.
Possible solution

OLD:

    There are many ways in which this problem could be addressed;
    while it may not yet be clear what the best way forward could
    be, any approach to provide a richer set of transport services
    to applications will have to begin with the identification of
    the services that current transport protocols provide.

NEW (this paragraph would make more sense after the 3 bullet points "the
Working Group will")

    The Working Group deliverables will help an application
    programmer identify the important transport services for his
    application and determine if those transport services are available
    on the end points and along the path in the network. An approach to
    provide a richer set of transport services to applications (which
    could be part of a future charter) has to begin with the
identification of
    the services that current transport protocols provide.

Agreed; I like this change a lot, it's much more concrete and reflects our intention IMO.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

 "The Working Group will coordinate closely with other Working Groups and
IRTF Research Groups."
You should list the WGs you have in mind.

I agree that it looks odd as it stands. I'm not sure what the right approach is here (simply remove? or what are these groups?) - e.g. Spencer would know better than me...

Cheers,
Michael


--------------050405030603040708060709-- From nobody Fri Jun 27 07:04:38 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A2E1B31BC for ; Fri, 27 Jun 2014 07:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 CKsrWOk-3W8R for ; Fri, 27 Jun 2014 07:04:29 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [129.240.10.15]) (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 D66D11B31BD for ; Fri, 27 Jun 2014 07:04:28 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1X0WlP-0005iU-2A; Fri, 27 Jun 2014 16:04:27 +0200 Received: from 089144238254.atnat0047.highway.bob.at ([89.144.238.254] helo=[192.168.0.100]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1X0WlN-0007r2-QR; Fri, 27 Jun 2014 16:04:27 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <53AD74D8.9010906@gmail.com> Date: Fri, 27 Jun 2014 16:04:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <88E2F950-7454-40A1-AF92-240F5B5DA6C0@ifi.uio.no> References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACAFDA.3060303@gmail.com> <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> <53AD74D8.9010906@gmail.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 3 sum msgs/h 1 total rcpts 17938 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: F7D9F16DE1354B2EC32C89A772A9A4CF646E92E2 X-UiO-SPAM-Test: remote_host: 89.144.238.254 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 64 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/OuzOd6Ym9KW4W59FwRbG8YaN5aA Cc: Benoit Claise , taps@ietf.org Subject: Re: [Taps] Charter bikeshed #1 - "transport service" X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 14:04:36 -0000 On 27. juni 2014, at 15:42, Spencer Dawkins = wrote: >=20 > On 06/27/2014 04:33 AM, Michael Welzl wrote: >> Hi, >>=20 >> I'm afraid this'll have to be long; in line: >=20 > Hi, Michael, >=20 > This was long, but helpful. Thanks - and apologies: I know that such a long email is a pain for = everyone, especially at this stage, but I saw no other way... > I agree with the point about the working group needing to work through = the list, and that not being a requirement for actual charter approval. = Would other folk be OK with naming a couple of examples, rather than a = starting list, as Benoit and I had been discussing? Sure; but my point is that having a too "open" list potentially sets up = the group in the wrong direction. > On one point (that Michael said he was confused about below, so maybe = worth explaining better), Benoit and I spent about 20 minutes talking = before he balloted his block, and one thing we talked about was the = difference between an application knowing what's available on a platform = and knowing what's available on the path between two endpoints (so, if I = can send UDP to any port to Benoit, but a firewall between me and = Michael drops all UDP except for port 53, both of those facts are = relevant). >=20 > This is what we meant when Benoit said "which transport building = blocks work for me" below. Well, indeed, this is a design trade-off here that the group must figure = out. Two example cases here: 1) My own preference: TAPS hides pretty much everything that's = path-related from the application, and we say "if you do care about such = details, don't use TAPS, use the protocol you wish." 2) Maybe someone else's, maybe Benoit's, preference: TAPS does not hide = path-related information from the application. In case 2), the outcome of TAPS is: + more useful + "richer" - more complex - less flexible in case someone wants to build a TAPS system that = automatizes a lot of functions. When writing a list of example transport services related to 1) and 2) = above, the first list is simply shorter than the second. Whether we want = 1) or 2) or where to draw the line between them is certainly a = discussion for later, but my concern is: if we include an example list = with items from 2) above in the charter, it's already decided that we = will do 2). If we include only examples from 1) above, nothing stops us = from going for 2) if the group wants to. Maybe I'm over-complicating it - if my concern is unfounded and charters = are flexible enough anyway and none of this really matters, by all means = include whatever list you wish, noone here will have a huge problem with = a list of examples anyway, I guess :-) Cheers, Michael From nobody Fri Jun 27 07:21:49 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313C41B2FB8 for ; Fri, 27 Jun 2014 07:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 n-6chnMZpjfM for ; Fri, 27 Jun 2014 07:21:36 -0700 (PDT) Received: from ppsw-50.csi.cam.ac.uk (ppsw-50-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f50]) (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 221EA1B3028 for ; Fri, 27 Jun 2014 07:21:32 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ravage.cl.cam.ac.uk ([128.232.1.17]:53494) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1X0X1o-0007MD-sC (Exim 4.82_3-c0e5623) (return-path ); Fri, 27 Jun 2014 15:21:24 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_87FA37AF-8E4A-4B0D-A13F-73EA21F20A3D" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Toby Moncaster In-Reply-To: <53AD74D8.9010906@gmail.com> Date: Fri, 27 Jun 2014 15:21:23 +0100 Message-Id: References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACAFDA.3060303@gmail.com> <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> <53AD74D8.9010906@gmail.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.1878.2) Sender: "T. Moncaster" Archived-At: http://mailarchive.ietf.org/arch/msg/taps/9LAa3npg_9rjdAlHB8XPZIGH3Ik Cc: Benoit Claise , Michael Welzl , taps@ietf.org Subject: Re: [Taps] Charter bikeshed #1 - "transport service" X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 14:21:44 -0000 --Apple-Mail=_87FA37AF-8E4A-4B0D-A13F-73EA21F20A3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I=92m going to try and add some (hopefully) relevant comments inline :) On 27 Jun 2014, at 14:42, Spencer Dawkins = wrote: >=20 > On 06/27/2014 04:33 AM, Michael Welzl wrote: >> Hi, >>=20 >> I'm afraid this'll have to be long; in line: >=20 > Hi, Michael, >=20 > This was long, but helpful. >=20 > I agree with the point about the working group needing to work through = the list, and that not being a requirement for actual charter approval. = Would other folk be OK with naming a couple of examples, rather than a = starting list, as Benoit and I had been discussing? I have a very strong preference for a set of examples. If we have too = long a list I fear it might bias the actual outcome of the work we hope = this WG will do! >=20 > On one point (that Michael said he was confused about below, so maybe = worth explaining better), Benoit and I spent about 20 minutes talking = before he balloted his block, and one thing we talked about was the = difference between an application knowing what's available on a platform = and knowing what's available on the path between two endpoints (so, if I = can send UDP to any port to Benoit, but a firewall between me and = Michael drops all UDP except for port 53, both of those facts are = relevant). OK, That makes sense. This is a difference between =93Which services are = available in my transport stack=94 and =93Which services can I use on a = particular connection=94. One of the points of thinking in terms of = falling back to e.g. TCP is to address this problem.=20 Also to my way of thinking the purpose of describing these as =93services=94= is to abstract away the actual mechanism that delivers the service. In = turn this gives the potential for the TAPS-aware transport to select the = transport protocol that most closely matches the desired set of services >=20 > This is what we meant when Benoit said "which transport building = blocks work for me" below. >=20 > And thanks for staying engaged. I appreciate it. >=20 > Spencer >=20 >> On 27. juni 2014, at 01:42, Spencer Dawkins = wrote: >>=20 >>> As you'll notice in Benoit's comments below, he's finding "service" = and "transport service" to be fairly vague. He ends up proposing that = the charter would not use "service" without an adjective, and that the = charter use "transport service" to describe "transport protocol + = criterion", so in a fairly constrained way. >>=20 >> Well, frankly, I don't think that's moving the charter in a good = direction. Talking about services rather than protocols makes it clearer = that we don't want to bind applications to protocols anymore, but rather = to what protocols provide to applications that use them (see, even that = sentence gets a bit strange if I avoid the word service - and if we = don't use that word here, what else is it that a protocol offers / = provides to applications?). I agree with Michael here. I think we could end up with a much less = clearly worded charter if we go down that route. If there is a need to = be more precise then I=92d favour adding something near the beginning of = the charter along the lines of the definition I put in the Problem = Statement document. Namely: "A Transport Service is any service = provided by the transport layer that can only be correctly implemented = with information from the application.=94We could then include 2 or 3 = example services=20 >>=20 >>=20 >>> I'd like to use terms in the charter that won't confuse the heck out = of the average reader, so I'm curious what the folks on the TAPS mailing = list think (after looking at his proposed text changes below, of course, = because we would never express an opinion without considering context). >>=20 >> I know that the word "service" is very often vaguely used and dislike = the word myself for that - but in fact, here, I think it really is the = best choice. It's about what an application gets from a protocol - e.g. = "characteristics" describes a protocol, i.e. is about internals that may = not be relevant to an application. Indeed, the email below shows some of = that misunderstanding, based on Brian's list. I'll explain below. >>=20 >> As for avoiding confusion, having a shortened version of Brian's list = as examples should do it - you see the list, you know what this is = about. yes >>=20 >>=20 >>> I should also mention that a couple of ADs have asked me if TAPS can = be described as a session layer. One of my definitions of "session = layer" is "surviving transport-layer disconnections and reconnections", = and I haven't seen people talking about that on e-mail, so I'm thinking = calling it a session layer wouldn't help (replacing a confusing term = with another confusing term). >>=20 >> +1 to your opinion! +1 Session layer will just totally throw everyone! >>=20 >>=20 >>> I kept Benoit on as CC:, so he can say "yes, that helps", or "no, = that's worse", but dropped the rest of the IESG from this part of the = conversation, in case this turns out to be a bikeshed. >>>=20 >>> Spencer >>>=20 >>> On 06/25/2014 08:15 AM, Benoit Claise wrote: >>>> Benoit Claise has entered the following ballot position for >>>> charter-ietf-taps-00-00: Block >>>>=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: >>>> http://datatracker.ietf.org/doc/charter-ietf-taps/ >>>>=20 >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> BLOCK: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> I support the work, but I have a BLOCK anyway. The charter needs to >>>> clarify a few points. >>>>=20 >>>> 1. (somehow similar to Alissa's COMMENT) >>>> The charter should mention that the WG will first analyze the set = of >>>> relevant criteria. >>>> I guess that this is what's meant by "services" in this entry but >>>> "services" is an overloaded term. >>>>=20 >>>> Identify services provided by existing IETF transport protocols >>>> and congestion control mechanisms. The resulting document will >>>> provide guidance on making a choice among available mechanisms >>>> and protocols to obtain a certain transport service. >>>>=20 >>>> Brian Trammell, during his IESG/IAB retreat presentation called = that >>>> "dimensions of transport": >>=20 >> There you go, he called it "dimensions", not "services", so the list = is broader in scope. I agree with including parts of his list in the = charter, as examples of services, but not the whole list because IMO = some items don't belong there. I'll go through them item by item below, = applying the following criterion: would an application programmer ever = want to say "yes" or "no" to this, without trying to optimize for = specific environment conditions? First, we don't want to replace = complexity with more complexity, so not exposing absolutely every detail = is part of the point here. Second, programmers who prefer to write code = themselves that optimizes for specific environments are probably not the = typical "customers" of TAPS - probably such folks will want to continue = choosing and configuring their protocol directly. I'm not saying TAPS is = meant to be sub-optimal :-) I'm saying it's meant to be able to = automatize optimizing for the path, and so we should probably only = expose things that are related to application requirements, irrespective = of the path. >>=20 >> Obviously, we're getting into a sort of discussion that we should = have in the WG-to-be, not now. But my point is: if the group should at = some point decide that what I say above is the way to go, then replacing = "service" with "protocol" etc. gets in the way, and so does the full = list of Brian. >>=20 >> As I go through the list, I also raise questions about the items I = criticize, but I don't want to discuss them yet: this is just to = highlight that these items can create a confusion and should be removed = from the list that goes in the charter. >>=20 >>=20 >>>> - message atomicity >>=20 >> What's that? That multiple messages are not combined into one packet? = This plays a role for an application only when there is significant loss = (I think). Wouldn't it be nice to have a system that provides atomicity = only when needed and otherwise saves header overhead? I would vote = against exposing that. Either way, I vote it off the list that goes in = the charter, it's not an obvious service to me. To some extent I agree here. But is there any way we can correctly = express the differences between stream and packet oriented transports? >>=20 >>=20 >>>> - stream fragmentation >>=20 >> Is this the opposite of atomicity? (then, why is it "stream", not = "message" fragmentation?). If it is, I wouldn't want to include it in = the list for the reasons I gave about atomicity above. >>=20 >>=20 >>>> - sequence preservation >>=20 >> Definitely a service! This absolutely depends on your application and = nothing else. agree >>=20 >>=20 >>>> - head-of-line blocking avoidance >>=20 >> Not a service at all, and potentially harmful to expose. This is a = performance optimization, a benefit that you can get if a protocol, set = of protocols, "session layer", whatever you want to call it, does its = job right. Why do I say "potentially harmful"? If an application would = select "I don't need sequence preservation" and "you must give me HOL = blocking avoidance", then this combination can be provided with SCTP, = but we have no way to use normal TCP as a fall-back because it comes = with HOL blocking. So the whole system is limited by this set of = choices. How harmful is such a fall-back however? It's just some extra = delay in a best effort Internet. Just the kind of flexibility that we = may want to have. agree with Michael, although I=92m not sure I completely agree with how = he expresses the objection >>=20 >>=20 >>>> - sub-channels >>=20 >> Not a service. You can get the benefits of sub-channels without = exposing them. See: >> http://heim.ifi.uio.no/michawe/research/publications/globecom2011.pdf >> for a proof of concept. Indeed, on what basis does an application say = "a sub-channel please"? This is like saying "over UDP please". You = shouldn't have to care. >>=20 >>=20 >>>> - full reliability >>>> - latency-limited reliability >>>=20 >>=20 >> Yes, reliability is a service, and fine to include in the list. But = I'd rather replace this with any of: >> "various degrees of reliability" or "various forms of reliability" or = "full / latency-limited / no reliability" >> ...or something like that. One item, not two, anyway. Hmmm. I=92d rather we had something like =93Degree of reliability from = unreliable to full reliability." >>=20 >>=20 >>>> - loss-sensitive congestion control >>>> - delay-sensitive congestion control >>=20 >> "loss-sensitive congestion control" isn't a good name for a service = because it indicates that there would be less loss, but in fact = delay-sensitive congestion controllers tend to lose less :-) The = choice of a loss-sensitive vs. delay-sensitive congestion controller (to = use things that are in RFCs: LEDBAT vs. TCP's AIMD CC.) is a choice of a = trade-off between throughput (potentially less, with LEDBAT) vs. delay = (also potentially less, with LEDBAT). >>=20 >> So, first of all, I'd remove "loss-sensitive congestion control" from = the list. Slightly disagree here. But can=92t quite put it into words >>=20 >> Second, using the phrase "congestion control" binds the application = requirement to a specific mechanism. I'd rather use something like "low = delay vs. high throughput=94. Perhaps this would best be expressed as =93Trading off latency and = throughput" >>=20 >>=20 >>>> - endpoint address agility >>=20 >> I'm not sure. Unsure enough to recommend removing it from the list. No views either way. But the fact there is any uncertainty is in itself = a good reason not to list this as a service in the charter (since that = effectively is making the decision that it IS a service) >>=20 >>=20 >>>> - privacy and integrity >>=20 >> See the discussion on security: I'd rather have it removed (given = that this is just a list of examples, we can be rather restrictive about = what goes in it). Agree. Remove this for the initial list >>=20 >>=20 >>>> - path-state propagation (NAT/FW) >>=20 >> As with security, not sure how much of this / in which form we'd want = to expose, and so I'd feel better if it were removed. Agree. Remove this for the initial list >>=20 >>=20 >>>> I don't know if this list is correct or complete. This should be = the WG >>>> job to compile it. >>>> Btw, adding this list to the charter, as a starting point, would = make >>>> sense. >>=20 >> So, to summarize, here's the complete list that I suggest: >>=20 >> - sequence preservation >> - various degrees of reliability >> - low delay vs. high throughput I=92d rephrase this as: - ordering/sequence preservation - degree of reliability=20 - latency vs throughput >>=20 >> Yes it's short, but for a list of examples, that could be ok? >>=20 >>=20 >>>> I'm an application designer, I care for a transport that will = provide >>>> me: >>>> - message atomicity >>>> - head-of-line blocking avoidance >>>> - sub-channels >>>> - full reliability >>>> - loss-sensitive congestion control >>=20 >> Wouldn't you rather say: >> - high throughput (don't care so much about low delay) >> - full reliability >> - sequence preservation doesn't matter to me >> ... and have a system underneath automatically gives you head-of-line = blocking avoidance and uses loss-sensitive congestion control? >> (Ideally, that system would also use sub-channels if they do improve = performance, and provides message atomicity only if this is a benefit, = i.e. only if there is significant loss) >>=20 >>=20 >>>> How do we call those 5 things? criteria? >>=20 >> A mess? If TAPS is ever to be successful we have to get and keep the application = developers on side. So I would say that application designers might have = a list of desired outcomes for their application and TAPS is about = marrying that up with the underlying services that lead to those = outcomes >>=20 >>=20 >>>> How do we call the transport that support those 5 things? a = transport >>>> protocol? a transport service? >>>> The "services" term is used multiple times within the charter. >>>> Sometimes I understand it as a "transport protocol" (like in the = first >>>> sentence in the charter), >>>> And sometimes I may interpret it as Brian's "dimensions of = transport" or >>>> criteria. >>>>=20 >>>> Potentially use "criteria" and "transport protocol" >>>> Alternatively, only use "transport services" when it means = "criteria, and >>>> "transport protocol". >>>> I tried to do the latter below. >>>>=20 >>>>=20 >>=20 >> Again, detailed comments in line: >>=20 >>=20 >>>> OLD: >>>>=20 >>>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP, >>>> UDP-Lite and the LEDBAT congestion control mechanism extend >>>> the set of transport services that are available to >>>> applications, beyond those provided by TCP and UDP. For >>>> example, SCTP provides potentially faster reliable delivery >>>> for applications that can accept blocks of data out of order, >>>> and LEDBAT provides low-priority "scavenger" communication. >>>>=20 >>>> NEW: >>>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP, >>>> UDP-Lite and the LEDBAT congestion control mechanism extend >>>> the set of transport protocols that are available to >>>> applications, beyond those provided by TCP and UDP. For >>>> example, SCTP provides potentially faster reliable delivery >>>> for applications that can accept blocks of data out of order, >>>> and LEDBAT provides low-priority "scavenger" communication. >>=20 >> Disagree, I'd rather leave it as it is to stress that applications = use services, not protocols. I actually think changing that to protocols might be a good thing, since = it highlights how complex the landscape has become.=20 >>=20 >>=20 >>>> OLD: >>>>=20 >>>> - Identify services provided by existing IETF transport protocols >>>> and congestion control mechanisms. The resulting document will >>>> provide guidance on making a choice among available mechanisms >>>> and protocols to obtain a certain transport service. >>>>=20 >>>>=20 >>>> NEW: >>>>=20 >>>> - Identify transport services provided by existing IETF transport >>>> protocols >>>> and congestion control mechanisms. The resulting document will >>>> provide guidance on making a choice among available mechanisms >>>> and protocols to obtain a certain transport service. As a = starting >>>> point >>>> for transport services, the working group can consider: message >>>> atomicity, >>>> stream fragmentation, sequence preservation, head-of-line = blocking >>>> avoidance, >>>> sub-channels, full reliability, latency-limited reliability, >>>> loss-sensitive >>>> congestion control, delay-sensitive congestion control, endpoint >>>> address agility, >>>> privacy and integrity, and path-state propagation (NAT/Firewall). >>=20 >> Sentence 1: "transport services provided by .. transport protocols" = doesn't seem to make things clearer. I'd rather keep "services" in this = sentence - what this means gets concrete anyway due to the list that = follows in sentence 3, and there the phrase "transport services" is used = anyway. The list should be changed, as I argued above. I suggest: >>=20 >> NEW: >>=20 >> - Identify services provided by existing IETF transport protocols >> and congestion control mechanisms. The resulting document will >> provide guidance on making a choice among available mechanisms >> and protocols to obtain a certain transport service. As a starting = point >> for transport services, the working group can consider: sequence >> preservation, various degrees of reliability, low delay vs. high = throughput. I think here we=92re once again running into the difficulty of the = ambiguity of the word =93transport=94, especially in the IETF=85 If we = have defined Transport Services in terms of the transport protocol = earlier in the document, can we actually phrase this - Identify Transport Services provided by IETF protocols and congestion = control mechanisms >>=20 >>=20 >>=20 >>>> OLD: >>>>=20 >>>> - Specify a subset of those services identified in item 1, which >>>> end systems supporting TAPS need to provide and provide guidance >>>> on choosing among available mechanisms and protocols to obtain >>>> a given transport service. >>>>=20 >>>> NEW: >>>> - Specify a subset of those transport services identified in item = 1, >>>> which >>>> end systems supporting TAPS need to provide and provide guidance >>>> on choosing among available mechanisms and protocols. >>=20 >> Agreed. agree as well >>=20 >>=20 >>>> OLD: >>>> - Specify experimental mechanisms to deliver a transport service. >>>> This will explain how to select and engage a protocol, and how >>>> to discover the availability of protocols on an interface (both >>>> end system and path support), in order to provide a basis for >>>> incremental deployment. >>>>=20 >>>> NEW: >>>> - Specify experimental mechanisms to deliver a transport protocol. >>>> This will explain how to select and engage a protocol, and how >>>> to discover the availability of protocol services on an interface = (both >>>>=20 >>>> end system and path support), in order to provide a basis for >>>> incremental deployment. >>=20 >>=20 >> Disagree. "deliver a transport protocol" is weird. The intention was = to say "provide a transport service", maybe "deliver" is a bad choice of = words here? So I suggest: >>=20 >> NEW: >> - Specify experimental mechanisms to provide a transport service. >> This will explain how to select and engage a protocol, and how >> to discover the availability of protocols on an interface (both >> end system and path support), in order to provide a basis for >> incremental deployment. Specify experimental mechanisms to provide a given Transport Service.=20 This will explain how to select and engage an appropriate protocol and=20= how to discover which protocols are available for a given connection.=20 This will provide a basis for incremental deployment. >>=20 >>=20 >>>> 2. >>>>=20 >>>> - Specify experimental mechanisms to deliver a transport service. >>>> This will explain how to select and engage a protocol, and how >>>> to discover the availability of protocols on an interface (both >>>> end system and path support), in order to provide a basis for >>>> incremental deployment. >>>>=20 >>>> I don't understand what "deliver" mean in the first sentence. >>=20 >> - hence I replaced it with "provide" above. >>=20 >>=20 >>>> 3. >>>> It seems that there are multiple problem statements, with two = different >>>> solution tracks: one for existing transport protocols, another one = for >>>> new transport protocols. >>>> Both rely on the identifying the transport services/criteria, which = is >>>> good. >>>> - existing transport protocols: as you wrote "different protocols = can >>>> provide the same services in different ways" >>>> - existing transport protocols: how do we know if endpoints and the = path >>>> support those? >>>> - new transport protocol development (I got this from my discussion = with >>>> Brian, true it's not really mentioned in the charter) >>>>=20 >>>> In your paragraph to which problem statement "this problem" refers = to? >>>>=20 >>>> There are many ways in which this problem could be addressed; >>>> while it may not yet be clear what the best way forward could >>>> be, any approach to provide a richer set of transport services >>>> to applications will have to begin with the identification of >>>> the services that current transport protocols provide. >>>>=20 >>>> Depending on what "this problem" refers to, the solution might be >>>> new transport middle layer >>>> API services discovery >>>> OAM services discovery >>>> etc. >>>>=20 >>>> Discussing with Spencer, it means: "which transport building blocks = work >>>> for me". >>=20 >> This block above has me a bit confused, I think I lack context, so I = won't comment on it. addressed above >>=20 >>=20 >>>> So this paragraph should be rephrased. >>>> Possible solution >>>>=20 >>>> OLD: >>>>=20 >>>> There are many ways in which this problem could be addressed; >>>> while it may not yet be clear what the best way forward could >>>> be, any approach to provide a richer set of transport services >>>> to applications will have to begin with the identification of >>>> the services that current transport protocols provide. >>>>=20 >>>> NEW (this paragraph would make more sense after the 3 bullet points = "the >>>> Working Group will") >>>>=20 >>>> The Working Group deliverables will help an application >>>> programmer identify the important transport services for his >>>> application and determine if those transport services are = available >>>> on the end points and along the path in the network. An = approach to >>>> provide a richer set of transport services to applications = (which >>>> could be part of a future charter) has to begin with the >>>> identification of >>>> the services that current transport protocols provide. >>=20 >> Agreed; I like this change a lot, it's much more concrete and = reflects our intention IMO. Yes. Agreed >>=20 >>=20 >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> "The Working Group will coordinate closely with other Working = Groups and >>>> IRTF Research Groups." >>>> You should list the WGs you have in mind. >>=20 >> I agree that it looks odd as it stands. I'm not sure what the right = approach is here (simply remove? or what are these groups?) - e.g. = Spencer would know better than me=85 I think the key thing here was that we aren=92t only limiting ourselves = to working with the IETF but are also interested in getting input from = the IRTF. However I think we can drop this >>=20 >> Cheers, >> Michael >>=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_87FA37AF-8E4A-4B0D-A13F-73EA21F20A3D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I=92m = going to try and add some (hopefully) relevant comments inline = :)


On 27 Jun 2014, at 14:42, Spencer = Dawkins <spencerdawkins.ietf@gmail.co= m> wrote:

=20 =20

On 06/27/2014 04:33 AM, Michael Welzl wrote:
Hi,

I'm afraid this'll have to be long; in line:

Hi, Michael,

This was long, but helpful.

I agree with the point about the working group needing to work through the list, and that not being a requirement for actual charter approval. Would other folk be OK with naming a couple of examples, rather than a starting list, as Benoit and I had been discussing?

I have a very = strong preference for a set of examples. If we have too long a list I = fear it might bias the actual outcome of the work we hope this WG will = do!


On one point (that Michael said he was confused about below, so maybe worth explaining better), Benoit and I spent about 20 minutes talking before he balloted his block, and one thing we talked about was the difference between an application knowing what's available on a platform and knowing what's available on the path between two endpoints (so, if I can send UDP to any port to Benoit, but a firewall between me and Michael drops all UDP except for port 53, both of those facts are = relevant).

OK, That makes = sense. This is a difference between =93Which services are available in = my transport stack=94 and =93Which services can I use on a particular = connection=94. One of the points of thinking in terms of falling back to = e.g. TCP is to address this problem. 

Also = to my way of thinking the purpose of describing these as =93services=94 = is to abstract away the actual mechanism that delivers the service. In = turn this gives the potential for the TAPS-aware transport to select the = transport protocol that most closely matches the desired set of = services


This is what we meant when Benoit said "which transport building blocks work for me" below.

And thanks for staying engaged. I appreciate it.

Spencer

On 27. juni 2014, at 01:42, Spencer Dawkins <spencerdawkins.ietf@gmail.co= m> wrote:

As you'll notice in Benoit's = comments below, he's finding "service" and "transport service" to be fairly vague. He ends up proposing that the charter would not use "service" without an adjective, and that the charter use "transport service" to describe "transport protocol + criterion", so in a fairly constrained way.

Well, frankly, I don't think that's moving the charter in a good direction. Talking about services rather than protocols makes it clearer that we don't want to bind applications to protocols anymore, but rather to what protocols provide to applications that use them (see, even that sentence gets a bit strange if I avoid the word service - and if we don't use that word here, what else is it that a protocol offers / provides to = applications?).

=

I agree with Michael here. I think we could = end up with a much less clearly worded charter if we go down that route. = If there is a need to be more precise then I=92d favour adding something = near the beginning of the charter along the lines of the definition I = put in the Problem Statement document. Namely:  "A Transport Service is any service = provided by the transport layer that can only be correctly implemented = with information from the application.=94We could then include 2 or 3 = example services



I'd like to use terms in the charter that won't confuse the heck out of the average reader, so I'm curious what the folks on the TAPS mailing list think (after looking at his proposed text changes below, of course, because we would never express an opinion without considering context).

I know that the word "service" is very often vaguely used and dislike the word myself for that - but in fact, here, I think it really is the best choice. It's about what an application gets from a protocol - e.g. "characteristics" describes a protocol, i.e. is about internals that may not be relevant to an application. Indeed, the email below shows some of that misunderstanding, based on Brian's list. I'll explain below.

As for avoiding confusion, having a shortened version of Brian's list as examples should do it - you see the list, you know what this is = about.

yes



I should also mention that a couple = of ADs have asked me if TAPS can be described as a session layer. One of my definitions of "session layer" is "surviving transport-layer disconnections and reconnections", and I haven't seen people talking about that on e-mail, so I'm thinking calling it a session layer wouldn't help (replacing a confusing term with another confusing term).

+1 to your = opinion!

+1= Session layer will just totally throw = everyone!




I kept Benoit on as CC:, so he can = say "yes, that helps", or "no, that's worse", but dropped the rest of the IESG from this part of the conversation, in case this turns out to be a bikeshed.

Spencer

On 06/25/2014 08:15 AM, Benoit Claise wrote:
Benoit Claise has entered the following ballot position for
charter-ietf-taps-00-00: Block

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:
http://datatra= cker.ietf.org/doc/charter-ietf-taps/



= ----------------------------------------------------------------------
= BLOCK:
= ----------------------------------------------------------------------
=
I support the work, but I have a BLOCK anyway. The charter needs to
clarify a few points.

1. (somehow similar to Alissa's COMMENT)
The charter should mention that the WG will first analyze the set of
relevant criteria.
I guess that this is what's meant by "services" in this entry but
"services" is an overloaded term.

  Identify services provided by existing IETF = transport protocols
  and congestion control mechanisms. The = resulting document will
  provide guidance on making a choice among = available mechanisms
  and protocols to obtain a certain transport = service.

Brian Trammell, during his IESG/IAB retreat presentation called that
"dimensions of transport":

There you go, he called it "dimensions", not "services", so the list is broader in scope. I agree with including parts of his list in the charter, as examples of services, but not the whole list because IMO some items don't belong there. I'll go through them item by item below, applying the following criterion: would an application programmer ever want to say "yes" or "no" to this, without trying to optimize for specific environment conditions? First, we don't want to replace complexity with more complexity, so not exposing absolutely every detail is part of the point here. Second, programmers who prefer to write code themselves that optimizes for specific environments are probably not the typical "customers" of TAPS - probably such folks will want to continue choosing and configuring their protocol directly. I'm not saying TAPS is meant to be sub-optimal :-)  I'm saying it's meant to = be able to automatize optimizing for the path, and so we should probably only expose things that are related to application requirements, irrespective of the path.

Obviously, we're getting into a sort of discussion that we should have in the WG-to-be, not now. But my point is: if the group should at some point decide that what I say above is the way to go, then replacing "service" with "protocol" etc. gets in the way, and so does the full list of Brian.

As I go through the list, I also raise questions about the items I criticize, but I don't want to discuss them yet: this is just to highlight that these items can create a confusion and should be removed from the list that goes in the = charter.


    - message = atomicity

What's that? That multiple messages are not combined into one packet? This plays a role for an application only when there is significant loss (I think). Wouldn't it be nice to have a system that provides atomicity only when needed and otherwise saves header overhead? I would vote against exposing that. Either way, I vote it off the list that goes in the charter, it's not an obvious service to = me.

T= o some extent I agree here. But is there any way we can correctly = express the differences between stream and packet oriented = transports?



    - stream = fragmentation

Is this the opposite of atomicity? (then, why is it "stream", not "message" fragmentation?). If it is, I wouldn't want to include it in the list for the reasons I gave about atomicity above.


    - = sequence preservation

Definitely a service! This absolutely depends on your application and nothing = else.

agree=



    - = head-of-line blocking avoidance

Not a service at all, and potentially harmful to expose. This is a performance optimization, a benefit that you can get if a protocol, set of protocols, "session layer", whatever you want to call it, does its job right. Why do I say "potentially harmful"? If an application would select "I don't need sequence preservation" and "you must give me HOL blocking avoidance", then this combination can be provided with SCTP, but we have no way to use normal TCP as a fall-back because it comes with HOL blocking. So the whole system is limited by this set of choices. How harmful is such a fall-back however? It's just some extra delay in a best effort Internet. Just the kind of flexibility that we may want to = have.

agree with Michael, although I=92m not sure I completely agree with how = he expresses the objection



    - = sub-channels

Not a service. You can get the benefits of sub-channels without exposing them. See:
for a proof of concept. Indeed, on what basis does an application say "a sub-channel please"? This is like saying "over UDP please". You shouldn't have to care.


    - full = reliability
    - = latency-limited reliability

Yes, reliability is a service, and fine to include in the list. But I'd rather replace this with any of:
"various degrees of reliability" or "various forms of reliability" or "full / latency-limited / no = reliability"
...or something like that.  One item, not two, = anyway.


Hmmm. I=92d rather we had something like =93Degree of = reliability from unreliable to full reliability."



    - = loss-sensitive congestion control
    - delay-sensitive congestion = control

"loss-sensitive congestion control" isn't a good name for a service because it indicates that there would be less loss, but in fact delay-sensitive congestion controllers tend to lose less  :-)    The choice of a = loss-sensitive vs. delay-sensitive congestion controller (to use things that are in RFCs: LEDBAT vs. TCP's AIMD CC.) is a choice of a trade-off between throughput (potentially less, with LEDBAT) vs. delay (also potentially less, with LEDBAT).

So, first of all, I'd remove "loss-sensitive congestion control" from the = list.

Slightly disagree here. But can=92t quite put it into = words


Second, using the phrase "congestion control" binds the application requirement to a specific mechanism. I'd rather use something like "low delay vs. high = throughput=94.

<= /div>
Perhaps this would best be expressed as =93Trading off latency = and throughput"




    - = endpoint address agility

I'm not sure. Unsure enough to recommend removing it from the = list.

No views either way. But the fact there is any uncertainty is in itself = a good reason not to list this as a service in the charter (since that = effectively is making the decision that it IS a = service)



    - privacy = and integrity

See the discussion on security: I'd rather have it removed (given that this is just a list of examples, we can be rather restrictive about what goes in = it).

= Agree. Remove this for the initial list



    - = path-state propagation (NAT/FW)

As with security, not sure how much of this / in which form we'd want to expose, and so I'd feel better if it were = removed.

<= div>Agree. Remove this for the initial list


I don't know if this list is = correct or complete. This should be the WG
job to compile it.
Btw, adding this list to the charter, as a starting point, would make
sense.

So, to summarize, here's the complete list that I suggest:

- sequence preservation
- various degrees of reliability
- low delay vs. high = throughput

I=92d rephrase this as:

- = ordering/sequence preservation
- degree of = reliability 
- latency vs throughput


Yes it's short, but for a list of examples, that could be ok?


I'm an application designer, I = care for a transport that will provide
me:
    - message atomicity
    - head-of-line blocking = avoidance
    - sub-channels
    - full reliability
    - loss-sensitive congestion = control

Wouldn't you rather say:
- high throughput (don't care so much about low = delay)
- full reliability
- sequence preservation doesn't matter to me
... and have a system underneath automatically gives you head-of-line blocking avoidance and uses loss-sensitive congestion control?
(Ideally, that system would also use sub-channels if they do improve performance, and provides message atomicity only if this is a benefit, i.e. only if there is significant loss)


How do we call those 5 things? criteria?

A = mess?

If TAPS is ever to be successful we have to get and keep the = application developers on side. So I would say that application = designers might have a list of desired outcomes for their application = and TAPS is about marrying that up with the underlying services that = lead to those outcomes



How do we call the transport that support those 5 things? a transport
protocol? a transport service?
The "services" term is used multiple times within the charter.
Sometimes I understand it as a "transport protocol" (like in the first
sentence in the charter),
And sometimes I may interpret it as Brian's "dimensions of transport" or
criteria.

Potentially use "criteria" and "transport protocol"
Alternatively, only use "transport services" when it means "criteria, and
"transport protocol".
I tried to do the latter below.



Again, detailed comments in line:


OLD:

Conjointly, transport protocols such as SCTP, DCCP, = MPTCP,
UDP-Lite and the LEDBAT congestion control mechanism extend
the set of transport services that are available to
applications, beyond those provided by TCP and UDP. = For
example, SCTP provides potentially faster reliable delivery
for applications that can accept blocks of data out of order,
and LEDBAT provides low-priority "scavenger" communication.

NEW:
Conjointly, transport protocols such as SCTP, DCCP, = MPTCP,
UDP-Lite and the LEDBAT congestion control mechanism extend
the set of transport protocols that are available to
applications, beyond those provided by TCP and UDP. = For
example, SCTP provides potentially faster reliable delivery
for applications that can accept blocks of data out of order,
and LEDBAT provides low-priority "scavenger" communication.

Disagree, I'd rather leave it as it is to stress that applications use services, not = protocols.

=
I actually think changing that to protocols might be a = good thing, since it highlights how complex the landscape has = become. 



OLD:

- Identify services provided by existing IETF transport protocols
  and congestion control mechanisms. The = resulting document will
  provide guidance on making a choice among = available mechanisms
  and protocols to obtain a certain transport = service.


NEW:

- Identify transport services provided by existing IETF transport
protocols
  and congestion control mechanisms. The = resulting document will
  provide guidance on making a choice among = available mechanisms
  and protocols to obtain a certain transport = service. As a starting
point
  for transport services, the working group can = consider: message
atomicity,
  stream fragmentation, sequence preservation, head-of-line blocking
avoidance,
  sub-channels, full reliability, = latency-limited reliability,
loss-sensitive
  congestion control, delay-sensitive congestion = control, endpoint
address agility,
  privacy and integrity, and path-state = propagation (NAT/Firewall).

Sentence 1: "transport services provided by .. =  transport protocols" doesn't seem to make things clearer. I'd rather keep "services" in this sentence - what this means gets concrete anyway due to the list that follows in sentence 3, and there the phrase "transport services" is used anyway. The list should be changed, as I argued above. I = suggest:

NEW:

- Identify services provided by existing IETF transport protocols
  and congestion control mechanisms. The resulting = document will
  provide guidance on making a choice among available mechanisms
  and protocols to obtain a certain transport service. = As a starting point
  for transport services, the working group can = consider: sequence
  preservation, various degrees of reliability, low = delay vs. high = throughput.

I think here we=92re once again running into the difficulty of = the ambiguity of the word =93transport=94, especially in the IETF=85 If = we have defined Transport Services in terms of the transport protocol = earlier in the document, can we actually phrase = this

- Identify Transport Services provided by = IETF protocols and congestion control = mechanisms





OLD:

- Specify a subset of those services identified in item 1, which
  end systems supporting TAPS need to provide = and provide guidance
  on choosing among available mechanisms and = protocols to obtain
  a given transport service.

NEW:
- Specify a subset of those transport services identified in item 1,
which
  end systems supporting TAPS need to provide = and provide guidance
  on choosing among available mechanisms and = protocols.

=
Agreed.

agree as well



OLD:
- Specify experimental mechanisms to deliver a transport service.
  This will explain how to select and engage a = protocol, and how
  to discover the availability of protocols on = an interface (both
  end system and path support), in order to = provide a basis for
  incremental deployment.

NEW:
- Specify experimental mechanisms to deliver a transport protocol.
  This will explain how to select and engage a = protocol, and how
  to discover the availability of protocol = services on an interface (both

  end system and path support), in order to = provide a basis for
  incremental deployment.


Disagree. "deliver a transport protocol" is weird. The intention was to say "provide a transport service", maybe "deliver" is a bad choice of words here? So I suggest:

NEW:
- Specify experimental mechanisms to provide a transport service.
  This will explain how to select and engage a protocol, = and how
  to discover the availability of protocols on an = interface (both
  end system and path support), in order to provide a = basis for
  incremental = deployment.

Specify experimental mechanisms to provide a given Transport = Service. 
This will explain how to select and engage an = appropriate protocol and 
how to discover which protocols = are available for a given connection. 
This will provide = a basis for incremental deployment.




2.

- Specify experimental mechanisms to deliver a transport service.
  This will explain how to select and engage a = protocol, and how
  to discover the availability of protocols on = an interface (both
  end system and path support), in order to = provide a basis for
  incremental deployment.

I don't understand what "deliver" mean in the first sentence.

- hence I replaced it with "provide" above.


3.
It seems that there are multiple problem statements, with two different
solution tracks: one for existing transport protocols, another one for
new transport protocols.
Both rely on the identifying the transport services/criteria, which is
good.
- existing transport protocols: as you wrote "different protocols can
provide the same services in different ways"
- existing transport protocols: how do we know if endpoints and the path
support those?
- new transport protocol development (I got this from my discussion with
Brian, true it's not really mentioned in the charter)

In your paragraph to which problem statement "this problem" refers to?

    There are many ways in which this = problem could be addressed;
    while it may not yet be clear what = the best way forward could
    be, any approach to provide a = richer set of transport services
    to applications will have to begin = with the identification of
    the services that current = transport protocols provide.

Depending on what "this problem" refers to, the solution might be
     new transport middle = layer
     API services discovery
    OAM services discovery
    etc.

Discussing with Spencer, it means: "which transport building blocks work
for me".

This block above has me a bit confused, I think I lack context, so I won't comment on = it.

a= ddressed above



So this paragraph should be rephrased.
Possible solution

OLD:

    There are many ways in which this = problem could be addressed;
    while it may not yet be clear what = the best way forward could
    be, any approach to provide a = richer set of transport services
    to applications will have to begin = with the identification of
    the services that current = transport protocols provide.

NEW (this paragraph would make more sense after the 3 bullet points "the
Working Group will")

    The Working Group deliverables = will help an application
    programmer identify the important = transport services for his
    application and determine if those = transport services are = available


    on the end points and along the = path in the network. An approach to
    provide a richer set of transport = services to applications (which
    could be part of a future charter) = has to begin with the
identification of
    the services that current = transport protocols provide.

Agreed; I like this change a lot, it's much more concrete and reflects our intention = IMO.

= Yes. Agreed



------------------------------------------------------------= ----------
COMMENT:
= ----------------------------------------------------------------------
=
 "The Working Group will coordinate closely with = other Working Groups and
IRTF Research Groups."
You should list the WGs you have in mind.

I agree that it looks odd as it stands. I'm not sure what the right approach is here (simply remove? or what are these groups?) - e.g. Spencer would know better than = me=85


I think the key thing here was that we aren=92t only = limiting ourselves to working with the IETF but are also interested in = getting input from the IRTF. However I think we can drop = this


Cheers,
Michael


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

= --Apple-Mail=_87FA37AF-8E4A-4B0D-A13F-73EA21F20A3D-- From nobody Fri Jun 27 07:38:28 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932A61B31B6 for ; Fri, 27 Jun 2014 07:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 5w2kcHj-1pPg for ; Fri, 27 Jun 2014 07:38:24 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71A181B3190 for ; Fri, 27 Jun 2014 07:38:23 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1X0XIC-0006Tj-5M; Fri, 27 Jun 2014 16:38:20 +0200 Received: from 089144238254.atnat0047.highway.bob.at ([89.144.238.254] helo=[192.168.0.100]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1X0XI8-0004dQ-3X; Fri, 27 Jun 2014 16:38:20 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_CDF3419D-FEE3-4F20-BCE0-292B34395FD1" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: Date: Fri, 27 Jun 2014 16:38:10 +0200 Message-Id: <33966B16-D15B-49E5-BEBD-C8DE990F8028@ifi.uio.no> References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACAFDA.3060303@gmail.com> <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> <53AD74D8.9010906@gmail.com> To: Toby Moncaster X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 2 sum rcpts/h 7 sum msgs/h 2 total rcpts 17942 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 4F8141B331244046565D45623D95C6E88C648CBE X-UiO-SPAM-Test: remote_host: 89.144.238.254 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 65 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/zo1JeTx1dnixBTYa20g8oyhBJ-I Cc: Benoit Claise , Spencer Dawkins , taps@ietf.org Subject: Re: [Taps] Charter bikeshed #1 - "transport service" X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 14:38:27 -0000 --Apple-Mail=_CDF3419D-FEE3-4F20-BCE0-292B34395FD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, I'll cut away a lot now, and only address things that need addressing = below: On 27. juni 2014, at 16:21, Toby Moncaster = wrote: [snip] > I agree with Michael here. I think we could end up with a much less = clearly worded charter if we go down that route. If there is a need to = be more precise then I=92d favour adding something near the beginning of = the charter along the lines of the definition I put in the Problem = Statement document. Namely: "A Transport Service is any service = provided by the transport layer that can only be correctly implemented = with information from the application.=94We could then include 2 or 3 = example services=20 I agree. Putting that definition in there would be nice. >>>>> - full reliability >>>>> - latency-limited reliability >>>>=20 >>>=20 >>> Yes, reliability is a service, and fine to include in the list. But = I'd rather replace this with any of: >>> "various degrees of reliability" or "various forms of reliability" = or "full / latency-limited / no reliability" >>> ...or something like that. One item, not two, anyway. >=20 >=20 > Hmmm. I=92d rather we had something like =93Degree of reliability from = unreliable to full reliability." Agree. >>> Second, using the phrase "congestion control" binds the application = requirement to a specific mechanism. I'd rather use something like "low = delay vs. high throughput=94. >=20 > Perhaps this would best be expressed as =93Trading off latency and = throughput" Agree. >>>>> I don't know if this list is correct or complete. This should be = the WG >>>>> job to compile it. >>>>> Btw, adding this list to the charter, as a starting point, would = make >>>>> sense. >>>=20 >>> So, to summarize, here's the complete list that I suggest: >>>=20 >>> - sequence preservation >>> - various degrees of reliability >>> - low delay vs. high throughput >=20 > I=92d rephrase this as: >=20 > - ordering/sequence preservation > - degree of reliability=20 > - latency vs throughput Agree, this is nicer! >>>>> How do we call the transport that support those 5 things? a = transport >>>>> protocol? a transport service? >>>>> The "services" term is used multiple times within the charter. >>>>> Sometimes I understand it as a "transport protocol" (like in the = first >>>>> sentence in the charter), >>>>> And sometimes I may interpret it as Brian's "dimensions of = transport" or >>>>> criteria. >>>>>=20 >>>>> Potentially use "criteria" and "transport protocol" >>>>> Alternatively, only use "transport services" when it means = "criteria, and >>>>> "transport protocol". >>>>> I tried to do the latter below. >>>>>=20 >>>>>=20 >>>=20 >>> Again, detailed comments in line: >>>=20 >>>=20 >>>>> OLD: >>>>>=20 >>>>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP, >>>>> UDP-Lite and the LEDBAT congestion control mechanism extend >>>>> the set of transport services that are available to >>>>> applications, beyond those provided by TCP and UDP. For >>>>> example, SCTP provides potentially faster reliable delivery >>>>> for applications that can accept blocks of data out of order, >>>>> and LEDBAT provides low-priority "scavenger" communication. >>>>>=20 >>>>> NEW: >>>>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP, >>>>> UDP-Lite and the LEDBAT congestion control mechanism extend >>>>> the set of transport protocols that are available to >>>>> applications, beyond those provided by TCP and UDP. For >>>>> example, SCTP provides potentially faster reliable delivery >>>>> for applications that can accept blocks of data out of order, >>>>> and LEDBAT provides low-priority "scavenger" communication. >>>=20 >>> Disagree, I'd rather leave it as it is to stress that applications = use services, not protocols. >=20 >=20 > I actually think changing that to protocols might be a good thing, = since it highlights how complex the landscape has become.=20 Okay, fine by me. I don't have a strong opinion here either way. >>>>> OLD: >>>>>=20 >>>>> - Identify services provided by existing IETF transport protocols >>>>> and congestion control mechanisms. The resulting document will >>>>> provide guidance on making a choice among available mechanisms >>>>> and protocols to obtain a certain transport service. >>>>>=20 >>>>>=20 >>>>> NEW: >>>>>=20 >>>>> - Identify transport services provided by existing IETF transport >>>>> protocols >>>>> and congestion control mechanisms. The resulting document will >>>>> provide guidance on making a choice among available mechanisms >>>>> and protocols to obtain a certain transport service. As a = starting >>>>> point >>>>> for transport services, the working group can consider: message >>>>> atomicity, >>>>> stream fragmentation, sequence preservation, head-of-line = blocking >>>>> avoidance, >>>>> sub-channels, full reliability, latency-limited reliability, >>>>> loss-sensitive >>>>> congestion control, delay-sensitive congestion control, endpoint >>>>> address agility, >>>>> privacy and integrity, and path-state propagation = (NAT/Firewall). >>>=20 >>> Sentence 1: "transport services provided by .. transport protocols" = doesn't seem to make things clearer. I'd rather keep "services" in this = sentence - what this means gets concrete anyway due to the list that = follows in sentence 3, and there the phrase "transport services" is used = anyway. The list should be changed, as I argued above. I suggest: >>>=20 >>> NEW: >>>=20 >>> - Identify services provided by existing IETF transport protocols >>> and congestion control mechanisms. The resulting document will >>> provide guidance on making a choice among available mechanisms >>> and protocols to obtain a certain transport service. As a starting = point >>> for transport services, the working group can consider: sequence >>> preservation, various degrees of reliability, low delay vs. high = throughput. >=20 > I think here we=92re once again running into the difficulty of the = ambiguity of the word =93transport=94, especially in the IETF=85 If we = have defined Transport Services in terms of the transport protocol = earlier in the document, can we actually phrase this >=20 > - Identify Transport Services provided by IETF protocols and = congestion control mechanisms Agreed >>>>> OLD: >>>>> - Specify experimental mechanisms to deliver a transport service. >>>>> This will explain how to select and engage a protocol, and how >>>>> to discover the availability of protocols on an interface (both >>>>> end system and path support), in order to provide a basis for >>>>> incremental deployment. >>>>>=20 >>>>> NEW: >>>>> - Specify experimental mechanisms to deliver a transport protocol. >>>>> This will explain how to select and engage a protocol, and how >>>>> to discover the availability of protocol services on an = interface (both >>>>>=20 >>>>> end system and path support), in order to provide a basis for >>>>> incremental deployment. >>>=20 >>>=20 >>> Disagree. "deliver a transport protocol" is weird. The intention was = to say "provide a transport service", maybe "deliver" is a bad choice of = words here? So I suggest: >>>=20 >>> NEW: >>> - Specify experimental mechanisms to provide a transport service. >>> This will explain how to select and engage a protocol, and how >>> to discover the availability of protocols on an interface (both >>> end system and path support), in order to provide a basis for >>> incremental deployment. >=20 > Specify experimental mechanisms to provide a given Transport Service.=20= > This will explain how to select and engage an appropriate protocol and=20= > how to discover which protocols are available for a given connection.=20= > This will provide a basis for incremental deployment. Agreed. >>>>> "The Working Group will coordinate closely with other Working = Groups and >>>>> IRTF Research Groups." >>>>> You should list the WGs you have in mind. >>>=20 >>> I agree that it looks odd as it stands. I'm not sure what the right = approach is here (simply remove? or what are these groups?) - e.g. = Spencer would know better than me=85 >=20 >=20 > I think the key thing here was that we aren=92t only limiting = ourselves to working with the IETF but are also interested in getting = input from the IRTF. However I think we can drop this Agreed. Cheers, Michael --Apple-Mail=_CDF3419D-FEE3-4F20-BCE0-292B34395FD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi,

I'll cut away a = lot now, and only address things that need addressing = below:


On 27. juni = 2014, at 16:21, Toby Moncaster <toby.moncaster@cl.cam.ac.uk> = wrote:

[snip]



Agree.


Second, using the phrase "congestion control" binds = the application requirement to a specific mechanism. I'd rather use = something like "low delay vs. high = throughput=94.

Pe= rhaps this would best be expressed as =93Trading off latency and = throughput"

Agree.=


I = don't know if this list is correct or complete. This should be the = WG
job to compile it.
Btw, adding this list to the charter, as a = starting point, would = make
sense.

So, to = summarize, here's the complete list that I = suggest:

- sequence preservation
- = various degrees of reliability
- low delay vs. high = throughput

I=92d = rephrase this as:

- ordering/sequence = preservation
- degree of reliability 
- latency = vs throughput

Agree, = this is nicer!


How= do we call the transport that support those 5 things? a = transport
protocol? a transport service?
The "services" term is = used multiple times within the charter.
Sometimes I understand it as = a "transport protocol" (like in the first
sentence in the = charter),
And sometimes I may interpret it as Brian's "dimensions of = transport" or
criteria.

Potentially use "criteria" and = "transport protocol"
Alternatively, only use "transport services" = when it means "criteria, and
"transport protocol".
I tried to do = the latter = below.



Again, = detailed comments in line:


OLD:

Conjointly, = transport protocols such as SCTP, DCCP, MPTCP,
UDP-Lite and the = LEDBAT congestion control mechanism extend
the set of transport = services that are available to
applications, beyond those provided by = TCP and UDP. For
example, SCTP provides potentially faster reliable = delivery
for applications that can accept blocks of data out of = order,
and LEDBAT provides low-priority "scavenger" = communication.

NEW:
Conjointly, transport protocols such as = SCTP, DCCP, MPTCP,
UDP-Lite and the LEDBAT congestion control = mechanism extend
the set of transport protocols that are available = to
applications, beyond those provided by TCP and UDP. = For
example, SCTP provides potentially faster reliable = delivery
for applications that can accept blocks of data out of = order,
and LEDBAT provides low-priority "scavenger" = communication.

Disagree, I'd = rather leave it as it is to stress that applications use services, not = protocols.


I actually think changing that to protocols might be a good = thing, since it highlights how complex the landscape has = become. 

Okay, fine by = me. I don't have a strong opinion here either = way.


OLD:

- Identify services provided by existing IETF = transport protocols
  and congestion control mechanisms. = The resulting document will
  provide guidance on making a = choice among available mechanisms
  and protocols to obtain = a certain transport service.


NEW:

- Identify transport = services provided by existing IETF = transport
protocols
  and congestion control mechanisms. = The resulting document will
  provide guidance on making a = choice among available mechanisms
  and protocols to obtain = a certain transport service. As a starting
point
  for = transport services, the working group can consider: = message
atomicity,
  stream fragmentation, sequence = preservation, head-of-line = blocking
avoidance,
  sub-channels, full reliability, = latency-limited reliability,
loss-sensitive
  congestion = control, delay-sensitive congestion control, endpoint
address = agility,
  privacy and integrity, and path-state = propagation = (NAT/Firewall).

Sentence = 1: "transport services provided by ..  transport protocols" doesn't = seem to make things clearer. I'd rather keep "services" in this sentence = - what this means gets concrete anyway due to the list that follows in = sentence 3, and there the phrase "transport services" is used anyway. = The list should be changed, as I argued above. I = suggest:

NEW:

- = Identify services provided by existing IETF transport = protocols
  and congestion control mechanisms. The resulting = document will
  provide guidance on making a choice among = available mechanisms
  and protocols to obtain a certain = transport service. As a starting point
  for transport = services, the working group can consider: sequence
  = preservation, various degrees of reliability, low delay vs. high = throughput.

I think here we=92re once again running into the difficulty of the = ambiguity of the word =93transport=94, especially in the IETF=85 If we = have defined Transport Services in terms of the transport protocol = earlier in the document, can we actually phrase = this

- Identify Transport Services provided by = IETF protocols and congestion control = mechanisms

Agreed


OLD:
- Specify experimental mechanisms to deliver a = transport service.
  This will explain how to select and = engage a protocol, and how
  to discover the availability = of protocols on an interface (both
  end system and path = support), in order to provide a basis for
  incremental = deployment.

NEW:
- Specify experimental mechanisms to deliver = a transport protocol.
  This will explain how to select and = engage a protocol, and how
  to discover the availability = of protocol services on an interface (both

  end system = and path support), in order to provide a basis = for
  incremental = deployment.


Dis= agree. "deliver a transport protocol" is weird. The intention was to say = "provide a transport service", maybe "deliver" is a bad choice of words = here? So I suggest:

NEW:
- Specify = experimental mechanisms to provide a transport service.
  This = will explain how to select and engage a protocol, and how
  to = discover the availability of protocols on an interface (both
  = end system and path support), in order to provide a basis for
  = incremental = deployment.

Speci= fy experimental mechanisms to provide a given Transport = Service. 
This will explain how to select and engage an = appropriate protocol and 
how to discover which protocols = are available for a given connection. 
This will provide = a basis for incremental = deployment.

Agreed.
=

 "The Working Group will coordinate closely with = other Working Groups and
IRTF Research Groups."
You should list = the WGs you have in = mind.

I agree that it = looks odd as it stands. I'm not sure what the right approach is here = (simply remove? or what are these groups?) - e.g. Spencer would know = better than = me=85


<= div>I think the key thing here was that we aren=92t only limiting = ourselves to working with the IETF but are also interested in getting = input from the IRTF. However I think we can drop = this

Agreed.

Cheers,

= --Apple-Mail=_CDF3419D-FEE3-4F20-BCE0-292B34395FD1-- From nobody Fri Jun 27 07:45:36 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCB01B313F for ; Fri, 27 Jun 2014 07:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham 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 dY8BDTWEtKqG for ; Fri, 27 Jun 2014 07:45:31 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 25B131B298A for ; Fri, 27 Jun 2014 07:45:17 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1X0XOu-0002TG-Cc for taps@ietf.org; Fri, 27 Jun 2014 16:45:16 +0200 Received: from 089144238254.atnat0047.highway.bob.at ([89.144.238.254] helo=[192.168.0.100]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1X0XOr-0008Aj-7u for taps@ietf.org; Fri, 27 Jun 2014 16:45:16 +0200 From: Michael Welzl Content-Type: multipart/alternative; boundary="Apple-Mail=_ED88DE3D-FAE8-4FFA-AB6B-BC011DB8D309" Message-Id: <87928669-2007-4F11-900E-1AD7030F08DD@ifi.uio.no> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Date: Fri, 27 Jun 2014 16:45:08 +0200 References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACAFDA.3060303@gmail.com> <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> <53AD74D8.9010906@gmail.com> To: taps@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 3 sum rcpts/h 8 sum msgs/h 3 total rcpts 17943 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 70AB916C0C0C99D28B126C495C91CA6BE0248578 X-UiO-SPAM-Test: remote_host: 89.144.238.254 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 66 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/AWBcld6IFsXobzmUPn5W_yprWAg Subject: [Taps] Stream vs. packet X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 14:45:33 -0000 --Apple-Mail=_ED88DE3D-FAE8-4FFA-AB6B-BC011DB8D309 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, I changed the subject because this is not about the chartering = discussion anymore - it's beginning our work :-) Toby, in his last email, raised the following question: On 27. juni 2014, at 16:21, Toby Moncaster = wrote: [snip] >>>>> - message atomicity >>>=20 >>> What's that? That multiple messages are not combined into one = packet? This plays a role for an application only when there is = significant loss (I think). Wouldn't it be nice to have a system that = provides atomicity only when needed and otherwise saves header overhead? = I would vote against exposing that. Either way, I vote it off the list = that goes in the charter, it's not an obvious service to me. >=20 > To some extent I agree here. But is there any way we can correctly = express the differences between stream and packet oriented transports? Can we try to make a simple decision here, as a group, to never even = really consider streams at all? It seems to me to be straightforward to provide a stream-based transport = over a message-based transport, so this is something that can simply = always be done. Thus, can we just write a disclaimer in one of our = documents, recommending that any TAPS-supporting systems can provide = stream-based transport on top of the message based transport too, but = that its users must be aware of limitations that arise from streams = (such as HOL blocking delay, no ALF, ..)? Cheers, Michael --Apple-Mail=_ED88DE3D-FAE8-4FFA-AB6B-BC011DB8D309 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi,

I changed the subject because = this is not about the chartering discussion anymore - it's beginning our = work   :-)


Toby, in his = last email, raised the following question:



    - message = atomicity

What's that? = That multiple messages are not combined into one packet? This plays a = role for an application only when there is significant loss (I think). = Wouldn't it be nice to have a system that provides atomicity only when = needed and otherwise saves header overhead? I would vote against = exposing that. Either way, I vote it off the list that goes in the = charter, it's not an obvious service to = me.

To = some extent I agree here. But is there any way we can correctly express = the differences between stream and packet oriented = transports?

Can = we try to make a simple decision here, as a group, to never even really = consider streams at all?

It seems to me to be = straightforward to provide a stream-based transport over a message-based = transport, so this is something that can simply always be done. Thus, = can we just write a disclaimer in one of our documents, recommending = that any TAPS-supporting systems can provide stream-based transport on = top of the message based transport too, but that its users must be aware = of limitations that arise from streams (such as HOL blocking delay, no = ALF, = ..)?

Cheers,
Michael

= --Apple-Mail=_ED88DE3D-FAE8-4FFA-AB6B-BC011DB8D309-- From nobody Fri Jun 27 07:51:14 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F037F1B2CB3 for ; Fri, 27 Jun 2014 07:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001] autolearn=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 SKqiKTnrH9hB for ; Fri, 27 Jun 2014 07:50:59 -0700 (PDT) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77CC11B2C4C for ; Fri, 27 Jun 2014 07:50:58 -0700 (PDT) X-Spam-Processed: mail.kau.se, Fri, 27 Jun 2014 16:50:44 +0200 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: annabrun@kau.se X-MDRemoteIP: 193.11.156.68 X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se X-MDaemon-Deliver-To: taps@ietf.org Message-ID: <53AD84CE.5080404@kau.se> Date: Fri, 27 Jun 2014 16:50:54 +0200 From: Anna Brunstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: taps@ietf.org References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACAFDA.3060303@gmail.com> <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> <53AD74D8.9010906@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050209070607080307010202" Archived-At: http://mailarchive.ietf.org/arch/msg/taps/zzU207e4gWja3ITfmHuzlYr8YEI Subject: Re: [Taps] Charter bikeshed #1 - "transport service" X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2014 14:51:12 -0000 This is a multi-part message in MIME format. --------------050209070607080307010202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, A few comments inline. The short summary is that I agree with most of the main points below and also prefer having a list of examples. Anna On 2014-06-27 16:21, Toby Moncaster wrote: > I'm going to try and add some (hopefully) relevant comments inline :) > > > On 27 Jun 2014, at 14:42, Spencer Dawkins > > > wrote: > >> >> On 06/27/2014 04:33 AM, Michael Welzl wrote: >>> Hi, >>> >>> I'm afraid this'll have to be long; in line: >> >> Hi, Michael, >> >> This was long, but helpful. >> >> I agree with the point about the working group needing to work >> through the list, and that not being a requirement for actual charter >> approval. Would other folk be OK with naming a couple of examples, >> rather than a starting list, as Benoit and I had been discussing? > > I have a very strong preference for a set of examples. If we have too > long a list I fear it might bias the actual outcome of the work we > hope this WG will do! I agree. > >> >> On one point (that Michael said he was confused about below, so maybe >> worth explaining better), Benoit and I spent about 20 minutes talking >> before he balloted his block, and one thing we talked about was the >> difference between an application knowing what's available on a >> platform and knowing what's available on the path between two >> endpoints (so, if I can send UDP to any port to Benoit, but a >> firewall between me and Michael drops all UDP except for port 53, >> both of those facts are relevant). > > OK, That makes sense. This is a difference between "Which services are > available in my transport stack" and "Which services can I use on a > particular connection". One of the points of thinking in terms of > falling back to e.g. TCP is to address this problem. > > Also to my way of thinking the purpose of describing these as > "services" is to abstract away the actual mechanism that delivers the > service. In turn this gives the potential for the TAPS-aware transport > to select the transport protocol that most closely matches the desired > set of services > >> >> This is what we meant when Benoit said "which transport building >> blocks work for me" below. >> >> And thanks for staying engaged. I appreciate it. >> >> Spencer >> >>> On 27. juni 2014, at 01:42, Spencer Dawkins >>> >> > wrote: >>> >>>> As you'll notice in Benoit's comments below, he's finding "service" >>>> and "transport service" to be fairly vague. He ends up proposing >>>> that the charter would not use "service" without an adjective, and >>>> that the charter use "transport service" to describe "transport >>>> protocol + criterion", so in a fairly constrained way. >>> >>> Well, frankly, I don't think that's moving the charter in a good >>> direction. Talking about services rather than protocols makes it >>> clearer that we don't want to bind applications to protocols >>> anymore, but rather to what protocols provide to applications that >>> use them (see, even that sentence gets a bit strange if I avoid the >>> word service - and if we don't use that word here, what else is it >>> that a protocol offers / provides to applications?). > > > I agree with Michael here. I think we could end up with a much less > clearly worded charter if we go down that route. If there is a need to > be more precise then I'd favour adding something near the beginning of > the charter along the lines of the definition I put in the Problem > Statement document. Namely: "A Transport Service is any service > provided by the transport layer that can only be correctly implemented > with information from the application."We could then include 2 or 3 > example services I agree. >>> >>> >>>> I'd like to use terms in the charter that won't confuse the heck >>>> out of the average reader, so I'm curious what the folks on the >>>> TAPS mailing list think (after looking at his proposed text changes >>>> below, of course, because we would never express an opinion without >>>> considering context). >>> >>> I know that the word "service" is very often vaguely used and >>> dislike the word myself for that - but in fact, here, I think it >>> really is the best choice. It's about what an application gets from >>> a protocol - e.g. "characteristics" describes a protocol, i.e. is >>> about internals that may not be relevant to an application. Indeed, >>> the email below shows some of that misunderstanding, based on >>> Brian's list. I'll explain below. >>> >>> As for avoiding confusion, having a shortened version of Brian's >>> list as examples should do it - you see the list, you know what this >>> is about. > > yes > >>> >>> >>>> I should also mention that a couple of ADs have asked me if TAPS >>>> can be described as a session layer. One of my definitions of >>>> "session layer" is "surviving transport-layer disconnections and >>>> reconnections", and I haven't seen people talking about that on >>>> e-mail, so I'm thinking calling it a session layer wouldn't help >>>> (replacing a confusing term with another confusing term). >>> >>> +1 to your opinion! > > +1 Session layer will just totally throw everyone! > > >>> >>> >>>> I kept Benoit on as CC:, so he can say "yes, that helps", or "no, >>>> that's worse", but dropped the rest of the IESG from this part of >>>> the conversation, in case this turns out to be a bikeshed. >>>> >>>> Spencer >>>> >>>> On 06/25/2014 08:15 AM, Benoit Claise wrote: >>>>> Benoit Claise has entered the following ballot position for >>>>> charter-ietf-taps-00-00: Block >>>>> >>>>> 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: >>>>> http://datatracker.ietf.org/doc/charter-ietf-taps/ >>>>> >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> BLOCK: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> I support the work, but I have a BLOCK anyway. The charter needs to >>>>> clarify a few points. >>>>> >>>>> 1. (somehow similar to Alissa's COMMENT) >>>>> The charter should mention that the WG will first analyze the set of >>>>> relevant criteria. >>>>> I guess that this is what's meant by "services" in this entry but >>>>> "services" is an overloaded term. >>>>> >>>>> Identify services provided by existing IETF transport protocols >>>>> and congestion control mechanisms. The resulting document will >>>>> provide guidance on making a choice among available mechanisms >>>>> and protocols to obtain a certain transport service. >>>>> >>>>> Brian Trammell, during his IESG/IAB retreat presentation called that >>>>> "dimensions of transport": >>> >>> There you go, he called it "dimensions", not "services", so the list >>> is broader in scope. I agree with including parts of his list in the >>> charter, as examples of services, but not the whole list because IMO >>> some items don't belong there. I'll go through them item by item >>> below, applying the following criterion: would an application >>> programmer ever want to say "yes" or "no" to this, without trying to >>> optimize for specific environment conditions? First, we don't want >>> to replace complexity with more complexity, so not exposing >>> absolutely every detail is part of the point here. Second, >>> programmers who prefer to write code themselves that optimizes for >>> specific environments are probably not the typical "customers" of >>> TAPS - probably such folks will want to continue choosing and >>> configuring their protocol directly. I'm not saying TAPS is meant to >>> be sub-optimal :-) I'm saying it's meant to be able to automatize >>> optimizing for the path, and so we should probably only expose >>> things that are related to application requirements, irrespective of >>> the path. >>> >>> Obviously, we're getting into a sort of discussion that we should >>> have in the WG-to-be, not now. But my point is: if the group should >>> at some point decide that what I say above is the way to go, then >>> replacing "service" with "protocol" etc. gets in the way, and so >>> does the full list of Brian. >>> >>> As I go through the list, I also raise questions about the items I >>> criticize, but I don't want to discuss them yet: this is just to >>> highlight that these items can create a confusion and should be >>> removed from the list that goes in the charter. >>> >>> >>>>> - message atomicity >>> >>> What's that? That multiple messages are not combined into one >>> packet? This plays a role for an application only when there is >>> significant loss (I think). Wouldn't it be nice to have a system >>> that provides atomicity only when needed and otherwise saves header >>> overhead? I would vote against exposing that. Either way, I vote it >>> off the list that goes in the charter, it's not an obvious service >>> to me. > > To some extent I agree here. But is there any way we can correctly > express the differences between stream and packet oriented transports? > I agree that this could be a good example of a useful service. From an application perspective, I would rather use message than packet though. Message preservation, message framing, preserving message boundaries? >>> >>> >>>>> - stream fragmentation >>> >>> Is this the opposite of atomicity? (then, why is it "stream", not >>> "message" fragmentation?). If it is, I wouldn't want to include it >>> in the list for the reasons I gave about atomicity above. >>> >>> >>>>> - sequence preservation >>> >>> Definitely a service! This absolutely depends on your application >>> and nothing else. > > agree > >>> >>> >>>>> - head-of-line blocking avoidance >>> >>> Not a service at all, and potentially harmful to expose. This is a >>> performance optimization, a benefit that you can get if a protocol, >>> set of protocols, "session layer", whatever you want to call it, >>> does its job right. Why do I say "potentially harmful"? If an >>> application would select "I don't need sequence preservation" and >>> "you must give me HOL blocking avoidance", then this combination can >>> be provided with SCTP, but we have no way to use normal TCP as a >>> fall-back because it comes with HOL blocking. So the whole system is >>> limited by this set of choices. How harmful is such a fall-back >>> however? It's just some extra delay in a best effort Internet. Just >>> the kind of flexibility that we may want to have. > > agree with Michael, although I'm not sure I completely agree with how > he expresses the objection > >>> >>> >>>>> - sub-channels >>> >>> Not a service. You can get the benefits of sub-channels without >>> exposing them. See: >>> http://heim.ifi.uio.no/michawe/research/publications/globecom2011.pdf >>> for a proof of concept. Indeed, on what basis does an application >>> say "a sub-channel please"? This is like saying "over UDP please". >>> You shouldn't have to care. >>> >>> >>>>> - full reliability >>>>> - latency-limited reliability >>>> >>> Yes, reliability is a service, and fine to include in the list. But >>> I'd rather replace this with any of: >>> "various degrees of reliability" or "various forms of reliability" >>> or "full / latency-limited / no reliability" >>> ...or something like that. One item, not two, anyway. > > > Hmmm. I'd rather we had something like "Degree of reliability from > unreliable to full reliability." > >>> >>> >>>>> - loss-sensitive congestion control >>>>> - delay-sensitive congestion control >>> >>> "loss-sensitive congestion control" isn't a good name for a service >>> because it indicates that there would be less loss, but in fact >>> delay-sensitive congestion controllers tend to lose less :-) The >>> choice of a loss-sensitive vs. delay-sensitive congestion controller >>> (to use things that are in RFCs: LEDBAT vs. TCP's AIMD CC.) is a >>> choice of a trade-off between throughput (potentially less, with >>> LEDBAT) vs. delay (also potentially less, with LEDBAT). >>> >>> So, first of all, I'd remove "loss-sensitive congestion control" >>> from the list. > > Slightly disagree here. But can't quite put it into words I would also remove "loss-sensitive congestion control" > >>> >>> Second, using the phrase "congestion control" binds the application >>> requirement to a specific mechanism. I'd rather use something like >>> "low delay vs. high throughput". > > Perhaps this would best be expressed as "Trading off latency and > throughput" > > >>> >>> >>>>> - endpoint address agility >>> >>> I'm not sure. Unsure enough to recommend removing it from the list. > > No views either way. But the fact there is any uncertainty is in > itself a good reason not to list this as a service in the charter > (since that effectively is making the decision that it IS a service) > >>> >>> >>>>> - privacy and integrity >>> >>> See the discussion on security: I'd rather have it removed (given >>> that this is just a list of examples, we can be rather restrictive >>> about what goes in it). > > Agree. Remove this for the initial list > >>> >>> >>>>> - path-state propagation (NAT/FW) >>> >>> As with security, not sure how much of this / in which form we'd >>> want to expose, and so I'd feel better if it were removed. > > Agree. Remove this for the initial list > >>> >>> >>>>> I don't know if this list is correct or complete. This should be >>>>> the WG >>>>> job to compile it. >>>>> Btw, adding this list to the charter, as a starting point, would make >>>>> sense. >>> >>> So, to summarize, here's the complete list that I suggest: >>> >>> - sequence preservation >>> - various degrees of reliability >>> - low delay vs. high throughput > > I'd rephrase this as: > > - ordering/sequence preservation > - degree of reliability > - latency vs throughput > All good updates I think. >>> >>> Yes it's short, but for a list of examples, that could be ok? >>> >>> >>>>> I'm an application designer, I care for a transport that will provide >>>>> me: >>>>> - message atomicity >>>>> - head-of-line blocking avoidance >>>>> - sub-channels >>>>> - full reliability >>>>> - loss-sensitive congestion control >>> >>> Wouldn't you rather say: >>> - high throughput (don't care so much about low delay) >>> - full reliability >>> - sequence preservation doesn't matter to me >>> ... and have a system underneath automatically gives you >>> head-of-line blocking avoidance and uses loss-sensitive congestion >>> control? >>> (Ideally, that system would also use sub-channels if they do improve >>> performance, and provides message atomicity only if this is a >>> benefit, i.e. only if there is significant loss) >>> >>> >>>>> How do we call those 5 things? criteria? >>> >>> A mess? > > If TAPS is ever to be successful we have to get and keep the > application developers on side. So I would say that application > designers might have a list of desired outcomes for their application > and TAPS is about marrying that up with the underlying services that > lead to those outcomes > >>> >>> >>>>> How do we call the transport that support those 5 things? a transport >>>>> protocol? a transport service? >>>>> The "services" term is used multiple times within the charter. >>>>> Sometimes I understand it as a "transport protocol" (like in the first >>>>> sentence in the charter), >>>>> And sometimes I may interpret it as Brian's "dimensions of >>>>> transport" or >>>>> criteria. >>>>> >>>>> Potentially use "criteria" and "transport protocol" >>>>> Alternatively, only use "transport services" when it means >>>>> "criteria, and >>>>> "transport protocol". >>>>> I tried to do the latter below. >>>>> >>>>> >>> >>> Again, detailed comments in line: >>> >>> >>>>> OLD: >>>>> >>>>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP, >>>>> UDP-Lite and the LEDBAT congestion control mechanism extend >>>>> the set of transport services that are available to >>>>> applications, beyond those provided by TCP and UDP. For >>>>> example, SCTP provides potentially faster reliable delivery >>>>> for applications that can accept blocks of data out of order, >>>>> and LEDBAT provides low-priority "scavenger" communication. >>>>> >>>>> NEW: >>>>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP, >>>>> UDP-Lite and the LEDBAT congestion control mechanism extend >>>>> the set of transport protocols that are available to >>>>> applications, beyond those provided by TCP and UDP. For >>>>> example, SCTP provides potentially faster reliable delivery >>>>> for applications that can accept blocks of data out of order, >>>>> and LEDBAT provides low-priority "scavenger" communication. >>> >>> Disagree, I'd rather leave it as it is to stress that applications >>> use services, not protocols. > > > I actually think changing that to protocols might be a good thing, > since it highlights how complex the landscape has become. I disagree. I agree with Michael here that we shoud stress that applications use services, not protocols. Also the examples talk about services not protocols so the proposed new wording is strange to me. > >>> >>> >>>>> OLD: >>>>> >>>>> - Identify services provided by existing IETF transport protocols >>>>> and congestion control mechanisms. The resulting document will >>>>> provide guidance on making a choice among available mechanisms >>>>> and protocols to obtain a certain transport service. >>>>> >>>>> >>>>> NEW: >>>>> >>>>> - Identify transport services provided by existing IETF transport >>>>> protocols >>>>> and congestion control mechanisms. The resulting document will >>>>> provide guidance on making a choice among available mechanisms >>>>> and protocols to obtain a certain transport service. As a starting >>>>> point >>>>> for transport services, the working group can consider: message >>>>> atomicity, >>>>> stream fragmentation, sequence preservation, head-of-line blocking >>>>> avoidance, >>>>> sub-channels, full reliability, latency-limited reliability, >>>>> loss-sensitive >>>>> congestion control, delay-sensitive congestion control, endpoint >>>>> address agility, >>>>> privacy and integrity, and path-state propagation (NAT/Firewall). >>> >>> Sentence 1: "transport services provided by .. transport protocols" >>> doesn't seem to make things clearer. I'd rather keep "services" in >>> this sentence - what this means gets concrete anyway due to the list >>> that follows in sentence 3, and there the phrase "transport >>> services" is used anyway. The list should be changed, as I argued >>> above. I suggest: >>> >>> NEW: >>> >>> - Identify services provided by existing IETF transport protocols >>> and congestion control mechanisms. The resulting document will >>> provide guidance on making a choice among available mechanisms >>> and protocols to obtain a certain transport service. As a starting >>> point >>> for transport services, the working group can consider: sequence >>> preservation, various degrees of reliability, low delay vs. high >>> throughput. > > I think here we're once again running into the difficulty of the > ambiguity of the word "transport", especially in the IETF... If we > have defined Transport Services in terms of the transport protocol > earlier in the document, can we actually phrase this > > - Identify Transport Services provided by IETF protocols and > congestion control mechanisms > > >>> >>> >>> >>>>> OLD: >>>>> >>>>> - Specify a subset of those services identified in item 1, which >>>>> end systems supporting TAPS need to provide and provide guidance >>>>> on choosing among available mechanisms and protocols to obtain >>>>> a given transport service. >>>>> >>>>> NEW: >>>>> - Specify a subset of those transport services identified in item 1, >>>>> which >>>>> end systems supporting TAPS need to provide and provide guidance >>>>> on choosing among available mechanisms and protocols. >>> >>> Agreed. > > agree as well > >>> >>> >>>>> OLD: >>>>> - Specify experimental mechanisms to deliver a transport service. >>>>> This will explain how to select and engage a protocol, and how >>>>> to discover the availability of protocols on an interface (both >>>>> end system and path support), in order to provide a basis for >>>>> incremental deployment. >>>>> >>>>> NEW: >>>>> - Specify experimental mechanisms to deliver a transport protocol. >>>>> This will explain how to select and engage a protocol, and how >>>>> to discover the availability of protocol services on an >>>>> interface (both >>>>> >>>>> end system and path support), in order to provide a basis for >>>>> incremental deployment. >>> >>> >>> Disagree. "deliver a transport protocol" is weird. The intention was >>> to say "provide a transport service", maybe "deliver" is a bad >>> choice of words here? So I suggest: >>> >>> NEW: >>> - Specify experimental mechanisms to provide a transport service. >>> This will explain how to select and engage a protocol, and how >>> to discover the availability of protocols on an interface (both >>> end system and path support), in order to provide a basis for >>> incremental deployment. > > Specify experimental mechanisms to provide a given Transport Service. > This will explain how to select and engage an appropriate protocol and > how to discover which protocols are available for a given connection. > This will provide a basis for incremental deployment. > > >>> >>> >>>>> 2. >>>>> >>>>> - Specify experimental mechanisms to deliver a transport service. >>>>> This will explain how to select and engage a protocol, and how >>>>> to discover the availability of protocols on an interface (both >>>>> end system and path support), in order to provide a basis for >>>>> incremental deployment. >>>>> >>>>> I don't understand what "deliver" mean in the first sentence. >>> >>> - hence I replaced it with "provide" above. >>> >>> >>>>> 3. >>>>> It seems that there are multiple problem statements, with two >>>>> different >>>>> solution tracks: one for existing transport protocols, another one for >>>>> new transport protocols. >>>>> Both rely on the identifying the transport services/criteria, which is >>>>> good. >>>>> - existing transport protocols: as you wrote "different protocols can >>>>> provide the same services in different ways" >>>>> - existing transport protocols: how do we know if endpoints and >>>>> the path >>>>> support those? >>>>> - new transport protocol development (I got this from my >>>>> discussion with >>>>> Brian, true it's not really mentioned in the charter) >>>>> >>>>> In your paragraph to which problem statement "this problem" refers to? >>>>> >>>>> There are many ways in which this problem could be addressed; >>>>> while it may not yet be clear what the best way forward could >>>>> be, any approach to provide a richer set of transport services >>>>> to applications will have to begin with the identification of >>>>> the services that current transport protocols provide. >>>>> >>>>> Depending on what "this problem" refers to, the solution might be >>>>> new transport middle layer >>>>> API services discovery >>>>> OAM services discovery >>>>> etc. >>>>> >>>>> Discussing with Spencer, it means: "which transport building >>>>> blocks work >>>>> for me". >>> >>> This block above has me a bit confused, I think I lack context, so I >>> won't comment on it. > > addressed above > >>> >>> >>>>> So this paragraph should be rephrased. >>>>> Possible solution >>>>> >>>>> OLD: >>>>> >>>>> There are many ways in which this problem could be addressed; >>>>> while it may not yet be clear what the best way forward could >>>>> be, any approach to provide a richer set of transport services >>>>> to applications will have to begin with the identification of >>>>> the services that current transport protocols provide. >>>>> >>>>> NEW (this paragraph would make more sense after the 3 bullet >>>>> points "the >>>>> Working Group will") >>>>> >>>>> The Working Group deliverables will help an application >>>>> programmer identify the important transport services for his >>>>> application and determine if those transport services are >>>>> available > > >>>>> on the end points and along the path in the network. An >>>>> approach to >>>>> provide a richer set of transport services to applications (which >>>>> could be part of a future charter) has to begin with the >>>>> identification of >>>>> the services that current transport protocols provide. >>> >>> Agreed; I like this change a lot, it's much more concrete and >>> reflects our intention IMO. > > Yes. Agreed > >>> >>> >>>>> ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> ---------------------------------------------------------------------- >>>>> >>>>> "The Working Group will coordinate closely with other Working >>>>> Groups and >>>>> IRTF Research Groups." >>>>> You should list the WGs you have in mind. >>> >>> I agree that it looks odd as it stands. I'm not sure what the right >>> approach is here (simply remove? or what are these groups?) - e.g. >>> Spencer would know better than me... > > > I think the key thing here was that we aren't only limiting ourselves > to working with the IETF but are also interested in getting input from > the IRTF. However I think we can drop this > >>> >>> Cheers, >>> Michael >>> >> >> _______________________________________________ >> 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 --------------050209070607080307010202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

A few comments inline. The short summary is that I agree with most of the main points below and also prefer having a list of examples.

Anna

On 2014-06-27 16:21, Toby Moncaster wrote:
I’m going to try and add some (hopefully) relevant comments inline :)




On 06/27/2014 04:33 AM, Michael Welzl wrote:
Hi,

I'm afraid this'll have to be long; in line:

Hi, Michael,

This was long, but helpful.

I agree with the point about the working group needing to work through the list, and that not being a requirement for actual charter approval. Would other folk be OK with naming a couple of examples, rather than a starting list, as Benoit and I had been discussing?

I have a very strong preference for a set of examples. If we have too long a list I fear it might bias the actual outcome of the work we hope this WG will do!

I agree.



On one point (that Michael said he was confused about below, so maybe worth explaining better), Benoit and I spent about 20 minutes talking before he balloted his block, and one thing we talked about was the difference between an application knowing what's available on a platform and knowing what's available on the path between two endpoints (so, if I can send UDP to any port to Benoit, but a firewall between me and Michael drops all UDP except for port 53, both of those facts are relevant).

OK, That makes sense. This is a difference between “Which services are available in my transport stack” and “Which services can I use on a particular connection”. One of the points of thinking in terms of falling back to e.g. TCP is to address this problem. 

Also to my way of thinking the purpose of describing these as “services” is to abstract away the actual mechanism that delivers the service. In turn this gives the potential for the TAPS-aware transport to select the transport protocol that most closely matches the desired set of services


This is what we meant when Benoit said "which transport building blocks work for me" below.

And thanks for staying engaged. I appreciate it.

Spencer

On 27. juni 2014, at 01:42, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:

As you'll notice in Benoit's comments below, he's finding "service" and "transport service" to be fairly vague. He ends up proposing that the charter would not use "service" without an adjective, and that the charter use "transport service" to describe "transport protocol + criterion", so in a fairly constrained way.

Well, frankly, I don't think that's moving the charter in a good direction. Talking about services rather than protocols makes it clearer that we don't want to bind applications to protocols anymore, but rather to what protocols provide to applications that use them (see, even that sentence gets a bit strange if I avoid the word service - and if we don't use that word here, what else is it that a protocol offers / provides to applications?).


I agree with Michael here. I think we could end up with a much less clearly worded charter if we go down that route. If there is a need to be more precise then I’d favour adding something near the beginning of the charter along the lines of the definition I put in the Problem Statement document. Namely:  "A Transport Service is any service provided by the transport layer that can only be correctly implemented with information from the application.”We could then include 2 or 3 example services 

        

      

    

    

    I agree.

    

    

      

        

          

            

              

                

                  

                    


                    

                    


                    

                    
I'd like to use terms in the
                      charter that won't confuse the heck out of the
                      average reader, so I'm curious what the folks on
                      the TAPS mailing list think (after looking at his
                      proposed text changes below, of course, because we
                      would never express an opinion without considering
                      context).

                    

                    


                    

                    
I know that the word "service" is very often
                      vaguely used and dislike the word myself for that
                      - but in fact, here, I think it really is the best
                      choice. It's about what an application gets from a
                      protocol - e.g. "characteristics" describes a
                      protocol, i.e. is about internals that may not be
                      relevant to an application. Indeed, the email
                      below shows some of that misunderstanding, based
                      on Brian's list. I'll explain below.

                    


                    

                    
As for avoiding confusion, having a shortened
                      version of Brian's list as examples should do it -
                      you see the list, you know what this is about.

                  

                

              

            

          

          


          

          
yes

          

          

            

              

                

                  

                    


                    

                    

                    
I should also mention that a
                      couple of ADs have asked me if TAPS can be
                      described as a session layer. One of my
                      definitions of "session layer" is "surviving
                      transport-layer disconnections and reconnections",
                      and I haven't seen people talking about that on
                      e-mail, so I'm thinking calling it a session layer
                      wouldn't help (replacing a confusing term with
                      another confusing term).

                    

                    


                    

                    +1 to your opinion!

                

              

            

          

          


          

          
+1 Session layer will just totally throw everyone!

          


          

          

          

            

              

                

                  


                  

                  


                    
I kept Benoit on as CC:, so
                      he can say "yes, that helps", or "no, that's
                      worse", but dropped the rest of the IESG from this
                      part of the conversation, in case this turns out
                      to be a bikeshed.

                      

                      Spencer

                      

                      On 06/25/2014 08:15 AM, Benoit Claise wrote:

                      
Benoit Claise has entered
                        the following ballot position for

                        charter-ietf-taps-00-00: Block

                        

                        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:

                        http://datatracker.ietf.org/doc/charter-ietf-taps/

                        

                        

                        

----------------------------------------------------------------------

                        BLOCK:

----------------------------------------------------------------------

                        

                        I support the work, but I have a BLOCK anyway.
                        The charter needs to

                        clarify a few points.

                        

                        1. (somehow similar to Alissa's COMMENT)

                        The charter should mention that the WG will
                        first analyze the set of

                        relevant criteria.

                        I guess that this is what's meant by "services"
                        in this entry but

                        "services" is an overloaded term.

                        

                          Identify services provided by existing IETF
                        transport protocols

                          and congestion control mechanisms. The
                        resulting document will

                          provide guidance on making a choice among
                        available mechanisms

                          and protocols to obtain a certain transport
                        service.

                        

                        Brian Trammell, during his IESG/IAB retreat
                        presentation called that

                        "dimensions of transport":

                      

                    

                    


                    

                    There you go, he called it "dimensions", not
                    "services", so the list is broader in scope. I agree
                    with including parts of his list in the charter, as
                    examples of services, but not the whole list because
                    IMO some items don't belong there. I'll go through
                    them item by item below, applying the following
                    criterion: would an application programmer ever want
                    to say "yes" or "no" to this, without trying to
                    optimize for specific environment conditions? First,
                    we don't want to replace complexity with more
                    complexity, so not exposing absolutely every detail
                    is part of the point here. Second, programmers who
                    prefer to write code themselves that optimizes for
                    specific environments are probably not the typical
                    "customers" of TAPS - probably such folks will want
                    to continue choosing and configuring their protocol
                    directly. I'm not saying TAPS is meant to be
                    sub-optimal :-)  I'm saying it's meant to be able to
                    automatize optimizing for the path, and so we should
                    probably only expose things that are related to
                    application requirements, irrespective of the path.

                  


                  

                  
Obviously, we're getting into a sort of
                    discussion that we should have in the WG-to-be, not
                    now. But my point is: if the group should at some
                    point decide that what I say above is the way to go,
                    then replacing "service" with "protocol" etc. gets
                    in the way, and so does the full list of Brian.

                  


                  

                  
As I go through the list, I also raise questions
                    about the items I criticize, but I don't want to
                    discuss them yet: this is just to highlight that
                    these items can create a confusion and should be
                    removed from the list that goes in the charter.

                  


                  

                  


                    

                      
     - message atomicity

                      

                    

                    


                    

                    
What's that? That multiple messages are not
                      combined into one packet? This plays a role for an
                      application only when there is significant loss (I
                      think). Wouldn't it be nice to have a system that
                      provides atomicity only when needed and otherwise
                      saves header overhead? I would vote against
                      exposing that. Either way, I vote it off the list
                      that goes in the charter, it's not an obvious
                      service to me.

                  

                

              

            

          

          


          

          
To some extent I agree here. But is there any way we can
            correctly express the differences between stream and packet
            oriented transports?

          

        

      

    

    

    I agree that this could be a good example of a useful service. From
    an application perspective, I would rather use message than packet
    though. Message preservation, message framing, preserving message
    boundaries?

    

    

      

        

          

            

              

                

                  

                    


                    

                    

                    

                      
     - stream
                        fragmentation

                      

                    

                    


                    

                    
Is this the opposite of atomicity? (then, why
                      is it "stream", not "message" fragmentation?). If
                      it is, I wouldn't want to include it in the list
                      for the reasons I gave about atomicity above.

                    


                    

                    

                    

                      
     - sequence
                        preservation

                      

                    

                    


                    

                    Definitely a service! This absolutely depends on
                    your application and nothing else.

                

              

            

          

          


          

          
agree

          

          

            

              

                

                  


                  

                  


                    

                      
     - head-of-line
                        blocking avoidance

                      

                    

                    


                    

                    
Not a service at all, and potentially harmful
                      to expose. This is a performance optimization, a
                      benefit that you can get if a protocol, set of
                      protocols, "session layer", whatever you want to
                      call it, does its job right. Why do I say
                      "potentially harmful"? If an application would
                      select "I don't need sequence preservation" and
                      "you must give me HOL blocking avoidance", then
                      this combination can be provided with SCTP, but we
                      have no way to use normal TCP as a fall-back
                      because it comes with HOL blocking. So the whole
                      system is limited by this set of choices. How
                      harmful is such a fall-back however? It's just
                      some extra delay in a best effort Internet. Just
                      the kind of flexibility that we may want to have.

                  

                

              

            

          

          


          

          
agree with Michael, although I’m not sure I completely
            agree with how he expresses the objection

          

          

            

              

                

                  

                    


                    

                    

                    

                      
     - sub-channels

                      

                    

                    


                    

                    
Not a service. You can get the benefits of
                      sub-channels without exposing them. See:

                    
                    
for a proof of concept. Indeed, on what
                        basis does an application say "a sub-channel
                        please"? This is like saying "over UDP please".
                        You shouldn't have to care.

                    


                      

                    

                    

                      
     - full reliability

                      

                    

                    

                      

                        

                          

                            
    -
                              latency-limited reliability

                            

                          

                          

                            


                            

                          

                        

                      

                    

                    
Yes, reliability is a service, and fine to
                      include in the list. But I'd rather replace this
                      with any of:

                    
"various degrees of reliability" or "various
                      forms of reliability" or "full / latency-limited /
                      no reliability"

                    
...or something like that.  One item, not two,
                      anyway.

                  

                

              

            

          

          


          

          


          

          
Hmmm. I’d rather we had something like “Degree of
            reliability from unreliable to full reliability."

          

          

            

              

                

                  

                    


                    

                  

                  


                    

                      
     - loss-sensitive
                        congestion control

                            - delay-sensitive congestion control

                      

                    

                    


                    

                    
"loss-sensitive congestion control" isn't a
                      good name for a service because it indicates that
                      there would be less loss, but in fact
                      delay-sensitive congestion controllers tend to
                      lose less  :-)    The choice of a loss-sensitive
                      vs. delay-sensitive congestion controller (to use
                      things that are in RFCs: LEDBAT vs. TCP's AIMD
                      CC.) is a choice of a trade-off between throughput
                      (potentially less, with LEDBAT) vs. delay (also
                      potentially less, with LEDBAT).

                    


                    

                    
So, first of all, I'd remove "loss-sensitive
                      congestion control" from the list.

                  

                

              

            

          

          


          

          
Slightly disagree here. But can’t quite put it into words

        

      

    

    

    I would also remove "loss-sensitive congestion control"

    

    

      

        


          

            

              

                

                  

                    


                    

                    
Second, using the phrase "congestion control"
                      binds the application requirement to a specific
                      mechanism. I'd rather use something like "low
                      delay vs. high throughput”.

                  

                

              

            

          

          


          

          
Perhaps this would best be expressed as “Trading off
            latency and throughput"

          


          

          

          

            

              

                

                  

                    


                    

                    

                    

                      
     - endpoint address
                        agility

                      

                    

                    


                    

                    
I'm not sure. Unsure enough to recommend
                      removing it from the list.

                  

                

              

            

          

          


          

          
No views either way. But the fact there is any
            uncertainty is in itself a good reason not to list this as a
            service in the charter (since that effectively is making the
            decision that it IS a service)

          

          

            

              

                

                  

                    


                    

                    

                    

                      
     - privacy and
                        integrity

                      

                    

                    


                    

                    
See the discussion on security: I'd rather have
                      it removed (given that this is just a list of
                      examples, we can be rather restrictive about what
                      goes in it).

                  

                

              

            

          

          


          

          
Agree. Remove this for the initial list

          

          

            

              

                

                  

                    


                    

                    

                    

                      
     - path-state
                        propagation (NAT/FW)

                      

                    

                    


                    

                    
As with security, not sure how much of this /
                      in which form we'd want to expose, and so I'd feel
                      better if it were removed.

                  

                

              

            

          

          


          

          
Agree. Remove this for the initial list

          

          

            

              

                

                  

                    


                    

                    

                    

                      
I don't know if this list
                        is correct or complete. This should be the WG

                        job to compile it.

                        Btw, adding this list to the charter, as a
                        starting point, would make

                        sense.

                      

                    

                    


                    

                    
So, to summarize, here's the complete list that
                      I suggest:

                    


                    

                    
- sequence preservation

                    
- various degrees of reliability

                    
- low delay vs. high throughput

                  

                

              

            

          

          


          

          
I’d rephrase this as:

          


          

          
- ordering/sequence preservation

          
- degree of reliability 

          
- latency vs throughput

          

        

      

    

    

    All good updates I think. 

    

    

      

        

          

            

              

                

                  

                    


                    

                    
Yes it's short, but for a list of examples,
                      that could be ok?

                    


                    

                    

                    

                      
I'm an application
                        designer, I care for a transport that will
                        provide

                        me:

                            - message atomicity

                            - head-of-line blocking avoidance

                            - sub-channels

                            - full reliability

                            - loss-sensitive congestion control

                      

                    

                    


                    

                    
Wouldn't you rather say:

                    
- high throughput (don't care so much about low
                      delay)

                    
- full reliability

                    
- sequence preservation doesn't matter to me

                    
... and have a system underneath automatically
                      gives you head-of-line blocking avoidance and uses
                      loss-sensitive congestion control?

                    
(Ideally, that system would also use
                      sub-channels if they do improve performance, and
                      provides message atomicity only if this is a
                      benefit, i.e. only if there is significant loss)

                    


                    

                    

                    

                      
How do we call those 5
                        things? criteria?

                      

                    

                    


                    

                    
A mess?

                  

                

              

            

          

          


          

          
If TAPS is ever to be successful we have to get and keep
            the application developers on side. So I would say that
            application designers might have a list of desired outcomes
            for their application and TAPS is about marrying that up
            with the underlying services that lead to those outcomes

          


          

          

            

              

                

                  

                    


                    

                    


                    

                    

                      
How do we call the
                        transport that support those 5 things? a
                        transport

                        protocol? a transport service?

                        The "services" term is used multiple times
                        within the charter.

                        Sometimes I understand it as a "transport
                        protocol" (like in the first

                        sentence in the charter),

                        And sometimes I may interpret it as Brian's
                        "dimensions of transport" or

                        criteria.

                        

                        Potentially use "criteria" and "transport
                        protocol"

                        Alternatively, only use "transport services"
                        when it means "criteria, and

                        "transport protocol".

                        I tried to do the latter below.

                        

                        

                      

                    

                    


                    

                    Again, detailed comments in line:

                  


                  

                  


                    

                      
OLD:

                        

                        Conjointly, transport protocols such as SCTP,
                        DCCP, MPTCP,

                        UDP-Lite and the LEDBAT congestion control
                        mechanism extend

                        the set of transport services that are available
                        to

                        applications, beyond those provided by TCP and
                        UDP. For

                        example, SCTP provides potentially faster
                        reliable delivery

                        for applications that can accept blocks of data
                        out of order,

                        and LEDBAT provides low-priority "scavenger"
                        communication.

                        

                        NEW:

                        Conjointly, transport protocols such as SCTP,
                        DCCP, MPTCP,

                        UDP-Lite and the LEDBAT congestion control
                        mechanism extend

                        the set of transport protocols that are
                        available to

                        applications, beyond those provided by TCP and
                        UDP. For

                        example, SCTP provides potentially faster
                        reliable delivery

                        for applications that can accept blocks of data
                        out of order,

                        and LEDBAT provides low-priority "scavenger"
                        communication.

                      

                    

                    


                    

                    Disagree, I'd rather leave it as it is to stress
                    that applications use services, not protocols.

                

              

            

          

          


          

          


          

          
I actually think changing that to protocols might be a
            good thing, since it highlights how complex the landscape
            has become. 

          

        

      

    

    

    I disagree. I agree with Michael here that we shoud stress that
    applications use services, not protocols. Also the examples talk
    about services not protocols so the proposed new wording is strange
    to me.

    

    

      

        


          

            

              

                

                  


                  

                  


                    

                      
OLD:

                        

                        - Identify services provided by existing IETF
                        transport protocols

                          and congestion control mechanisms. The
                        resulting document will

                          provide guidance on making a choice among
                        available mechanisms

                          and protocols to obtain a certain transport
                        service.

                        

                        

                        NEW:

                        

                        - Identify transport services provided by
                        existing IETF transport

                        protocols

                          and congestion control mechanisms. The
                        resulting document will

                          provide guidance on making a choice among
                        available mechanisms

                          and protocols to obtain a certain transport
                        service. As a starting

                        point

                          for transport services, the working group can
                        consider: message

                        atomicity,

                          stream fragmentation, sequence preservation,
                        head-of-line blocking

                        avoidance,

                          sub-channels, full reliability,
                        latency-limited reliability,

                        loss-sensitive

                          congestion control, delay-sensitive congestion
                        control, endpoint

                        address agility,

                          privacy and integrity, and path-state
                        propagation (NAT/Firewall).

                      

                    

                    


                    

                    
Sentence 1: "transport services provided by ..
                       transport protocols" doesn't seem to make things
                      clearer. I'd rather keep "services" in this
                      sentence - what this means gets concrete anyway
                      due to the list that follows in sentence 3, and
                      there the phrase "transport services" is used
                      anyway. The list should be changed, as I argued
                      above. I suggest:

                    


                    

                    
NEW:

                    


                    

                    
- Identify services provided by existing IETF
                      transport protocols

                        and congestion control mechanisms. The resulting
                      document will

                        provide guidance on making a choice among
                      available mechanisms

                        and protocols to obtain a certain transport
                      service. As a starting point

                    
  for transport services, the working group can
                      consider: sequence

                    
  preservation, various degrees of reliability,
                      low delay vs. high throughput.

                  

                

              

            

          

          


          

          
I think here we’re once again running into the difficulty
            of the ambiguity of the word “transport”, especially in the
            IETF… If we have defined Transport Services in terms of the
            transport protocol earlier in the document, can we actually
            phrase this

          


          

          
- Identify Transport Services provided by IETF protocols
            and congestion control mechanisms

          


          

          

          

            

              

                

                  

                    


                    

                    


                    

                    

                    

                      
OLD:

                        

                        - Specify a subset of those services identified
                        in item 1, which

                          end systems supporting TAPS need to provide
                        and provide guidance

                          on choosing among available mechanisms and
                        protocols to obtain

                          a given transport service.

                        

                        NEW:

                        - Specify a subset of those transport services
                        identified in item 1,

                        which

                          end systems supporting TAPS need to provide
                        and provide guidance

                          on choosing among available mechanisms and
                        protocols.

                      

                    

                    


                    

                    
Agreed.

                  

                

              

            

          

          


          

          
agree as well

          

          

            

              

                

                  
 

                  


                  

                  


                    

                      
OLD:

                        - Specify experimental mechanisms to deliver a
                        transport service.

                          This will explain how to select and engage a
                        protocol, and how

                          to discover the availability of protocols on
                        an interface (both

                          end system and path support), in order to
                        provide a basis for

                          incremental deployment.

                        

                        NEW:

                        - Specify experimental mechanisms to deliver a
                        transport protocol.

                          This will explain how to select and engage a
                        protocol, and how

                          to discover the availability of protocol
                        services on an interface (both

                        

                          end system and path support), in order to
                        provide a basis for

                          incremental deployment.

                      

                    

                    


                    

                    


                    

                    Disagree. "deliver a transport protocol" is weird.
                    The intention was to say "provide a transport
                    service", maybe "deliver" is a bad choice of words
                    here? So I suggest:

                  


                  

                  
NEW:

                    - Specify experimental mechanisms to provide a
                    transport service.

                      This will explain how to select and engage a
                    protocol, and how

                      to discover the availability of protocols on an
                    interface (both

                      end system and path support), in order to provide
                    a basis for

                      incremental deployment.

                

              

            

          

          


          

          
Specify experimental mechanisms to provide a given
            Transport Service. 

          
This will explain how to select and engage an appropriate
            protocol and 

          
how to discover which protocols are available for a given
            connection. 

          
This will provide a basis for incremental deployment.

          


          

        

      

    

    

      

        


          

            

              

                

                  


                  

                  


                    

                      
2.

                        

                        - Specify experimental mechanisms to deliver a
                        transport service.

                          This will explain how to select and engage a
                        protocol, and how

                          to discover the availability of protocols on
                        an interface (both

                          end system and path support), in order to
                        provide a basis for

                          incremental deployment.

                        

                        I don't understand what "deliver" mean in the
                        first sentence.

                      

                    

                    


                    

                    - hence I replaced it with "provide" above.

                  


                  

                  


                    

                      
3.

                        It seems that there are multiple problem
                        statements, with two different

                        solution tracks: one for existing transport
                        protocols, another one for

                        new transport protocols.

                        Both rely on the identifying the transport
                        services/criteria, which is

                        good.

                        - existing transport protocols: as you wrote
                        "different protocols can

                        provide the same services in different ways"

                        - existing transport protocols: how do we know
                        if endpoints and the path

                        support those?

                        - new transport protocol development (I got this
                        from my discussion with

                        Brian, true it's not really mentioned in the
                        charter)

                        

                        In your paragraph to which problem statement
                        "this problem" refers to?

                        

                            There are many ways in which this problem
                        could be addressed;

                            while it may not yet be clear what the best
                        way forward could

                            be, any approach to provide a richer set of
                        transport services

                            to applications will have to begin with the
                        identification of

                            the services that current transport
                        protocols provide.

                        

                        Depending on what "this problem" refers to, the
                        solution might be

                             new transport middle layer

                             API services discovery

                            OAM services discovery

                            etc.

                        

                        Discussing with Spencer, it means: "which
                        transport building blocks work

                        for me".

                      

                    

                    


                    

                    
This block above has me a bit confused, I think
                      I lack context, so I won't comment on it.

                  

                

              

            

          

          


          

          
addressed above

          

          

            

              

                

                  

                    


                    

                    

                    

                      
So this paragraph should
                        be rephrased.

                        Possible solution

                        

                        OLD:

                        

                            There are many ways in which this problem
                        could be addressed;

                            while it may not yet be clear what the best
                        way forward could

                            be, any approach to provide a richer set of
                        transport services

                            to applications will have to begin with the
                        identification of

                            the services that current transport
                        protocols provide.

                        

                        NEW (this paragraph would make more sense after
                        the 3 bullet points "the

                        Working Group will")

                        

                            The Working Group deliverables will help an
                        application

                            programmer identify the important transport
                        services for his

                            application and determine if those transport
                        services are available

                      

                    

                  

                

              

            

          

          


          

          

          

            

              

                

                  

                    

                      
     on the end points and
                        along the path in the network. An approach to

                            provide a richer set of transport services
                        to applications (which

                            could be part of a future charter) has to
                        begin with the

                        identification of

                            the services that current transport
                        protocols provide.

                      

                    

                    


                    

                    
Agreed; I like this change a lot, it's much
                      more concrete and reflects our intention IMO.

                  

                

              

            

          

          


          

          
Yes. Agreed

          

          

            

              

                

                  

                    


                    

                    

                    

                      
----------------------------------------------------------------------

                        COMMENT:

----------------------------------------------------------------------

                        

                         "The Working Group will coordinate closely with
                        other Working Groups and

                        IRTF Research Groups."

                        You should list the WGs you have in mind.

                      

                    

                    


                    

                    
I agree that it looks odd as it stands. I'm not
                      sure what the right approach is here (simply
                      remove? or what are these groups?) - e.g. Spencer
                      would know better than me…

                  

                

              

            

          

          


          

          


          

          
I think the key thing here was that we aren’t only
            limiting ourselves to working with the IETF but are also
            interested in getting input from the IRTF. However I think
            we can drop this

          

          

            

              

                

                  

                    


                    

                    
Cheers,

                    
Michael

                    


                    

                  

                

              

              

            

            _______________________________________________

            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


    

    

  


--------------050209070607080307010202--



From nobody Fri Jun 27 07:56:37 2014
Return-Path: 
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28B91B31BF for ; Fri, 27 Jun 2014 07:56:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 Muh6-KN3uOyP for ; Fri, 27 Jun 2014 07:56:29 -0700 (PDT)
Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A3B1B2DE1 for ; Fri, 27 Jun 2014 07:56:19 -0700 (PDT)
X-Spam-Processed: mail.kau.se, Fri, 27 Jun 2014 16:56:01 +0200 (not processed: spam filter heuristic analysis disabled)
X-Authenticated-Sender: annabrun@kau.se
X-MDRemoteIP: 193.11.156.68
X-Return-Path: anna.brunstrom@kau.se
X-Envelope-From: anna.brunstrom@kau.se
X-MDaemon-Deliver-To: taps@ietf.org
Message-ID: <53AD8609.9070503@kau.se>
Date: Fri, 27 Jun 2014 16:56:09 +0200
From: Anna Brunstrom 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: taps@ietf.org
References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACAFDA.3060303@gmail.com> <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> <53AD74D8.9010906@gmail.com>  <87928669-2007-4F11-900E-1AD7030F08DD@ifi.uio.no>
In-Reply-To: <87928669-2007-4F11-900E-1AD7030F08DD@ifi.uio.no>
Content-Type: multipart/alternative; boundary="------------090408070108040906040208"
Archived-At: http://mailarchive.ietf.org/arch/msg/taps/Sgj09Y1_jxAyvWrSI0TYISn3Rfs
Subject: Re: [Taps] Stream vs. packet
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 14:56:32 -0000

This is a multi-part message in MIME format.
--------------090408070108040906040208
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

As this is now in a new thread I add my point from the very long mail.

Preserving message boundaries is a useful service so I think this could 
be a good example of a service. I guess that was what Brian was after. 
Some possible names: Message preservation, message framing, preserving 
message boundaries?

Anna

On 2014-06-27 16:45, Michael Welzl wrote:
> Hi,
>
> I changed the subject because this is not about the chartering 
> discussion anymore - it's beginning our work   :-)
>
>
> Toby, in his last email, raised the following question:
>
> On 27. juni 2014, at 16:21, Toby Moncaster 
> > wrote:
>
> [snip]
>
>
>>>>>>     - message atomicity
>>>>
>>>> What's that? That multiple messages are not combined into one 
>>>> packet? This plays a role for an application only when there is 
>>>> significant loss (I think). Wouldn't it be nice to have a system 
>>>> that provides atomicity only when needed and otherwise saves header 
>>>> overhead? I would vote against exposing that. Either way, I vote it 
>>>> off the list that goes in the charter, it's not an obvious service 
>>>> to me.
>>
>> To some extent I agree here. But is there any way we can correctly 
>> express the differences between stream and packet oriented transports?
>
> Can we try to make a simple decision here, as a group, to never even 
> really consider streams at all?
>
> It seems to me to be straightforward to provide a stream-based 
> transport over a message-based transport, so this is something that 
> can simply always be done. Thus, can we just write a disclaimer in one 
> of our documents, recommending that any TAPS-supporting systems can 
> provide stream-based transport on top of the message based transport 
> too, but that its users must be aware of limitations that arise from 
> streams (such as HOL blocking delay, no ALF, ..)?
>
> Cheers,
> Michael
>
>
>
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps


--------------090408070108040906040208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi,

    

    As this is now in a new thread I add my point from the very long
    mail.

    

    Preserving message boundaries is a useful service so I think this
    could be a good example of a service. I guess that was what Brian
    was after. Some possible names: Message preservation, message
    framing, preserving message boundaries?

    

    Anna

    

    
On 2014-06-27 16:45, Michael Welzl
      wrote:

    

    

      
      Hi,
      


      

      
I changed the subject because this is not about the
        chartering discussion anymore - it's beginning our work   :-)

      


      

      


      

      
Toby, in his last email, raised the following question:

      


        

          
On 27. juni 2014, at 16:21, Toby Moncaster <toby.moncaster@cl.cam.ac.uk>
            wrote:

          


          

          [snip]

        


        

        


          

            

              

                

                  

                    

                      

                        

                          

                            
    - message
                              atomicity

                            

                          

                          


                          

                          
What's that? That multiple messages are
                            not combined into one packet? This plays a
                            role for an application only when there is
                            significant loss (I think). Wouldn't it be
                            nice to have a system that provides
                            atomicity only when needed and otherwise
                            saves header overhead? I would vote against
                            exposing that. Either way, I vote it off the
                            list that goes in the charter, it's not an
                            obvious service to me.

                        

                      

                    

                  

                  


                  

                  
To some extent I agree here. But is there any way
                    we can correctly express the differences between
                    stream and packet oriented transports?

                

              

            

          

          


          

          
Can we try to make a simple decision here, as a group, to
            never even really consider streams at all?

          


          

          
It seems to me to be straightforward to provide a
            stream-based transport over a message-based transport, so
            this is something that can simply always be done. Thus, can
            we just write a disclaimer in one of our documents,
            recommending that any TAPS-supporting systems can provide
            stream-based transport on top of the message based transport
            too, but that its users must be aware of limitations that
            arise from streams (such as HOL blocking delay, no ALF, ..)?

          


          

          
Cheers,

          
Michael

          


          

        

      

      

      

      

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


    

    

  


--------------090408070108040906040208--


From nobody Fri Jun 27 08:08:05 2014
Return-Path: 
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D8D1B3231 for ; Fri, 27 Jun 2014 08:07:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 JjE7DdqijC6D for ; Fri, 27 Jun 2014 08:07:49 -0700 (PDT)
Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F29691B3230 for ; Fri, 27 Jun 2014 08:07:48 -0700 (PDT)
X-Spam-Processed: mail.kau.se, Fri, 27 Jun 2014 17:07:36 +0200 (not processed: spam filter heuristic analysis disabled)
X-Authenticated-Sender: annabrun@kau.se
X-MDRemoteIP: 193.11.156.68
X-Return-Path: anna.brunstrom@kau.se
X-Envelope-From: anna.brunstrom@kau.se
Message-ID: <53AD88BD.6090003@kau.se>
Date: Fri, 27 Jun 2014 17:07:41 +0200
From: Anna Brunstrom 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: taps@ietf.org
References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACAFDA.3060303@gmail.com> <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> <53AD74D8.9010906@gmail.com>  <33966B16-D15B-49E5-BEBD-C8DE990F8028@ifi.uio.no>
In-Reply-To: <33966B16-D15B-49E5-BEBD-C8DE990F8028@ifi.uio.no>
Content-Type: multipart/alternative; boundary="------------080802010507050603090100"
Archived-At: http://mailarchive.ietf.org/arch/msg/taps/WxTqXB57odXqNaZAuv1aR7Iu8Ck
Cc: bclaise@cisco.com, spencerdawkins.ietf@gmail.com
Subject: Re: [Taps] Charter bikeshed #1 - "transport service"
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 15:07:57 -0000

This is a multi-part message in MIME format.
--------------080802010507050603090100
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Repeating one of my comments on the long mail to this more manageable 
version that Micheal produced while I was reading.

Anna

On 2014-06-27 16:38, Michael Welzl wrote:
> Hi,
>
> I'll cut away a lot now, and only address things that need addressing 
> below:
>
>
> On 27. juni 2014, at 16:21, Toby Moncaster 
> > wrote:
>
> [snip]
>
>> I agree with Michael here. I think we could end up with a much less 
>> clearly worded charter if we go down that route. If there is a need 
>> to be more precise then I'd favour adding something near the 
>> beginning of the charter along the lines of the definition I put in 
>> the Problem Statement document. Namely:  "A Transport Service is any 
>> service provided by the transport layer that can only be correctly 
>> implemented with information from the application."We could then 
>> include 2 or 3 example services
>
> I agree. Putting that definition in there would be nice.
>
>
>>>>>>     - full reliability
>>>>>>     - latency-limited reliability
>>>>>
>>>> Yes, reliability is a service, and fine to include in the list. But 
>>>> I'd rather replace this with any of:
>>>> "various degrees of reliability" or "various forms of reliability" 
>>>> or "full / latency-limited / no reliability"
>>>> ...or something like that.  One item, not two, anyway.
>>
>>
>> Hmmm. I'd rather we had something like "Degree of reliability from 
>> unreliable to full reliability."
>
> Agree.
>
>
>>>> Second, using the phrase "congestion control" binds the application 
>>>> requirement to a specific mechanism. I'd rather use something like 
>>>> "low delay vs. high throughput".
>>
>> Perhaps this would best be expressed as "Trading off latency and 
>> throughput"
>
> Agree.
>
>
>>>>>> I don't know if this list is correct or complete. This should be 
>>>>>> the WG
>>>>>> job to compile it.
>>>>>> Btw, adding this list to the charter, as a starting point, would make
>>>>>> sense.
>>>>
>>>> So, to summarize, here's the complete list that I suggest:
>>>>
>>>> - sequence preservation
>>>> - various degrees of reliability
>>>> - low delay vs. high throughput
>>
>> I'd rephrase this as:
>>
>> - ordering/sequence preservation
>> - degree of reliability
>> - latency vs throughput
>
> Agree, this is nicer!
>
>
>>>>>> How do we call the transport that support those 5 things? a transport
>>>>>> protocol? a transport service?
>>>>>> The "services" term is used multiple times within the charter.
>>>>>> Sometimes I understand it as a "transport protocol" (like in the 
>>>>>> first
>>>>>> sentence in the charter),
>>>>>> And sometimes I may interpret it as Brian's "dimensions of 
>>>>>> transport" or
>>>>>> criteria.
>>>>>>
>>>>>> Potentially use "criteria" and "transport protocol"
>>>>>> Alternatively, only use "transport services" when it means 
>>>>>> "criteria, and
>>>>>> "transport protocol".
>>>>>> I tried to do the latter below.
>>>>>>
>>>>>>
>>>>
>>>> Again, detailed comments in line:
>>>>
>>>>
>>>>>> OLD:
>>>>>>
>>>>>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
>>>>>> UDP-Lite and the LEDBAT congestion control mechanism extend
>>>>>> the set of transport services that are available to
>>>>>> applications, beyond those provided by TCP and UDP. For
>>>>>> example, SCTP provides potentially faster reliable delivery
>>>>>> for applications that can accept blocks of data out of order,
>>>>>> and LEDBAT provides low-priority "scavenger" communication.
>>>>>>
>>>>>> NEW:
>>>>>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
>>>>>> UDP-Lite and the LEDBAT congestion control mechanism extend
>>>>>> the set of transport protocols that are available to
>>>>>> applications, beyond those provided by TCP and UDP. For
>>>>>> example, SCTP provides potentially faster reliable delivery
>>>>>> for applications that can accept blocks of data out of order,
>>>>>> and LEDBAT provides low-priority "scavenger" communication.
>>>>
>>>> Disagree, I'd rather leave it as it is to stress that applications 
>>>> use services, not protocols.
>>
>>
>> I actually think changing that to protocols might be a good thing, 
>> since it highlights how complex the landscape has become.
>

I disagree. The "For example" list gets very strange as examples of 
transport protocols. I also agree with Michael's original objection: 
stressing that applications use services is important.



> Okay, fine by me. I don't have a strong opinion here either way.
>
>
>>>>>> OLD:
>>>>>>
>>>>>> - Identify services provided by existing IETF transport protocols
>>>>>>   and congestion control mechanisms. The resulting document will
>>>>>>   provide guidance on making a choice among available mechanisms
>>>>>>   and protocols to obtain a certain transport service.
>>>>>>
>>>>>>
>>>>>> NEW:
>>>>>>
>>>>>> - Identify transport services provided by existing IETF transport
>>>>>> protocols
>>>>>>   and congestion control mechanisms. The resulting document will
>>>>>>   provide guidance on making a choice among available mechanisms
>>>>>>   and protocols to obtain a certain transport service. As a starting
>>>>>> point
>>>>>>   for transport services, the working group can consider: message
>>>>>> atomicity,
>>>>>>   stream fragmentation, sequence preservation, head-of-line blocking
>>>>>> avoidance,
>>>>>>   sub-channels, full reliability, latency-limited reliability,
>>>>>> loss-sensitive
>>>>>>   congestion control, delay-sensitive congestion control, endpoint
>>>>>> address agility,
>>>>>>   privacy and integrity, and path-state propagation (NAT/Firewall).
>>>>
>>>> Sentence 1: "transport services provided by ..  transport 
>>>> protocols" doesn't seem to make things clearer. I'd rather keep 
>>>> "services" in this sentence - what this means gets concrete anyway 
>>>> due to the list that follows in sentence 3, and there the phrase 
>>>> "transport services" is used anyway. The list should be changed, as 
>>>> I argued above. I suggest:
>>>>
>>>> NEW:
>>>>
>>>> - Identify services provided by existing IETF transport protocols
>>>>   and congestion control mechanisms. The resulting document will
>>>>   provide guidance on making a choice among available mechanisms
>>>>   and protocols to obtain a certain transport service. As a 
>>>> starting point
>>>>   for transport services, the working group can consider: sequence
>>>>   preservation, various degrees of reliability, low delay vs. high 
>>>> throughput.
>>
>> I think here we're once again running into the difficulty of the 
>> ambiguity of the word "transport", especially in the IETF... If we 
>> have defined Transport Services in terms of the transport protocol 
>> earlier in the document, can we actually phrase this
>>
>> - Identify Transport Services provided by IETF protocols and 
>> congestion control mechanisms
>
> Agreed
>
>
>>>>>> OLD:
>>>>>> - Specify experimental mechanisms to deliver a transport service.
>>>>>>   This will explain how to select and engage a protocol, and how
>>>>>>   to discover the availability of protocols on an interface (both
>>>>>>   end system and path support), in order to provide a basis for
>>>>>>   incremental deployment.
>>>>>>
>>>>>> NEW:
>>>>>> - Specify experimental mechanisms to deliver a transport protocol.
>>>>>>   This will explain how to select and engage a protocol, and how
>>>>>>   to discover the availability of protocol services on an 
>>>>>> interface (both
>>>>>>
>>>>>>   end system and path support), in order to provide a basis for
>>>>>>   incremental deployment.
>>>>
>>>>
>>>> Disagree. "deliver a transport protocol" is weird. The intention 
>>>> was to say "provide a transport service", maybe "deliver" is a bad 
>>>> choice of words here? So I suggest:
>>>>
>>>> NEW:
>>>> - Specify experimental mechanisms to provide a transport service.
>>>>   This will explain how to select and engage a protocol, and how
>>>>   to discover the availability of protocols on an interface (both
>>>>   end system and path support), in order to provide a basis for
>>>>   incremental deployment.
>>
>> Specify experimental mechanisms to provide a given Transport Service.
>> This will explain how to select and engage an appropriate protocol and
>> how to discover which protocols are available for a given connection.
>> This will provide a basis for incremental deployment.
>
> Agreed.
>
>
>>>>>>  "The Working Group will coordinate closely with other Working 
>>>>>> Groups and
>>>>>> IRTF Research Groups."
>>>>>> You should list the WGs you have in mind.
>>>>
>>>> I agree that it looks odd as it stands. I'm not sure what the right 
>>>> approach is here (simply remove? or what are these groups?) - e.g. 
>>>> Spencer would know better than me...
>>
>>
>> I think the key thing here was that we aren't only limiting ourselves 
>> to working with the IETF but are also interested in getting input 
>> from the IRTF. However I think we can drop this
>
> Agreed.
>
> Cheers,
> Michael
>
>
>
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps


--------------080802010507050603090100
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi,

    

    Repeating one of my comments on the long mail to this more
    manageable version that Micheal produced while I was reading.

    

    Anna 

    

    On 2014-06-27 16:38, Michael Welzl wrote:

    

      
      
Hi,

      


      

      
I'll cut away a lot now, and only address things that need
        addressing below:

      


      

      


      

      

        

          
On 27. juni 2014, at 16:21, Toby Moncaster <toby.moncaster@cl.cam.ac.uk>
            wrote:

          


          

          [snip]

        


        

        

          

            
I agree with
              Michael here. I think we could end up with a much less
              clearly worded charter if we go down that route. If there
              is a need to be more precise then I’d favour adding
              something near the beginning of the charter along the
              lines of the definition I put in the Problem Statement
              document. Namely:  "A
                Transport Service is any service provided by the
                transport layer that can only be correctly implemented
                with information from the application.”We could then
                include 2 or 3 example services 

          

          

            


              

          

          
I agree. Putting that
              definition in there would be nice.

          


            

        

        


        

        

          

            

              

                

                  

                    

                      

                        

                          
    - full reliability

                          

                        

                        

                          

                            
    -
                              latency-limited reliability

                            

                          

                          

                            


                            

                          

                        

                        
Yes, reliability is a service, and fine to
                          include in the list. But I'd rather replace
                          this with any of:

                        
"various degrees of reliability" or
                          "various forms of reliability" or "full /
                          latency-limited / no reliability"

                        
...or something like that.  One item, not
                          two, anyway.

                      

                    

                  

                  


                  

                  


                  

                  
Hmmm. I’d rather we had something like “Degree of
                    reliability from unreliable to full reliability."

                

              

            

          

          


          

          Agree.

        


        

        


        

        

          

            

              

                

                  

                    

                      

                        
Second, using the phrase "congestion
                          control" binds the application requirement to
                          a specific mechanism. I'd rather use something
                          like "low delay vs. high throughput”.

                      

                    

                  

                  


                  

                  
Perhaps this would best be expressed as “Trading
                    off latency and throughput"

                

              

            

          

          


          

          
Agree.

          


          

          

          

            

              

                

                  

                    

                      

                        

                          
I don't know if this
                            list is correct or complete. This should be
                            the WG

                            job to compile it.

                            Btw, adding this list to the charter, as a
                            starting point, would make

                            sense.

                          

                        

                        


                        

                        
So, to summarize, here's the complete list
                          that I suggest:

                        


                        

                        
- sequence preservation

                        
- various degrees of reliability

                        
- low delay vs. high throughput

                      

                    

                  

                  


                  

                  
I’d rephrase this as:

                  


                  

                  
- ordering/sequence preservation

                  
- degree of reliability 

                  
- latency vs throughput

                

              

            

          

          


          

          Agree, this is nicer!

        


        

        


        

        

          

            

              

                

                  

                    

                      

                        
How do we call the
                          transport that support those 5 things? a
                          transport

                          protocol? a transport service?

                          The "services" term is used multiple times
                          within the charter.

                          Sometimes I understand it as a "transport
                          protocol" (like in the first

                          sentence in the charter),

                          And sometimes I may interpret it as Brian's
                          "dimensions of transport" or

                          criteria.

                          

                          Potentially use "criteria" and "transport
                          protocol"

                          Alternatively, only use "transport services"
                          when it means "criteria, and

                          "transport protocol".

                          I tried to do the latter below.

                          

                          

                        

                      

                      


                      

                      Again, detailed comments in line:

                    


                    

                    


                      

                        
OLD:

                          

                          Conjointly, transport protocols such as SCTP,
                          DCCP, MPTCP,

                          UDP-Lite and the LEDBAT congestion control
                          mechanism extend

                          the set of transport services that are
                          available to

                          applications, beyond those provided by TCP and
                          UDP. For

                          example, SCTP provides potentially faster
                          reliable delivery

                          for applications that can accept blocks of
                          data out of order,

                          and LEDBAT provides low-priority "scavenger"
                          communication.

                          

                          NEW:

                          Conjointly, transport protocols such as SCTP,
                          DCCP, MPTCP,

                          UDP-Lite and the LEDBAT congestion control
                          mechanism extend

                          the set of transport protocols that are
                          available to

                          applications, beyond those provided by TCP and
                          UDP. For

                          example, SCTP provides potentially faster
                          reliable delivery

                          for applications that can accept blocks of
                          data out of order,

                          and LEDBAT provides low-priority "scavenger"
                          communication.

                        

                      

                      


                      

                      Disagree, I'd rather leave it as it is to stress
                      that applications use services, not protocols.

                  

                

              

              


              

              


              

              
I actually think changing that to protocols might be
                a good thing, since it highlights how complex the
                landscape has become. 

            

          

          


          

        

      

    

    

    I disagree. The "For example" list gets very strange as examples of
    transport protocols. I also agree with Michael's original objection:
    stressing that applications use services is important.

    

    

    

    

      

        

          
Okay, fine by me. I don't have a strong opinion here
            either way.

        

      

    

    

      

        

          


          

          

          

            

              

                

                  

                    

                      

                        
OLD:

                          

                          - Identify services provided by existing IETF
                          transport protocols

                            and congestion control mechanisms. The
                          resulting document will

                            provide guidance on making a choice among
                          available mechanisms

                            and protocols to obtain a certain transport
                          service.

                          

                          

                          NEW:

                          

                          - Identify transport services provided by
                          existing IETF transport

                          protocols

                            and congestion control mechanisms. The
                          resulting document will

                            provide guidance on making a choice among
                          available mechanisms

                            and protocols to obtain a certain transport
                          service. As a starting

                          point

                            for transport services, the working group
                          can consider: message

                          atomicity,

                            stream fragmentation, sequence preservation,
                          head-of-line blocking

                          avoidance,

                            sub-channels, full reliability,
                          latency-limited reliability,

                          loss-sensitive

                            congestion control, delay-sensitive
                          congestion control, endpoint

                          address agility,

                            privacy and integrity, and path-state
                          propagation (NAT/Firewall).

                        

                      

                      


                      

                      
Sentence 1: "transport services provided by
                        ..  transport protocols" doesn't seem to make
                        things clearer. I'd rather keep "services" in
                        this sentence - what this means gets concrete
                        anyway due to the list that follows in sentence
                        3, and there the phrase "transport services" is
                        used anyway. The list should be changed, as I
                        argued above. I suggest:

                      


                      

                      
NEW:

                      


                      

                      
- Identify services provided by existing IETF
                        transport protocols

                          and congestion control mechanisms. The
                        resulting document will

                          provide guidance on making a choice among
                        available mechanisms

                          and protocols to obtain a certain transport
                        service. As a starting point

                      
  for transport services, the working group
                        can consider: sequence

                      
  preservation, various degrees of
                        reliability, low delay vs. high throughput.

                    

                  

                

              

              


              

              
I think here we’re once again running into the
                difficulty of the ambiguity of the word “transport”,
                especially in the IETF… If we have defined Transport
                Services in terms of the transport protocol earlier in
                the document, can we actually phrase this

              


              

              
- Identify Transport Services provided by IETF
                protocols and congestion control mechanisms

            

          

          


          

          Agreed

        


        

        


          

            

              

                

                  

                    

                      

                        
OLD:

                          - Specify experimental mechanisms to deliver a
                          transport service.

                            This will explain how to select and engage a
                          protocol, and how

                            to discover the availability of protocols on
                          an interface (both

                            end system and path support), in order to
                          provide a basis for

                            incremental deployment.

                          

                          NEW:

                          - Specify experimental mechanisms to deliver a
                          transport protocol.

                            This will explain how to select and engage a
                          protocol, and how

                            to discover the availability of protocol
                          services on an interface (both

                          

                            end system and path support), in order to
                          provide a basis for

                            incremental deployment.

                        

                      

                      


                      

                      


                      

                      Disagree. "deliver a transport protocol" is weird.
                      The intention was to say "provide a transport
                      service", maybe "deliver" is a bad choice of words
                      here? So I suggest:

                    


                    

                    
NEW:

                      - Specify experimental mechanisms to provide a
                      transport service.

                        This will explain how to select and engage a
                      protocol, and how

                        to discover the availability of protocols on an
                      interface (both

                        end system and path support), in order to
                      provide a basis for

                        incremental deployment.

                  

                

              

              


              

              
Specify experimental mechanisms to provide a given
                Transport Service. 

              
This will explain how to select and engage an
                appropriate protocol and 

              
how to discover which protocols are available for a
                given connection. 

              
This will provide a basis for incremental deployment.

            

          

          


          

          
Agreed.

          


          

          


          

          

            

              

                

                  

                    

                      
 "The Working Group will
                        coordinate closely with other Working Groups and

                        IRTF Research Groups."

                        You should list the WGs you have in mind.

                      

                    

                    


                    

                    
I agree that it looks odd as it stands. I'm not
                      sure what the right approach is here (simply
                      remove? or what are these groups?) - e.g. Spencer
                      would know better than me…

                  

                

              

              


              

              


              

              
I think the key thing here was that we aren’t only
                limiting ourselves to working with the IETF but are also
                interested in getting input from the IRTF. However I
                think we can drop this

            

          

          


          

          Agreed.

        


        

        
Cheers,

        
Michael

        


        

      

      

      

      

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


    

    

  


--------------080802010507050603090100--


From nobody Fri Jun 27 10:53:42 2014
Return-Path: 
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C20F1A03B4 for ; Fri, 27 Jun 2014 10:53:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 lF1_qcgB4gnk for ; Fri, 27 Jun 2014 10:53:39 -0700 (PDT)
Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 776621A0054 for ; Fri, 27 Jun 2014 10:53:39 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s5RHrMwK012651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 27 Jun 2014 10:53:22 -0700 (PDT)
Message-ID: <53ADAF92.4040404@isi.edu>
Date: Fri, 27 Jun 2014 10:53:22 -0700
From: Joe Touch 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Anna Brunstrom , taps@ietf.org
References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACAFDA.3060303@gmail.com> <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> <53AD74D8.9010906@gmail.com>  <87928669-2007-4F11-900E-1AD7030F08DD@ifi.uio.no> <53AD8609.9070503@kau.se>
In-Reply-To: <53AD8609.9070503@kau.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/taps/qeBZ0Z8gMyvfAJxDgZfdTOxTjzw
Subject: Re: [Taps] Stream vs. packet
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Jun 2014 17:53:41 -0000

On 6/27/2014 7:56 AM, Anna Brunstrom wrote:
> Hi,
>
> As this is now in a new thread I add my point from the very long mail.
>
> Preserving message boundaries is a useful service so I think this could
> be a good example of a service. I guess that was what Brian was after.
> Some possible names: Message preservation, message framing, preserving
> message boundaries?

FWIW, I don't understand "preserving message boundaries" as a service.

Being a service means defining the information exchange - either it's a 
single, ordered stream of bytes or it's a set of messages.

I don't know if there's utility in defining another type which is "a 
continuous stream of bytes with separator boundaries", but AFAICT that 
mechanism is an artifact of using a bytestream to implement a message 
service - and IMO ought to be invisible to the service 'consumer'.

Joe

>
> Anna
>
> On 2014-06-27 16:45, Michael Welzl wrote:
>> Hi,
>>
>> I changed the subject because this is not about the chartering
>> discussion anymore - it's beginning our work   :-)
>>
>>
>> Toby, in his last email, raised the following question:
>>
>> On 27. juni 2014, at 16:21, Toby Moncaster
>> > wrote:
>>
>> [snip]
>>
>>
>>>>>>>     - message atomicity
>>>>>
>>>>> What's that? That multiple messages are not combined into one
>>>>> packet? This plays a role for an application only when there is
>>>>> significant loss (I think). Wouldn't it be nice to have a system
>>>>> that provides atomicity only when needed and otherwise saves header
>>>>> overhead? I would vote against exposing that. Either way, I vote it
>>>>> off the list that goes in the charter, it's not an obvious service
>>>>> to me.
>>>
>>> To some extent I agree here. But is there any way we can correctly
>>> express the differences between stream and packet oriented transports?
>>
>> Can we try to make a simple decision here, as a group, to never even
>> really consider streams at all?
>>
>> It seems to me to be straightforward to provide a stream-based
>> transport over a message-based transport, so this is something that
>> can simply always be done. Thus, can we just write a disclaimer in one
>> of our documents, recommending that any TAPS-supporting systems can
>> provide stream-based transport on top of the message based transport
>> too, but that its users must be aware of limitations that arise from
>> streams (such as HOL blocking delay, no ALF, ..)?
>>
>> Cheers,
>> Michael
>>
>>
>>
>> _______________________________________________
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
>
>
>
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
>


From nobody Sat Jun 28 02:31:47 2014
Return-Path: 
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6F31A0332 for ; Sat, 28 Jun 2014 02:31:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
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 Y1bNLmgOXTZ4 for ; Sat, 28 Jun 2014 02:31:40 -0700 (PDT)
Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.107]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE4AB1A02F1 for ; Sat, 28 Jun 2014 02:31:39 -0700 (PDT)
Received: from [193.109.255.147:9942] by server-3.bemta-14.messagelabs.com id B1/63-13460-97B8EA35; Sat, 28 Jun 2014 09:31:37 +0000
X-Env-Sender: l.wood@surrey.ac.uk
X-Msg-Ref: server-6.tower-72.messagelabs.com!1403947896!14095536!1
X-Originating-IP: [131.227.200.39]
X-StarScan-Received: 
X-StarScan-Version: 6.11.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 482 invoked from network); 28 Jun 2014 09:31:36 -0000
Received: from exht012p.surrey.ac.uk (HELO EXHT012P.surrey.ac.uk) (131.227.200.39) by server-6.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 28 Jun 2014 09:31:36 -0000
Received: from EXHY022V.surrey.ac.uk (131.227.201.104) by EXHT012P.surrey.ac.uk (131.227.200.39) with Microsoft SMTP Server (TLS) id 8.3.348.2; Sat, 28 Jun 2014 10:31:35 +0100
Received: from emea01-am1-obe.outbound.protection.outlook.com (131.227.201.241) by EXHY022v.surrey.ac.uk (131.227.201.104) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sat, 28 Jun 2014 10:31:36 +0100
Received: from AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) by AMSPR06MB437.eurprd06.prod.outlook.com (10.242.23.11) with Microsoft SMTP Server (TLS) id 15.0.969.15; Sat, 28 Jun 2014 09:31:35 +0000
Received: from AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) by AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) with mapi id 15.00.0969.007; Sat, 28 Jun 2014 09:31:35 +0000
From: 
To: , 
Thread-Topic: [Taps] Charter bikeshed #1 - "transport service"
Thread-Index: AQHPkg3Qpp9PvhY+OkO75h7vCz/t/5uFAgmAgAAEsACAAAhAgIAAeIHZ
Date: Sat, 28 Jun 2014 09:31:33 +0000
Message-ID: <0305821c865245e08cc4531ff66d9c7d@AMSPR06MB439.eurprd06.prod.outlook.com>
References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACAFDA.3060303@gmail.com> <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> <53AD74D8.9010906@gmail.com>  <33966B16-D15B-49E5-BEBD-C8DE990F8028@ifi.uio.no>,<53AD88BD.6090003@kau.se>
In-Reply-To: <53AD88BD.6090003@kau.se>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [124.149.114.231]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 0256C18696
x-forefront-antispam-report: SFV:NSPM; SFS:(377424004)(377454003)(189002)(199002)(24454002)(33646001)(15975445006)(101416001)(4396001)(31966008)(50986999)(19580405001)(19580395003)(20776003)(105586002)(83322001)(76176999)(74482001)(85306003)(83072002)(85852003)(86362001)(64706001)(74502001)(74662001)(66066001)(16236675004)(80022001)(76482001)(106356001)(77982001)(106116001)(79102001)(87936001)(99396002)(95666004)(81342001)(76576001)(54356999)(74316001)(93886003)(81542001)(2656002)(92566001)(46102001)(21056001)(107046002)(17413003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR06MB437; H:AMSPR06MB439.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_0305821c865245e08cc4531ff66d9c7dAMSPR06MB439eurprd06pro_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: AMSPR06MB437.eurprd06.prod.outlook.com
X-CrossPremisesHeadersFiltered: EXHY022v.surrey.ac.uk
Archived-At: http://mailarchive.ietf.org/arch/msg/taps/RG7yqEosmI3-b6DBwuBhuMOqSHw
Cc: bclaise@cisco.com, spencerdawkins.ietf@gmail.com
Subject: Re: [Taps] Charter bikeshed #1 - "transport service"
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Jun 2014 09:31:44 -0000

--_000_0305821c865245e08cc4531ff66d9c7dAMSPR06MB439eurprd06pro_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

on reliability, are we talking of reliable erasure-free DELIVERY or reliabl=
e error-free CONTENT that is delivered?

Two dimensions here. We spent a few years debating the nuances in DTNRG.

e.g. TCP is thought to offer both, but its payload content check is weak. S=
CTP can vary delivery reliability, while its payload check is stronger. UDP=
-Lite doesn't give reliable delivery, its content check can vary, etc.
________________________________
From: Taps  on behalf of Anna Brunstrom 
Sent: Saturday, 28 June 2014 1:07:41 AM
To: taps@ietf.org
Cc: bclaise@cisco.com; spencerdawkins.ietf@gmail.com
Subject: Re: [Taps] Charter bikeshed #1 - "transport service"

Hi,

Repeating one of my comments on the long mail to this more manageable versi=
on that Micheal produced while I was reading.

Anna

On 2014-06-27 16:38, Michael Welzl wrote:
Hi,

I'll cut away a lot now, and only address things that need addressing below=
:


On 27. juni 2014, at 16:21, Toby Moncaster > wrote:

[snip]

I agree with Michael here. I think we could end up with a much less clearly=
 worded charter if we go down that route. If there is a need to be more pre=
cise then I=92d favour adding something near the beginning of the charter a=
long the lines of the definition I put in the Problem Statement document. N=
amely:  "A Transport Service is any service provided by the transport layer=
 that can only be correctly implemented with information from the applicati=
on.=94We could then include 2 or 3 example services

I agree. Putting that definition in there would be nice.


    - full reliability
    - latency-limited reliability

Yes, reliability is a service, and fine to include in the list. But I'd rat=
her replace this with any of:
"various degrees of reliability" or "various forms of reliability" or "full=
 / latency-limited / no reliability"
...or something like that.  One item, not two, anyway.


Hmmm. I=92d rather we had something like =93Degree of reliability from unre=
liable to full reliability."

Agree.


Second, using the phrase "congestion control" binds the application require=
ment to a specific mechanism. I'd rather use something like "low delay vs. =
high throughput=94.

Perhaps this would best be expressed as =93Trading off latency and throughp=
ut"

Agree.


I don't know if this list is correct or complete. This should be the WG
job to compile it.
Btw, adding this list to the charter, as a starting point, would make
sense.

So, to summarize, here's the complete list that I suggest:

- sequence preservation
- various degrees of reliability
- low delay vs. high throughput

I=92d rephrase this as:

- ordering/sequence preservation
- degree of reliability
- latency vs throughput

Agree, this is nicer!


How do we call the transport that support those 5 things? a transport
protocol? a transport service?
The "services" term is used multiple times within the charter.
Sometimes I understand it as a "transport protocol" (like in the first
sentence in the charter),
And sometimes I may interpret it as Brian's "dimensions of transport" or
criteria.

Potentially use "criteria" and "transport protocol"
Alternatively, only use "transport services" when it means "criteria, and
"transport protocol".
I tried to do the latter below.



Again, detailed comments in line:


OLD:

Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
UDP-Lite and the LEDBAT congestion control mechanism extend
the set of transport services that are available to
applications, beyond those provided by TCP and UDP. For
example, SCTP provides potentially faster reliable delivery
for applications that can accept blocks of data out of order,
and LEDBAT provides low-priority "scavenger" communication.

NEW:
Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
UDP-Lite and the LEDBAT congestion control mechanism extend
the set of transport protocols that are available to
applications, beyond those provided by TCP and UDP. For
example, SCTP provides potentially faster reliable delivery
for applications that can accept blocks of data out of order,
and LEDBAT provides low-priority "scavenger" communication.

Disagree, I'd rather leave it as it is to stress that applications use serv=
ices, not protocols.


I actually think changing that to protocols might be a good thing, since it=
 highlights how complex the landscape has become.


I disagree. The "For example" list gets very strange as examples of transpo=
rt protocols. I also agree with Michael's original objection: stressing tha=
t applications use services is important.



Okay, fine by me. I don't have a strong opinion here either way.


OLD:

- Identify services provided by existing IETF transport protocols
  and congestion control mechanisms. The resulting document will
  provide guidance on making a choice among available mechanisms
  and protocols to obtain a certain transport service.


NEW:

- Identify transport services provided by existing IETF transport
protocols
  and congestion control mechanisms. The resulting document will
  provide guidance on making a choice among available mechanisms
  and protocols to obtain a certain transport service. As a starting
point
  for transport services, the working group can consider: message
atomicity,
  stream fragmentation, sequence preservation, head-of-line blocking
avoidance,
  sub-channels, full reliability, latency-limited reliability,
loss-sensitive
  congestion control, delay-sensitive congestion control, endpoint
address agility,
  privacy and integrity, and path-state propagation (NAT/Firewall).

Sentence 1: "transport services provided by ..  transport protocols" doesn'=
t seem to make things clearer. I'd rather keep "services" in this sentence =
- what this means gets concrete anyway due to the list that follows in sent=
ence 3, and there the phrase "transport services" is used anyway. The list =
should be changed, as I argued above. I suggest:

NEW:

- Identify services provided by existing IETF transport protocols
  and congestion control mechanisms. The resulting document will
  provide guidance on making a choice among available mechanisms
  and protocols to obtain a certain transport service. As a starting point
  for transport services, the working group can consider: sequence
  preservation, various degrees of reliability, low delay vs. high throughp=
ut.

I think here we=92re once again running into the difficulty of the ambiguit=
y of the word =93transport=94, especially in the IETF=85 If we have defined=
 Transport Services in terms of the transport protocol earlier in the docum=
ent, can we actually phrase this

- Identify Transport Services provided by IETF protocols and congestion con=
trol mechanisms

Agreed


OLD:
- Specify experimental mechanisms to deliver a transport service.
  This will explain how to select and engage a protocol, and how
  to discover the availability of protocols on an interface (both
  end system and path support), in order to provide a basis for
  incremental deployment.

NEW:
- Specify experimental mechanisms to deliver a transport protocol.
  This will explain how to select and engage a protocol, and how
  to discover the availability of protocol services on an interface (both

  end system and path support), in order to provide a basis for
  incremental deployment.


Disagree. "deliver a transport protocol" is weird. The intention was to say=
 "provide a transport service", maybe "deliver" is a bad choice of words he=
re? So I suggest:

NEW:
- Specify experimental mechanisms to provide a transport service.
  This will explain how to select and engage a protocol, and how
  to discover the availability of protocols on an interface (both
  end system and path support), in order to provide a basis for
  incremental deployment.

Specify experimental mechanisms to provide a given Transport Service.
This will explain how to select and engage an appropriate protocol and
how to discover which protocols are available for a given connection.
This will provide a basis for incremental deployment.

Agreed.


 "The Working Group will coordinate closely with other Working Groups and
IRTF Research Groups."
You should list the WGs you have in mind.

I agree that it looks odd as it stands. I'm not sure what the right approac=
h is here (simply remove? or what are these groups?) - e.g. Spencer would k=
now better than me=85


I think the key thing here was that we aren=92t only limiting ourselves to =
working with the IETF but are also interested in getting input from the IRT=
F. However I think we can drop this

Agreed.

Cheers,
Michael




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



--_000_0305821c865245e08cc4531ff66d9c7dAMSPR06MB439eurprd06pro_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable






on reliability, are we talking of reliable erasure-free DELIVERY or reliabl=
e error-free CONTENT that is delivered?



Two dimensions here. We spent a few years debating the nuances in DTNRG.


e.g. TCP is thought to offer both, but its payload content check is weak. S=
CTP can vary delivery reliability, while its payload check is stronger. UDP=
-Lite doesn't give reliable delivery, its content check can vary, etc.



From: Taps <taps-bounces=
@ietf.org> on behalf of Anna Brunstrom <anna.brunstrom@kau.se>

Sent: Saturday, 28 June 2014 1:07:41 AM

To: taps@ietf.org

Cc: bclaise@cisco.com; spencerdawkins.ietf@gmail.com

Subject: Re: [Taps] Charter bikeshed #1 - "transport service&qu=
ot;

 




Hi,



Repeating one of my comments on the long mail to this more manageable versi=
on that Micheal produced while I was reading.



Anna 



On 2014-06-27 16:38, Michael Welzl wrote:




Hi,







I'll cut away a lot now, and only address things that need addressing =
below:
















On 27. juni 2014, at 16:21, Toby Moncaster <toby.moncaster@cl.cam.ac.u=
k> wrote:






[snip]












I agree with Michael here. I think we could end up with a much less clearly=
 worded charter if we go down that route. If there is a need to be more pre=
cise then I=92d favour adding something near the beginning of the charter a=
long the lines of the definition I
 put in the Problem Statement document. Namely:  "A Transport Service is any service provided by the =
transport layer that can only be correctly implemented with information fro=
m the application.=94We could then include 2 or
 3 example services 















I agree. Putting that definition in =
there would be nice.

































    - full reliability










    - latency-limited reliability

















Yes, reliability is a service, and fine to include in the list. But I'=
d rather replace this with any of:


"various degrees of reliability" or "various forms of r=
eliability" or "full / latency-limited / no reliability"

...or something like that.  One item, not two, anyway.


















Hmmm. I=92d rather we had something like =93Degree of reliability from=
 unreliable to full reliability."














Agree.




























Second, using the phrase "congestion control" binds the appl=
ication requirement to a specific mechanism. I'd rather use something like =
"low delay vs. high throughput=94.













Perhaps this would best be expressed as =93Trading off latency and thr=
oughput"















Agree.

























I don't know if this list is correct or complete.=
 This should be the WG

job to compile it.

Btw, adding this list to the charter, as a starting point, would make

sense.











So, to summarize, here's the complete list that I suggest:







- sequence preservation


- various degrees of reliability


- low delay vs. high throughput













I=92d rephrase this as:







- ordering/sequence preservation


- degree of reliability 


- latency vs throughput














Agree, this is nicer!




























How do we call the transport that support those 5=
 things? a transport

protocol? a transport service?

The "services" term is used multiple times within the charter.
Sometimes I understand it as a "transport protocol" (like in the =
first

sentence in the charter),

And sometimes I may interpret it as Brian's "dimensions of transport&q=
uot; or

criteria.



Potentially use "criteria" and "transport protocol"

Alternatively, only use "transport services" when it means "=
criteria, and

"transport protocol".

I tried to do the latter below.














Again, detailed comments in line:












OLD:



Conjointly, transport protocols such as SCTP, DCCP, MPTCP,

UDP-Lite and the LEDBAT congestion control mechanism extend

the set of transport services that are available to

applications, beyond those provided by TCP and UDP. For

example, SCTP provides potentially faster reliable delivery

for applications that can accept blocks of data out of order,

and LEDBAT provides low-priority "scavenger" communication.



NEW:

Conjointly, transport protocols such as SCTP, DCCP, MPTCP,

UDP-Lite and the LEDBAT congestion control mechanism extend

the set of transport protocols that are available to

applications, beyond those provided by TCP and UDP. For

example, SCTP provides potentially faster reliable delivery

for applications that can accept blocks of data out of order,

and LEDBAT provides low-priority "scavenger" communication.










Disagree, I'd rather leave it as it is to stress that applications use serv=
ices, not protocols.


















I actually think changing that to protocols might be a good thing, sin=
ce it highlights how complex the landscape has become. 


















I disagree. The "For example" list gets very strange as examples =
of transport protocols. I also agree with Michael's original objection: str=
essing that applications use services is important.














Okay, fine by me. I don't have a strong opinion here either way.



































OLD:



- Identify services provided by existing IETF transport protocols

  and congestion control mechanisms. The resulting document will<=
br>
  provide guidance on making a choice among available mechanisms<=
br>
  and protocols to obtain a certain transport service.





NEW:



- Identify transport services provided by existing IETF transport

protocols

  and congestion control mechanisms. The resulting document will<=
br>
  provide guidance on making a choice among available mechanisms<=
br>
  and protocols to obtain a certain transport service. As a start=
ing

point

  for transport services, the working group can consider: message=


atomicity,

  stream fragmentation, sequence preservation, head-of-line block=
ing

avoidance,

  sub-channels, full reliability, latency-limited reliability,
loss-sensitive

  congestion control, delay-sensitive congestion control, endpoin=
t

address agility,

  privacy and integrity, and path-state propagation (NAT/Firewall=
).











Sentence 1: "transport services provided by ..  transport pr=
otocols" doesn't seem to make things clearer. I'd rather keep "se=
rvices" in this sentence - what this means gets concrete anyway due to=
 the list that follows in sentence 3, and there the phrase
 "transport services" is used anyway. The list should be changed,=
 as I argued above. I suggest:







NEW:







- Identify services provided by existing IETF transport protocols

  and congestion control mechanisms. The resulting document will

  provide guidance on making a choice among available mechanisms

  and protocols to obtain a certain transport service. As a starting p=
oint


  for transport services, the working group can consider: sequenc=
e


  preservation, various degrees of reliability, low delay vs. hig=
h throughput.















I think here we=92re once again running into the difficulty of the amb=
iguity of the word =93transport=94, especially in the IETF=85 If we have de=
fined Transport Services in terms of the transport protocol earlier in the =
document, can we actually phrase this







- Identify Transport Services provided by IETF protocols and congestio=
n control mechanisms










Agreed
























OLD:

- Specify experimental mechanisms to deliver a transport service.

  This will explain how to select and engage a protocol, and how<=
br>
  to discover the availability of protocols on an interface (both=


  end system and path support), in order to provide a basis for
  incremental deployment.



NEW:

- Specify experimental mechanisms to deliver a transport protocol.

  This will explain how to select and engage a protocol, and how<=
br>
  to discover the availability of protocol services on an interfa=
ce (both



  end system and path support), in order to provide a basis for
  incremental deployment.















Disagree. "deliver a transport protocol" is weird. The intention =
was to say "provide a transport service", maybe "deliver&quo=
t; is a bad choice of words here? So I suggest:







NEW:

- Specify experimental mechanisms to provide a transport service.

  This will explain how to select and engage a protocol, and how

  to discover the availability of protocols on an interface (both

  end system and path support), in order to provide a basis for

  incremental deployment.













Specify experimental mechanisms to provide a given Transport Service.&=
nbsp;


This will explain how to select and engage an appropriate protocol and=
 


how to discover which protocols are available for a given connection.&=
nbsp;


This will provide a basis for incremental deployment.











Agreed.
























 "The Working Group will coordinate clo=
sely with other Working Groups and

IRTF Research Groups."

You should list the WGs you have in mind.











I agree that it looks odd as it stands. I'm not sure what the right ap=
proach is here (simply remove? or what are these groups?) - e.g. Spencer wo=
uld know better than me=85


















I think the key thing here was that we aren=92t only limiting ourselve=
s to working with the IETF but are also interested in getting input from th=
e IRTF. However I think we can drop this










Agreed.







Cheers,


Michael











 


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











--_000_0305821c865245e08cc4531ff66d9c7dAMSPR06MB439eurprd06pro_--


From nobody Sat Jun 28 03:08:10 2014
Return-Path: 
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFA41A0338 for ; Sat, 28 Jun 2014 03:08:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 u4kdMMtQfXbQ for ; Sat, 28 Jun 2014 03:08:00 -0700 (PDT)
Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABE621A0336 for ; Sat, 28 Jun 2014 03:08:00 -0700 (PDT)
Received: by mail-qc0-f176.google.com with SMTP id w7so5475535qcr.35 for ; Sat, 28 Jun 2014 03:07:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=inpWC+JAGcICvl61LEPA/8LqO7r28iinSyGQAFT2LJo=; b=fUn9C2RkJkNOS4ZAAPIauJYKiGn0GeSrnnF1riwZj1rMMBgNp/A23jE/r2gXOZUZFh 5bQ8N9iO3i7YT5KH/Oprrl7g0BDJBEbTpQBz1AM+HrzcfnBDmu8fsjv5pw74OHVPDQUM fYAyW3DvG1JHi8R0DlaaqJiv0nDLwPFEuvjavXLdyO8qFW+w0Bg+Q6ml+XFqqmcpNFM7 mAzmZtoXWOUWKm2SkUC4jfKnJpV/aWk/aYdpgWDjtATf/TeaxZcWxUdVC4Q2ANtNjbGA rwhM43JYGlVVc2IFsLUATfz+HAZMjD9TOLpHjyn4AeiyNkme3PqVx3mLMXYN7X3NrLE7 Hl7Q==
X-Gm-Message-State: ALoCoQnKVjdIsZZFF98fPOlCIPy26mKB5q7dpf/Z5T4lDt8wgtztAdyYmZ/Aeo/EVjtJJuVyWrYM
X-Received: by 10.140.20.247 with SMTP id 110mr2946677qgj.49.1403950079773; Sat, 28 Jun 2014 03:07:59 -0700 (PDT)
Received: from [10.0.1.19] (c-76-118-234-192.hsd1.ma.comcast.net. [76.118.234.192]) by mx.google.com with ESMTPSA id j1sm21022328qaa.11.2014.06.28.03.07.58 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Jun 2014 03:07:58 -0700 (PDT)
References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACAFDA.3060303@gmail.com> <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> <53AD74D8.9010906@gmail.com>  <33966B16-D15B-49E5-BEBD-C8DE990F8028@ifi.uio.no> <53AD88BD.6090003@kau.se> <0305821c865245e08cc4531ff66d9c7d@AMSPR06MB439.eurprd06.prod.outlook.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <0305821c865245e08cc4531ff66d9c7d@AMSPR06MB439.eurprd06.prod.outlook.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-ACC07936-93F3-48D1-9D18-F4912580C76C
Content-Transfer-Encoding: 7bit
Message-Id: <12FABC6F-187D-479C-8A72-4D1FBC5C25FC@mjmontpetit.com>
X-Mailer: iPad Mail (11D201)
From: Marie-Jose Montpetit 
Date: Sat, 28 Jun 2014 06:08:00 -0400
To: "" 
Archived-At: http://mailarchive.ietf.org/arch/msg/taps/fFzJ674yMHE-tcVJO8hSYgFGEw4
Cc: "bclaise@cisco.com" , "spencerdawkins.ietf@gmail.com" , "" , "" 
Subject: Re: [Taps] Charter bikeshed #1 - "transport service"
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Jun 2014 10:08:08 -0000

--Apple-Mail-ACC07936-93F3-48D1-9D18-F4912580C76C
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

I would say that we should not limit it to one or the other but make it depe=
ndent on the application requirement.

Marie-Jos=C3=A9 Montpetit
marie@mjmontpetit.com
mariejo@mit.edu

> On Jun 28, 2014, at 5:31,  wrote:
>=20
> on reliability, are we talking of reliable erasure-free DELIVERY or reliab=
le error-free CONTENT that is delivered?
>=20
> Two dimensions here. We spent a few years debating the nuances in DTNRG.
>=20
> e.g. TCP is thought to offer both, but its payload content check is weak. S=
CTP can vary delivery reliability, while its payload check is stronger. UDP-=
Lite doesn't give reliable delivery, its content check can vary, etc.=20
> From: Taps  on behalf of Anna Brunstrom 
> Sent: Saturday, 28 June 2014 1:07:41 AM
> To: taps@ietf.org
> Cc: bclaise@cisco.com; spencerdawkins.ietf@gmail.com
> Subject: Re: [Taps] Charter bikeshed #1 - "transport service"
> =20
> Hi,
>=20
> Repeating one of my comments on the long mail to this more manageable vers=
ion that Micheal produced while I was reading.
>=20
> Anna=20
>=20
>> On 2014-06-27 16:38, Michael Welzl wrote:
>> Hi,
>>=20
>> I'll cut away a lot now, and only address things that need addressing bel=
ow:
>>=20
>>=20
>> On 27. juni 2014, at 16:21, Toby Moncaster  w=
rote:
>>=20
>> [snip]
>>=20
>>> I agree with Michael here. I think we could end up with a much less clea=
rly worded charter if we go down that route. If there is a need to be more p=
recise then I=E2=80=99d favour adding something near the beginning of the ch=
arter along the lines of the definition I put in the Problem Statement docum=
ent. Namely:  "A Transport Service is any service provided by the transport l=
ayer that can only be correctly implemented with information from the applic=
ation.=E2=80=9DWe could then include 2 or
>>>  3 example services=20
>>=20
>>=20
>> I agree. Putting that definition in there would be nice.
>>=20
>>=20
>>=20
>>>>>>>     - full reliability
>>>>>>>     - latency-limited reliability
>>>>>>=20
>>>>>=20
>>>>> Yes, reliability is a service, and fine to include in the list. But I'=
d rather replace this with any of:
>>>>> "various degrees of reliability" or "various forms of reliability" or "=
full / latency-limited / no reliability"
>>>>> ...or something like that.  One item, not two, anyway.
>>>=20
>>>=20
>>> Hmmm. I=E2=80=99d rather we had something like =E2=80=9CDegree of reliab=
ility from unreliable to full reliability."
>>=20
>> Agree.
>>=20
>>=20
>>>>> Second, using the phrase "congestion control" binds the application re=
quirement to a specific mechanism. I'd rather use something like "low delay v=
s. high throughput=E2=80=9D.
>>>=20
>>> Perhaps this would best be expressed as =E2=80=9CTrading off latency and=
 throughput"
>>=20
>> Agree.
>>=20
>>=20
>>>>>>> I don't know if this list is correct or complete. This should be the=
 WG
>>>>>>> job to compile it.
>>>>>>> Btw, adding this list to the charter, as a starting point, would mak=
e
>>>>>>> sense.
>>>>>=20
>>>>> So, to summarize, here's the complete list that I suggest:
>>>>>=20
>>>>> - sequence preservation
>>>>> - various degrees of reliability
>>>>> - low delay vs. high throughput
>>>=20
>>> I=E2=80=99d rephrase this as:
>>>=20
>>> - ordering/sequence preservation
>>> - degree of reliability=20
>>> - latency vs throughput
>>=20
>> Agree, this is nicer!
>>=20
>>=20
>>>>>>> How do we call the transport that support those 5 things? a transpor=
t
>>>>>>> protocol? a transport service?
>>>>>>> The "services" term is used multiple times within the charter.
>>>>>>> Sometimes I understand it as a "transport protocol" (like in the fir=
st
>>>>>>> sentence in the charter),
>>>>>>> And sometimes I may interpret it as Brian's "dimensions of transport=
" or
>>>>>>> criteria.
>>>>>>>=20
>>>>>>> Potentially use "criteria" and "transport protocol"
>>>>>>> Alternatively, only use "transport services" when it means "criteria=
, and
>>>>>>> "transport protocol".
>>>>>>> I tried to do the latter below.
>>>>>>>=20
>>>>>>>=20
>>>>>=20
>>>>> Again, detailed comments in line:
>>>>>=20
>>>>>=20
>>>>>>> OLD:
>>>>>>>=20
>>>>>>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
>>>>>>> UDP-Lite and the LEDBAT congestion control mechanism extend
>>>>>>> the set of transport services that are available to
>>>>>>> applications, beyond those provided by TCP and UDP. For
>>>>>>> example, SCTP provides potentially faster reliable delivery
>>>>>>> for applications that can accept blocks of data out of order,
>>>>>>> and LEDBAT provides low-priority "scavenger" communication.
>>>>>>>=20
>>>>>>> NEW:
>>>>>>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
>>>>>>> UDP-Lite and the LEDBAT congestion control mechanism extend
>>>>>>> the set of transport protocols that are available to
>>>>>>> applications, beyond those provided by TCP and UDP. For
>>>>>>> example, SCTP provides potentially faster reliable delivery
>>>>>>> for applications that can accept blocks of data out of order,
>>>>>>> and LEDBAT provides low-priority "scavenger" communication.
>>>>>=20
>>>>> Disagree, I'd rather leave it as it is to stress that applications use=
 services, not protocols.
>>>=20
>>>=20
>>> I actually think changing that to protocols might be a good thing, since=
 it highlights how complex the landscape has become.=20
>>=20
>=20
> I disagree. The "For example" list gets very strange as examples of transp=
ort protocols. I also agree with Michael's original objection: stressing tha=
t applications use services is important.
>=20
>=20
>=20
>> Okay, fine by me. I don't have a strong opinion here either way.
>>=20
>>=20
>>>>>>> OLD:
>>>>>>>=20
>>>>>>> - Identify services provided by existing IETF transport protocols
>>>>>>>   and congestion control mechanisms. The resulting document will
>>>>>>>   provide guidance on making a choice among available mechanisms
>>>>>>>   and protocols to obtain a certain transport service.
>>>>>>>=20
>>>>>>>=20
>>>>>>> NEW:
>>>>>>>=20
>>>>>>> - Identify transport services provided by existing IETF transport
>>>>>>> protocols
>>>>>>>   and congestion control mechanisms. The resulting document will
>>>>>>>   provide guidance on making a choice among available mechanisms
>>>>>>>   and protocols to obtain a certain transport service. As a starting=

>>>>>>> point
>>>>>>>   for transport services, the working group can consider: message
>>>>>>> atomicity,
>>>>>>>   stream fragmentation, sequence preservation, head-of-line blocking=

>>>>>>> avoidance,
>>>>>>>   sub-channels, full reliability, latency-limited reliability,
>>>>>>> loss-sensitive
>>>>>>>   congestion control, delay-sensitive congestion control, endpoint
>>>>>>> address agility,
>>>>>>>   privacy and integrity, and path-state propagation (NAT/Firewall).
>>>>>=20
>>>>> Sentence 1: "transport services provided by ..  transport protocols" d=
oesn't seem to make things clearer. I'd rather keep "services" in this sente=
nce - what this means gets concrete anyway due to the list that follows in s=
entence 3, and there the phrase "transport services" is used anyway. The lis=
t should be changed, as I argued above. I suggest:
>>>>>=20
>>>>> NEW:
>>>>>=20
>>>>> - Identify services provided by existing IETF transport protocols
>>>>>   and congestion control mechanisms. The resulting document will
>>>>>   provide guidance on making a choice among available mechanisms
>>>>>   and protocols to obtain a certain transport service. As a starting p=
oint
>>>>>   for transport services, the working group can consider: sequence
>>>>>   preservation, various degrees of reliability, low delay vs. high thr=
oughput.
>>>=20
>>> I think here we=E2=80=99re once again running into the difficulty of the=
 ambiguity of the word =E2=80=9Ctransport=E2=80=9D, especially in the IETF=E2=
=80=A6 If we have defined Transport Services in terms of the transport proto=
col earlier in the document, can we actually phrase this
>>>=20
>>> - Identify Transport Services provided by IETF protocols and congestion c=
ontrol mechanisms
>>=20
>> Agreed
>>=20
>>=20
>>>>>>> OLD:
>>>>>>> - Specify experimental mechanisms to deliver a transport service.
>>>>>>>   This will explain how to select and engage a protocol, and how
>>>>>>>   to discover the availability of protocols on an interface (both
>>>>>>>   end system and path support), in order to provide a basis for
>>>>>>>   incremental deployment.
>>>>>>>=20
>>>>>>> NEW:
>>>>>>> - Specify experimental mechanisms to deliver a transport protocol.
>>>>>>>   This will explain how to select and engage a protocol, and how
>>>>>>>   to discover the availability of protocol services on an interface (=
both
>>>>>>>=20
>>>>>>>   end system and path support), in order to provide a basis for
>>>>>>>   incremental deployment.
>>>>>=20
>>>>>=20
>>>>> Disagree. "deliver a transport protocol" is weird. The intention was t=
o say "provide a transport service", maybe "deliver" is a bad choice of word=
s here? So I suggest:
>>>>>=20
>>>>> NEW:
>>>>> - Specify experimental mechanisms to provide a transport service.
>>>>>   This will explain how to select and engage a protocol, and how
>>>>>   to discover the availability of protocols on an interface (both
>>>>>   end system and path support), in order to provide a basis for
>>>>>   incremental deployment.
>>>=20
>>> Specify experimental mechanisms to provide a given Transport Service.=20=

>>> This will explain how to select and engage an appropriate protocol and=20=

>>> how to discover which protocols are available for a given connection.=20=

>>> This will provide a basis for incremental deployment.
>>=20
>> Agreed.
>>=20
>>=20
>>>>>>>  "The Working Group will coordinate closely with other Working Group=
s and
>>>>>>> IRTF Research Groups."
>>>>>>> You should list the WGs you have in mind.
>>>>>=20
>>>>> I agree that it looks odd as it stands. I'm not sure what the right ap=
proach is here (simply remove? or what are these groups?) - e.g. Spencer wou=
ld know better than me=E2=80=A6
>>>=20
>>>=20
>>> I think the key thing here was that we aren=E2=80=99t only limiting ours=
elves to working with the IETF but are also interested in getting input from=
 the IRTF. However I think we can drop this
>>=20
>> Agreed.
>>=20
>> Cheers,
>> Michael
>>=20
>>=20
>>=20
>> _______________________________________________
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
>=20
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps

--Apple-Mail-ACC07936-93F3-48D1-9D18-F4912580C76C
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


I would say that we should not limit i=
t to one or the other but make it dependent on the application requirement.<=
br>
Marie-Jos=C3=A9 Montpetit

On Jun 28, 2014, at 5:31, <l.wood@surrey.ac.uk> wrote:






on reliability, are we talking of reliable erasure-free DELIVERY or reliable=
 error-free CONTENT that is delivered?



Two dimensions here. We spent a few years debating the nuances in DTNRG.
=



e.g. TCP is thought to offer both, but its payload content check is weak. SC=
TP can vary delivery reliability, while its payload check is stronger. UDP-L=
ite doesn't give reliable delivery, its content check can vary, etc.




Hi,



Repeating one of my comments on the long mail to this more manageable versio=
n that Micheal produced while I was reading.



Anna 



On 2014-06-27 16:38, Michael Welzl wrote:




Hi,







I'll cut away a lot now, and only address things that need addressing b=
elow:

























I agree with Michael here. I think we could end up with a much less clearly w=
orded charter if we go down that route. If there is a need to be more precis=
e then I=E2=80=99d favour adding something near the beginning of the charter=
 along the lines of the definition I
 put in the Problem Statement document. Namely:  "A Transport Service is any service provided by the transpo=
rt layer that can only be correctly implemented with information from the ap=
plication.=E2=80=9DWe could then include 2 or
 3 example services 















I agree. Putting that definition in t=
here would be nice.

































    - full reliability










    - latency-limited reliability

















Yes, reliability is a service, and fine to include in the list. But I'd=
 rather replace this with any of:


"various degrees of reliability" or "various forms of reliability" or "=
full / latency-limited / no reliability"


...or something like that.  One item, not two, anyway.


















Hmmm. I=E2=80=99d rather we had something like =E2=80=9CDegree of relia=
bility from unreliable to full reliability."














Agree.




























Second, using the phrase "congestion control" binds the application req=
uirement to a specific mechanism. I'd rather use something like "low delay v=
s. high throughput=E2=80=9D.













Perhaps this would best be expressed as =E2=80=9CTrading off latency an=
d throughput"















Agree.

























I don't know if this list is correct or complete. T=
his should be the WG

job to compile it.

Btw, adding this list to the charter, as a starting point, would make

sense.











So, to summarize, here's the complete list that I suggest:







- sequence preservation


- various degrees of reliability


- low delay vs. high throughput













I=E2=80=99d rephrase this as:







- ordering/sequence preservation


- degree of reliability 


- latency vs throughput














Agree, this is nicer!




























How do we call the transport that support those 5 t=
hings? a transport

protocol? a transport service?

The "services" term is used multiple times within the charter.

Sometimes I understand it as a "transport protocol" (like in the first

sentence in the charter),

And sometimes I may interpret it as Brian's "dimensions of transport" or
=

criteria.



Potentially use "criteria" and "transport protocol"

Alternatively, only use "transport services" when it means "criteria, and
"transport protocol".

I tried to do the latter below.














Again, detailed comments in line:












OLD:



Conjointly, transport protocols such as SCTP, DCCP, MPTCP,

UDP-Lite and the LEDBAT congestion control mechanism extend

the set of transport services that are available to

applications, beyond those provided by TCP and UDP. For

example, SCTP provides potentially faster reliable delivery

for applications that can accept blocks of data out of order,

and LEDBAT provides low-priority "scavenger" communication.



NEW:

Conjointly, transport protocols such as SCTP, DCCP, MPTCP,

UDP-Lite and the LEDBAT congestion control mechanism extend

the set of transport protocols that are available to

applications, beyond those provided by TCP and UDP. For

example, SCTP provides potentially faster reliable delivery

for applications that can accept blocks of data out of order,

and LEDBAT provides low-priority "scavenger" communication.










Disagree, I'd rather leave it as it is to stress that applications use servi=
ces, not protocols.


















I actually think changing that to protocols might be a good thing, sinc=
e it highlights how complex the landscape has become. 


















I disagree. The "For example" list gets very strange as examples of transpor=
t protocols. I also agree with Michael's original objection: stressing that a=
pplications use services is important.














Okay, fine by me. I don't have a strong opinion here either way.



































OLD:



- Identify services provided by existing IETF transport protocols

  and congestion control mechanisms. The resulting document will
  provide guidance on making a choice among available mechanisms
  and protocols to obtain a certain transport service.





NEW:



- Identify transport services provided by existing IETF transport

protocols

  and congestion control mechanisms. The resulting document will
  provide guidance on making a choice among available mechanisms
  and protocols to obtain a certain transport service. As a starti=
ng

point

  for transport services, the working group can consider: message<=
br>
atomicity,

  stream fragmentation, sequence preservation, head-of-line blocki=
ng

avoidance,

  sub-channels, full reliability, latency-limited reliability,
=

loss-sensitive

  congestion control, delay-sensitive congestion control, endpoint=


address agility,

  privacy and integrity, and path-state propagation (NAT/Firewall)=
.











Sentence 1: "transport services provided by ..  transport protocol=
s" doesn't seem to make things clearer. I'd rather keep "services" in this s=
entence - what this means gets concrete anyway due to the list that follows i=
n sentence 3, and there the phrase
 "transport services" is used anyway. The list should be changed, as I argue=
d above. I suggest:







NEW:







- Identify services provided by existing IETF transport protocols

  and congestion control mechanisms. The resulting document will

  provide guidance on making a choice among available mechanisms

  and protocols to obtain a certain transport service. As a starting po=
int


  for transport services, the working group can consider: sequence=



  preservation, various degrees of reliability, low delay vs. high=
 throughput.















I think here we=E2=80=99re once again running into the difficulty of th=
e ambiguity of the word =E2=80=9Ctransport=E2=80=9D, especially in the IETF=E2=
=80=A6 If we have defined Transport Services in terms of the transport proto=
col earlier in the document, can we actually phrase this







- Identify Transport Services provided by IETF protocols and congestion=
 control mechanisms










Agreed
























OLD:

- Specify experimental mechanisms to deliver a transport service.

  This will explain how to select and engage a protocol, and how
  to discover the availability of protocols on an interface (both<=
br>
  end system and path support), in order to provide a basis for
  incremental deployment.



NEW:

- Specify experimental mechanisms to deliver a transport protocol.

  This will explain how to select and engage a protocol, and how
  to discover the availability of protocol services on an interfac=
e (both



  end system and path support), in order to provide a basis for
  incremental deployment.















Disagree. "deliver a transport protocol" is weird. The intention was to say "=
provide a transport service", maybe "deliver" is a bad choice of words here?=
 So I suggest:







NEW:

- Specify experimental mechanisms to provide a transport service.

  This will explain how to select and engage a protocol, and how

  to discover the availability of protocols on an interface (both

  end system and path support), in order to provide a basis for

  incremental deployment.













Specify experimental mechanisms to provide a given Transport Service.&n=
bsp;


This will explain how to select and engage an appropriate protocol and&=
nbsp;


how to discover which protocols are available for a given connection.&n=
bsp;


This will provide a basis for incremental deployment.











Agreed.
























 "The Working Group will coordinate closely w=
ith other Working Groups and

IRTF Research Groups."

You should list the WGs you have in mind.











I agree that it looks odd as it stands. I'm not sure what the right app=
roach is here (simply remove? or what are these groups?) - e.g. Spencer woul=
d know better than me=E2=80=A6


















I think the key thing here was that we aren=E2=80=99t only limiting our=
selves to working with the IETF but are also interested in getting input fro=
m the IRTF. However I think we can drop this










Agreed.







Cheers,


Michael











 


_______________________________________________
Taps mailing 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
=

--Apple-Mail-ACC07936-93F3-48D1-9D18-F4912580C76C--


From nobody Sat Jun 28 07:46:55 2014
Return-Path: 
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8701A034E for ; Sat, 28 Jun 2014 07:46:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 YyghIuqlwU2A for ; Sat, 28 Jun 2014 07:46:50 -0700 (PDT)
Received: from mail-yh0-f72.google.com (mail-yh0-f72.google.com [209.85.213.72]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86DC1A034A for ; Sat, 28 Jun 2014 07:46:49 -0700 (PDT)
Received: by mail-yh0-f72.google.com with SMTP id f10so13011053yha.3 for ; Sat, 28 Jun 2014 07:46:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yeGKE7CjpgqYRNzXodO3rUjIltn395Z8vJS7LxT3Xyk=; b=AIUwd8sAz8+hscTX5HIzJfdgaJxv+9Wv67jI5sxD9C0iuwgL5CFWbT5r3qNKWP/G3h 2n71+76xRVYX2zh/Rt7I5gVtPsz3vghJk9FRfoHF5UOgk3rmw0BylneFP7AQdAxdR3Ry H3lhvZpBUGvvwDCAzr51r3ktfQYc+aZwGd6h/RoYxHvZTpSB/NnHZ6134oApT77GUC1c xKR3yqEYhPu/jCCxubfYiqQfU3hbAqMT1u/sHP5EoYa0qJUiE29egytaf4dPzttYViCP QSMZzhIEoE6lwTvMD892bphxgCLSxfMYV4IEPVrQcQ5CA9WAWYr0CH1sbDcx0Q2bVxDc wilw==
X-Gm-Message-State: ALoCoQled6YpyNXWs7NzYza5YxaoxwK9yIIhR3fVxdlyG/tL7vwnHPrF0MXXhIlv6T+dQP7YxObt
X-Received: by 10.52.253.131 with SMTP id aa3mr18156036vdd.25.1403966809070; Sat, 28 Jun 2014 07:46:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.58.85.72 with HTTP; Sat, 28 Jun 2014 07:46:28 -0700 (PDT)
In-Reply-To: <12FABC6F-187D-479C-8A72-4D1FBC5C25FC@mjmontpetit.com>
References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACAFDA.3060303@gmail.com> <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> <53AD74D8.9010906@gmail.com>  <33966B16-D15B-49E5-BEBD-C8DE990F8028@ifi.uio.no> <53AD88BD.6090003@kau.se> <0305821c865245e08cc4531ff66d9c7d@AMSPR06MB439.eurprd06.prod.outlook.com> <12FABC6F-187D-479C-8A72-4D1FBC5C25FC@mjmontpetit.com>
From: Aaron Falk 
Date: Sat, 28 Jun 2014 10:46:28 -0400
Message-ID: 
To: Marie-Jose Montpetit 
Content-Type: multipart/alternative; boundary=001a1135e9b6ee744f04fce67e3e
Archived-At: http://mailarchive.ietf.org/arch/msg/taps/8YeW2YLQgjtY8wCZV2LqQtSf_Y8
Cc: "bclaise@cisco.com" , "" , "spencerdawkins.ietf@gmail.com" , "" , "" 
Subject: Re: [Taps] Charter bikeshed #1 - "transport service"
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Jun 2014 14:46:54 -0000

--001a1135e9b6ee744f04fce67e3e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Sounds like there are two points here worth teasing apart:

1. "reliable erasure-free DELIVERY" vs "reliable error-free CONTENT that is
delivered" are different

and

2. Each is a 'dimension' rather than a binary characteristic (like, say, in
order delivery)

--aaron


On Sat, Jun 28, 2014 at 6:08 AM, Marie-Jose Montpetit  wrote:

> I would say that we should not limit it to one or the other but make it
> dependent on the application requirement.
>
> Marie-Jos=C3=A9 Montpetit
> marie@mjmontpetit.com
> mariejo@mit.edu
>
> On Jun 28, 2014, at 5:31,  wrote:
>
> on reliability, are we talking of reliable erasure-free DELIVERY or
> reliable error-free CONTENT that is delivered?
>
> Two dimensions here. We spent a few years debating the nuances in DTNRG.
>
> e.g. TCP is thought to offer both, but its payload content check is weak.
> SCTP can vary delivery reliability, while its payload check is stronger.
> UDP-Lite doesn't give reliable delivery, its content check can vary, etc.
> ------------------------------
> *From:* Taps  on behalf of Anna Brunstrom <
> anna.brunstrom@kau.se>
> *Sent:* Saturday, 28 June 2014 1:07:41 AM
> *To:* taps@ietf.org
> *Cc:* bclaise@cisco.com; spencerdawkins.ietf@gmail.com
> *Subject:* Re: [Taps] Charter bikeshed #1 - "transport service"
>
>  Hi,
>
> Repeating one of my comments on the long mail to this more manageable
> version that Micheal produced while I was reading.
>
> Anna
>
> On 2014-06-27 16:38, Michael Welzl wrote:
>
> Hi,
>
>  I'll cut away a lot now, and only address things that need addressing
> below:
>
>
>   On 27. juni 2014, at 16:21, Toby Moncaster 
> wrote:
>
>  [snip]
>
>   I agree with Michael here. I think we could end up with a much less
> clearly worded charter if we go down that route. If there is a need to be
> more precise then I=E2=80=99d favour adding something near the beginning =
of the
> charter along the lines of the definition I put in the Problem Statement
> document. Namely:  "A Transport Service is any service provided by the
> transport layer that can only be correctly implemented with information
> from the application.=E2=80=9DWe could then include 2 or 3 example servic=
es
>
>
>   I agree. Putting that definition in there would be nice.
>
>
>          - full reliability
>
>       - latency-limited reliability
>
>
>   Yes, reliability is a service, and fine to include in the list. But I'd
> rather replace this with any of:
> "various degrees of reliability" or "various forms of reliability" or
> "full / latency-limited / no reliability"
> ...or something like that.  One item, not two, anyway.
>
>
>
>  Hmmm. I=E2=80=99d rather we had something like =E2=80=9CDegree of reliab=
ility from
> unreliable to full reliability."
>
>
>  Agree.
>
>
>      Second, using the phrase "congestion control" binds the application
> requirement to a specific mechanism. I'd rather use something like "low
> delay vs. high throughput=E2=80=9D.
>
>
>  Perhaps this would best be expressed as =E2=80=9CTrading off latency and
> throughput"
>
>
>  Agree.
>
>
>     I don't know if this list is correct or complete. This should be the
> WG
> job to compile it.
> Btw, adding this list to the charter, as a starting point, would make
> sense.
>
>
>  So, to summarize, here's the complete list that I suggest:
>
>  - sequence preservation
> - various degrees of reliability
> - low delay vs. high throughput
>
>
>  I=E2=80=99d rephrase this as:
>
>  - ordering/sequence preservation
> - degree of reliability
> - latency vs throughput
>
>
>  Agree, this is nicer!
>
>
>      How do we call the transport that support those 5 things? a transpor=
t
> protocol? a transport service?
> The "services" term is used multiple times within the charter.
> Sometimes I understand it as a "transport protocol" (like in the first
> sentence in the charter),
> And sometimes I may interpret it as Brian's "dimensions of transport" or
> criteria.
>
> Potentially use "criteria" and "transport protocol"
> Alternatively, only use "transport services" when it means "criteria, and
> "transport protocol".
> I tried to do the latter below.
>
>
>
>  Again, detailed comments in line:
>
>
>  OLD:
>
> Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
> UDP-Lite and the LEDBAT congestion control mechanism extend
> the set of transport services that are available to
> applications, beyond those provided by TCP and UDP. For
> example, SCTP provides potentially faster reliable delivery
> for applications that can accept blocks of data out of order,
> and LEDBAT provides low-priority "scavenger" communication.
>
> NEW:
> Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
> UDP-Lite and the LEDBAT congestion control mechanism extend
> the set of transport protocols that are available to
> applications, beyond those provided by TCP and UDP. For
> example, SCTP provides potentially faster reliable delivery
> for applications that can accept blocks of data out of order,
> and LEDBAT provides low-priority "scavenger" communication.
>
>
>  Disagree, I'd rather leave it as it is to stress that applications use
> services, not protocols.
>
>
>
>  I actually think changing that to protocols might be a good thing, since
> it highlights how complex the landscape has become.
>
>
>
> I disagree. The "For example" list gets very strange as examples of
> transport protocols. I also agree with Michael's original objection:
> stressing that applications use services is important.
>
>
>
>   Okay, fine by me. I don't have a strong opinion here either way.
>
>
>
>     OLD:
>
> - Identify services provided by existing IETF transport protocols
>   and congestion control mechanisms. The resulting document will
>   provide guidance on making a choice among available mechanisms
>   and protocols to obtain a certain transport service.
>
>
> NEW:
>
> - Identify transport services provided by existing IETF transport
> protocols
>   and congestion control mechanisms. The resulting document will
>   provide guidance on making a choice among available mechanisms
>   and protocols to obtain a certain transport service. As a starting
> point
>   for transport services, the working group can consider: message
> atomicity,
>   stream fragmentation, sequence preservation, head-of-line blocking
> avoidance,
>   sub-channels, full reliability, latency-limited reliability,
> loss-sensitive
>   congestion control, delay-sensitive congestion control, endpoint
> address agility,
>   privacy and integrity, and path-state propagation (NAT/Firewall).
>
>
>  Sentence 1: "transport services provided by ..  transport protocols"
> doesn't seem to make things clearer. I'd rather keep "services" in this
> sentence - what this means gets concrete anyway due to the list that
> follows in sentence 3, and there the phrase "transport services" is used
> anyway. The list should be changed, as I argued above. I suggest:
>
>  NEW:
>
>  - Identify services provided by existing IETF transport protocols
>   and congestion control mechanisms. The resulting document will
>   provide guidance on making a choice among available mechanisms
>   and protocols to obtain a certain transport service. As a starting poin=
t
>   for transport services, the working group can consider: sequence
>   preservation, various degrees of reliability, low delay vs. high
> throughput.
>
>
>  I think here we=E2=80=99re once again running into the difficulty of the
> ambiguity of the word =E2=80=9Ctransport=E2=80=9D, especially in the IETF=
=E2=80=A6 If we have
> defined Transport Services in terms of the transport protocol earlier in
> the document, can we actually phrase this
>
>  - Identify Transport Services provided by IETF protocols and congestion
> control mechanisms
>
>
>  Agreed
>
>
>     OLD:
> - Specify experimental mechanisms to deliver a transport service.
>   This will explain how to select and engage a protocol, and how
>   to discover the availability of protocols on an interface (both
>   end system and path support), in order to provide a basis for
>   incremental deployment.
>
> NEW:
> - Specify experimental mechanisms to deliver a transport protocol.
>   This will explain how to select and engage a protocol, and how
>   to discover the availability of protocol services on an interface (both
>
>   end system and path support), in order to provide a basis for
>   incremental deployment.
>
>
>
>  Disagree. "deliver a transport protocol" is weird. The intention was to
> say "provide a transport service", maybe "deliver" is a bad choice of wor=
ds
> here? So I suggest:
>
>  NEW:
> - Specify experimental mechanisms to provide a transport service.
>   This will explain how to select and engage a protocol, and how
>   to discover the availability of protocols on an interface (both
>   end system and path support), in order to provide a basis for
>   incremental deployment.
>
>
>  Specify experimental mechanisms to provide a given Transport Service.
> This will explain how to select and engage an appropriate protocol and
> how to discover which protocols are available for a given connection.
> This will provide a basis for incremental deployment.
>
>
>  Agreed.
>
>
>      "The Working Group will coordinate closely with other Working Groups
> and
> IRTF Research Groups."
> You should list the WGs you have in mind.
>
>
>  I agree that it looks odd as it stands. I'm not sure what the right
> approach is here (simply remove? or what are these groups?) - e.g. Spence=
r
> would know better than me=E2=80=A6
>
>
>
>  I think the key thing here was that we aren=E2=80=99t only limiting ours=
elves to
> working with the IETF but are also interested in getting input from the
> IRTF. However I think we can drop this
>
>
>  Agreed.
>
>  Cheers,
> Michael
>
>
>
> _______________________________________________
> Taps mailing listTaps@ietf.orghttps://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
>
>

--001a1135e9b6ee744f04fce67e3e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Sounds like there are two points here worth teasing apart:=


1. "reliable erasure-free DELIVERY" vs "reliable error-=
free CONTENT that is delivered" are different




and=
=C2=A0




2. Each is a 'dimension' rather than a binary characteristic (li=
ke, say, in order delivery)




--aaron


On Sat, Jun 28, 2014 at 6:08 AM, Marie-Jose Montpetit <marie@mjmontpetit.com> wrote:



I would say that we s=
hould not limit it to one or the other but make it dependent on the applica=
tion requirement.



Marie-Jos=C3=A9 Montpetit




On Jun 28, 2014, at 5:31, <l.wood@surrey.ac.uk> wrote:






on reliability, are we talking of reliable erasure-free DELIVERY or reliabl=
e error-free CONTENT that is delivered?



Two dimensions here. We spent a few years debating the nuances in DTNRG.


e.g. TCP is thought to offer both, but its payload content check is weak. S=
CTP can vary delivery reliability, while its payload check is stronger. UDP=
-Lite doesn't give reliable delivery, its content check can vary, etc.



From: Taps <taps-bounces@ietf.org> on behalf of Anna B=
runstrom <ann=
a.brunstrom@kau.se>



Sent: Saturday, 28 June 2014 1:07:41 AM

To: taps@ietf.org=


Cc: bclaise@c=
isco.com; spencerdawkins.ietf@gmail.com

Subject: Re: [Taps] Charter bikeshed #1 - "transport service&qu=
ot;

=C2=A0




Hi,



Repeating one of my comments on the long mail to this more manageable versi=
on that Micheal produced while I was reading.



Anna 



On 2014-06-27 16:38, Michael Welzl wrote:




Hi,







I'll cut away a lot now, and only address things that need address=
ing below:
















On 27. juni 2014, at 16:21, Toby Moncaster <toby.moncaster@cl.cam.ac.uk&g=
t; wrote:






[snip]












I agree with Michael here. I think we could end up with a much less clearly=
 worded charter if we go down that route. If there is a need to be more pre=
cise then I=E2=80=99d favour adding something near the beginning of the cha=
rter along the lines of the definition I
 put in the Problem Statement document. Namely: =C2=A0"A Transport Service is any service provided by the tr=
ansport layer that can only be correctly implemented with information from =
the application.=E2=80=9DWe could then include 2 or
 3 example services 















I agree. Putting that definition in th=
ere would be nice.



































=C2=A0=C2=A0=C2=A0=C2=A0- full reliability










=C2=A0 =C2=A0 - latency-limited reliability

















Yes, reliability is a service, and fine to include in the list. But I&=
#39;d rather replace this with any of:


"various degrees of reliability" or "various forms of r=
eliability" or "full / latency-limited / no reliability"

...or something like that. =C2=A0One item, not two, anyway.


















Hmmm. I=E2=80=99d rather we had something like =E2=80=9CDegree of reli=
ability from unreliable to full reliability."














Agree.






























Second, using the phrase "congestion control" binds the appl=
ication requirement to a specific mechanism. I'd rather use something l=
ike "low delay vs. high throughput=E2=80=9D.













Perhaps this would best be expressed as =E2=80=9CTrading off latency a=
nd throughput"















Agree.



























I don't know if this list is correct or compl=
ete. This should be the WG

job to compile it.

Btw, adding this list to the charter, as a starting point, would make

sense.











So, to summarize, here's the complete list that I suggest:







- sequence preservation


- various degrees of reliability


- low delay vs. high throughput













I=E2=80=99d rephrase this as:







- ordering/sequence preservation


- degree of reliability=C2=A0


- latency vs throughput














Agree, this is nicer!






























How do we call the transport that support those 5=
 things? a transport

protocol? a transport service?

The "services" term is used multiple times within the charter.
Sometimes I understand it as a "transport protocol" (like in the =
first

sentence in the charter),

And sometimes I may interpret it as Brian's "dimensions of transpo=
rt" or

criteria.



Potentially use "criteria" and "transport protocol"

Alternatively, only use "transport services" when it means "=
criteria, and

"transport protocol".

I tried to do the latter below.














Again, detailed comments in line:












OLD:



Conjointly, transport protocols such as SCTP, DCCP, MPTCP,

UDP-Lite and the LEDBAT congestion control mechanism extend

the set of transport services that are available to

applications, beyond those provided by TCP and UDP. For

example, SCTP provides potentially faster reliable delivery

for applications that can accept blocks of data out of order,

and LEDBAT provides low-priority "scavenger" communication.



NEW:

Conjointly, transport protocols such as SCTP, DCCP, MPTCP,

UDP-Lite and the LEDBAT congestion control mechanism extend

the set of transport protocols that are available to

applications, beyond those provided by TCP and UDP. For

example, SCTP provides potentially faster reliable delivery

for applications that can accept blocks of data out of order,

and LEDBAT provides low-priority "scavenger" communication.










Disagree, I'd rather leave it as it is to stress that applications use =
services, not protocols.


















I actually think changing that to protocols might be a good thing, sin=
ce it highlights how complex the landscape has become.=C2=A0


















I disagree. The "For example" list gets very strange as examples =
of transport protocols. I also agree with Michael's original objection:=
 stressing that applications use services is important.














Okay, fine by me. I don't have a strong opinion here either way.




































OLD:



- Identify services provided by existing IETF transport protocols

=C2=A0=C2=A0and congestion control mechanisms. The resulting document will<=
br>
=C2=A0=C2=A0provide guidance on making a choice among available mechanisms<=
br>
=C2=A0=C2=A0and protocols to obtain a certain transport service.





NEW:



- Identify transport services provided by existing IETF transport

protocols

=C2=A0=C2=A0and congestion control mechanisms. The resulting document will<=
br>
=C2=A0=C2=A0provide guidance on making a choice among available mechanisms<=
br>
=C2=A0=C2=A0and protocols to obtain a certain transport service. As a start=
ing

point

=C2=A0=C2=A0for transport services, the working group can consider: message=


atomicity,

=C2=A0=C2=A0stream fragmentation, sequence preservation, head-of-line block=
ing

avoidance,

=C2=A0=C2=A0sub-channels, full reliability, latency-limited reliability,
loss-sensitive

=C2=A0=C2=A0congestion control, delay-sensitive congestion control, endpoin=
t

address agility,

=C2=A0=C2=A0privacy and integrity, and path-state propagation (NAT/Firewall=
).











Sentence 1: "transport services provided by .. =C2=A0transport pr=
otocols" doesn't seem to make things clearer. I'd rather keep =
"services" in this sentence - what this means gets concrete anywa=
y due to the list that follows in sentence 3, and there the phrase
 "transport services" is used anyway. The list should be changed,=
 as I argued above. I suggest:







NEW:







- Identify services provided by existing IETF transport protocols

=C2=A0 and congestion control mechanisms. The resulting document will

=C2=A0 provide guidance on making a choice among available mechanisms

=C2=A0 and protocols to obtain a certain transport service. As a starting p=
oint


=C2=A0 for transport services, the working group can consider: sequenc=
e


=C2=A0 preservation, various degrees of reliability, low delay vs. hig=
h throughput.















I think here we=E2=80=99re once again running into the difficulty of t=
he ambiguity of the word =E2=80=9Ctransport=E2=80=9D, especially in the IET=
F=E2=80=A6 If we have defined Transport Services in terms of the transport =
protocol earlier in the document, can we actually phrase this









- Identify Transport Services provided by IETF protocols and congestio=
n control mechanisms










Agreed


























OLD:

- Specify experimental mechanisms to deliver a transport service.

=C2=A0=C2=A0This will explain how to select and engage a protocol, and how<=
br>
=C2=A0=C2=A0to discover the availability of protocols on an interface (both=


=C2=A0=C2=A0end system and path support), in order to provide a basis for
=C2=A0=C2=A0incremental deployment.



NEW:

- Specify experimental mechanisms to deliver a transport protocol.

=C2=A0=C2=A0This will explain how to select and engage a protocol, and how<=
br>
=C2=A0=C2=A0to discover the availability of protocol services on an interfa=
ce (both



=C2=A0=C2=A0end system and path support), in order to provide a basis for
=C2=A0=C2=A0incremental deployment.















Disagree. "deliver a transport protocol" is weird. The intention =
was to say "provide a transport service", maybe "deliver&quo=
t; is a bad choice of words here? So I suggest:







NEW:

- Specify experimental mechanisms to provide a transport service.

=C2=A0 This will explain how to select and engage a protocol, and how

=C2=A0 to discover the availability of protocols on an interface (both

=C2=A0 end system and path support), in order to provide a basis for

=C2=A0 incremental deployment.













Specify experimental mechanisms to provide a given Transport Service.=
=C2=A0


This will explain how to select and engage an appropriate protocol and=
=C2=A0


how to discover which protocols are available for a given connection.=
=C2=A0


This will provide a basis for incremental deployment.











Agreed.


























=C2=A0"The Working Group will coordinate clo=
sely with other Working Groups and

IRTF Research Groups."

You should list the WGs you have in mind.











I agree that it looks odd as it stands. I'm not sure what the righ=
t approach is here (simply remove? or what are these groups?) - e.g. Spence=
r would know better than me=E2=80=A6


















I think the key thing here was that we aren=E2=80=99t only limiting ou=
rselves to working with the IETF but are also interested in getting input f=
rom the IRTF. However I think we can drop this










Agreed.







Cheers,


Michael











 


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











___________________=
____________________________
Taps mailing list
Taps@ietf.org


https://www.ietf.org/mailman/listinfo/taps

_______________________________________________<=
br>


Taps mailing list

Taps@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/taps





--001a1135e9b6ee744f04fce67e3e--


From nobody Sat Jun 28 10:12:38 2014
Return-Path: 
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8812E1A037C for ; Sat, 28 Jun 2014 10:12:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level: 
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 hGUH9YyVdPgE for ; Sat, 28 Jun 2014 10:12:30 -0700 (PDT)
Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7326B1A0380 for ; Sat, 28 Jun 2014 10:12:29 -0700 (PDT)
Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1X0wAt-0000fZ-Ms; Sat, 28 Jun 2014 19:12:27 +0200
Received: from 089144238254.atnat0047.highway.bob.at ([89.144.238.254] helo=[192.168.0.101]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1X0wAm-00055O-Fc; Sat, 28 Jun 2014 19:12:27 +0200
References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACAFDA.3060303@gmail.com> <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> <53AD74D8.9010906@gmail.com>  <33966B16-D15B-49E5-BEBD-C8DE990F8028@ifi.uio.no> <53AD88BD.6090003@kau.se> <0305821c865245e08cc4531ff66d9c7d@AMSPR06MB439.eurprd06.prod.outlook.com> <12FABC6F-187D-479C-8A72-4D1FBC5C25FC@mjmontpetit.com> 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: multipart/alternative; boundary=Apple-Mail-ACB4C3EB-53D4-4282-B510-BD8AAEEA44F9
Content-Transfer-Encoding: 7bit
Message-Id: 
X-Mailer: iPhone Mail (11D201)
From: Michael Welzl 
Date: Sat, 28 Jun 2014 19:12:07 +0200
To: Aaron Falk 
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 2 sum rcpts/h 12 sum msgs/h 3 total rcpts 17955 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: E5A6C016E7B5A63E833D3B6AE0F97631B1554936
X-UiO-SPAM-Test: remote_host: 89.144.238.254 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 71 max/h 5 blacklist 0 greylist 0 ratelimit 0
Archived-At: http://mailarchive.ietf.org/arch/msg/taps/0CK6FHkC-7jmCL9GyibnLReSCYY
Cc: "" , Marie-Jose Montpetit , "spencerdawkins.ietf@gmail.com" , "" , "bclaise@cisco.com" , "" 
Subject: Re: [Taps] Charter bikeshed #1 - "transport service"
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Jun 2014 17:12:35 -0000

--Apple-Mail-ACB4C3EB-53D4-4282-B510-BD8AAEEA44F9
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

one thing matters here, now: this is not about charter text, right?

Sent from my iPhone

> On 28. juni 2014, at 16:46, Aaron Falk  wrote:
>=20
> Sounds like there are two points here worth teasing apart:
>=20
> 1. "reliable erasure-free DELIVERY" vs "reliable error-free CONTENT that i=
s delivered" are different
>=20
> and=20
>=20
> 2. Each is a 'dimension' rather than a binary characteristic (like, say, i=
n order delivery)
>=20
> --aaron
>=20
>=20
>> On Sat, Jun 28, 2014 at 6:08 AM, Marie-Jose Montpetit  wrote:
>> I would say that we should not limit it to one or the other but make it d=
ependent on the application requirement.
>>=20
>> Marie-Jos=C3=A9 Montpetit
>> marie@mjmontpetit.com
>> mariejo@mit.edu
>>=20
>>> On Jun 28, 2014, at 5:31,  wrote:
>>>=20
>>> on reliability, are we talking of reliable erasure-free DELIVERY or reli=
able error-free CONTENT that is delivered?
>>>=20
>>> Two dimensions here. We spent a few years debating the nuances in DTNRG.=

>>>=20
>>> e.g. TCP is thought to offer both, but its payload content check is weak=
. SCTP can vary delivery reliability, while its payload check is stronger. U=
DP-Lite doesn't give reliable delivery, its content check can vary, etc. =20=

>>> From: Taps  on behalf of Anna Brunstrom 
>>> Sent: Saturday, 28 June 2014 1:07:41 AM
>>> To: taps@ietf.org
>>> Cc: bclaise@cisco.com; spencerdawkins.ietf@gmail.com
>>> Subject: Re: [Taps] Charter bikeshed #1 - "transport service"
>>> =20
>>> Hi,
>>>=20
>>> Repeating one of my comments on the long mail to this more manageable ve=
rsion that Micheal produced while I was reading.
>>>=20
>>> Anna=20
>>>=20
>>>> On 2014-06-27 16:38, Michael Welzl wrote:
>>>> Hi,
>>>>=20
>>>> I'll cut away a lot now, and only address things that need addressing b=
elow:
>>>>=20
>>>>=20
>>>> On 27. juni 2014, at 16:21, Toby Moncaster  wrote:
>>>>=20
>>>> [snip]
>>>>=20
>>>>> I agree with Michael here. I think we could end up with a much less cl=
early worded charter if we go down that route. If there is a need to be more=
 precise then I=E2=80=99d favour adding something near the beginning of the c=
harter along the lines of the definition I put in the Problem Statement docu=
ment. Namely:  "A Transport Service is any service provided by the transport=
 layer that can only be correctly implemented with information from the appl=
ication.=E2=80=9DWe could then include 2 or
>>>>>  3 example services=20
>>>>=20
>>>>=20
>>>> I agree. Putting that definition in there would be nice.
>>>>=20
>>>>=20
>>>>=20
>>>>>>>>>     - full reliability
>>>>>>>>>     - latency-limited reliability
>>>>>>>=20
>>>>>>> Yes, reliability is a service, and fine to include in the list. But I=
'd rather replace this with any of:
>>>>>>> "various degrees of reliability" or "various forms of reliability" o=
r "full / latency-limited / no reliability"
>>>>>>> ...or something like that.  One item, not two, anyway.
>>>>>=20
>>>>>=20
>>>>> Hmmm. I=E2=80=99d rather we had something like =E2=80=9CDegree of reli=
ability from unreliable to full reliability."
>>>>=20
>>>> Agree.
>>>>=20
>>>>=20
>>>>>>> Second, using the phrase "congestion control" binds the application r=
equirement to a specific mechanism. I'd rather use something like "low delay=
 vs. high throughput=E2=80=9D.
>>>>>=20
>>>>> Perhaps this would best be expressed as =E2=80=9CTrading off latency a=
nd throughput"
>>>>=20
>>>> Agree.
>>>>=20
>>>>=20
>>>>>>>>> I don't know if this list is correct or complete. This should be t=
he WG
>>>>>>>>> job to compile it.
>>>>>>>>> Btw, adding this list to the charter, as a starting point, would m=
ake
>>>>>>>>> sense.
>>>>>>>=20
>>>>>>> So, to summarize, here's the complete list that I suggest:
>>>>>>>=20
>>>>>>> - sequence preservation
>>>>>>> - various degrees of reliability
>>>>>>> - low delay vs. high throughput
>>>>>=20
>>>>> I=E2=80=99d rephrase this as:
>>>>>=20
>>>>> - ordering/sequence preservation
>>>>> - degree of reliability=20
>>>>> - latency vs throughput
>>>>=20
>>>> Agree, this is nicer!
>>>>=20
>>>>=20
>>>>>>>>> How do we call the transport that support those 5 things? a transp=
ort
>>>>>>>>> protocol? a transport service?
>>>>>>>>> The "services" term is used multiple times within the charter.
>>>>>>>>> Sometimes I understand it as a "transport protocol" (like in the f=
irst
>>>>>>>>> sentence in the charter),
>>>>>>>>> And sometimes I may interpret it as Brian's "dimensions of transpo=
rt" or
>>>>>>>>> criteria.
>>>>>>>>>=20
>>>>>>>>> Potentially use "criteria" and "transport protocol"
>>>>>>>>> Alternatively, only use "transport services" when it means "criter=
ia, and
>>>>>>>>> "transport protocol".
>>>>>>>>> I tried to do the latter below.
>>>>>>>=20
>>>>>>> Again, detailed comments in line:
>>>>>>>=20
>>>>>>>=20
>>>>>>>>> OLD:
>>>>>>>>>=20
>>>>>>>>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
>>>>>>>>> UDP-Lite and the LEDBAT congestion control mechanism extend
>>>>>>>>> the set of transport services that are available to
>>>>>>>>> applications, beyond those provided by TCP and UDP. For
>>>>>>>>> example, SCTP provides potentially faster reliable delivery
>>>>>>>>> for applications that can accept blocks of data out of order,
>>>>>>>>> and LEDBAT provides low-priority "scavenger" communication.
>>>>>>>>>=20
>>>>>>>>> NEW:
>>>>>>>>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
>>>>>>>>> UDP-Lite and the LEDBAT congestion control mechanism extend
>>>>>>>>> the set of transport protocols that are available to
>>>>>>>>> applications, beyond those provided by TCP and UDP. For
>>>>>>>>> example, SCTP provides potentially faster reliable delivery
>>>>>>>>> for applications that can accept blocks of data out of order,
>>>>>>>>> and LEDBAT provides low-priority "scavenger" communication.
>>>>>>>=20
>>>>>>> Disagree, I'd rather leave it as it is to stress that applications u=
se services, not protocols.
>>>>>=20
>>>>>=20
>>>>> I actually think changing that to protocols might be a good thing, sin=
ce it highlights how complex the landscape has become.=20
>>>=20
>>> I disagree. The "For example" list gets very strange as examples of tran=
sport protocols. I also agree with Michael's original objection: stressing t=
hat applications use services is important.
>>>=20
>>>=20
>>>=20
>>>> Okay, fine by me. I don't have a strong opinion here either way.
>>>>=20
>>>>=20
>>>>>>>>> OLD:
>>>>>>>>>=20
>>>>>>>>> - Identify services provided by existing IETF transport protocols
>>>>>>>>>   and congestion control mechanisms. The resulting document will
>>>>>>>>>   provide guidance on making a choice among available mechanisms
>>>>>>>>>   and protocols to obtain a certain transport service.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> NEW:
>>>>>>>>>=20
>>>>>>>>> - Identify transport services provided by existing IETF transport
>>>>>>>>> protocols
>>>>>>>>>   and congestion control mechanisms. The resulting document will
>>>>>>>>>   provide guidance on making a choice among available mechanisms
>>>>>>>>>   and protocols to obtain a certain transport service. As a starti=
ng
>>>>>>>>> point
>>>>>>>>>   for transport services, the working group can consider: message
>>>>>>>>> atomicity,
>>>>>>>>>   stream fragmentation, sequence preservation, head-of-line blocki=
ng
>>>>>>>>> avoidance,
>>>>>>>>>   sub-channels, full reliability, latency-limited reliability,
>>>>>>>>> loss-sensitive
>>>>>>>>>   congestion control, delay-sensitive congestion control, endpoint=

>>>>>>>>> address agility,
>>>>>>>>>   privacy and integrity, and path-state propagation (NAT/Firewall)=
.
>>>>>>>=20
>>>>>>> Sentence 1: "transport services provided by ..  transport protocols"=
 doesn't seem to make things clearer. I'd rather keep "services" in this sen=
tence - what this means gets concrete anyway due to the list that follows in=
 sentence 3, and there the phrase "transport services" is used anyway. The l=
ist should be changed, as I argued above. I suggest:
>>>>>>>=20
>>>>>>> NEW:
>>>>>>>=20
>>>>>>> - Identify services provided by existing IETF transport protocols
>>>>>>>   and congestion control mechanisms. The resulting document will
>>>>>>>   provide guidance on making a choice among available mechanisms
>>>>>>>   and protocols to obtain a certain transport service. As a starting=
 point
>>>>>>>   for transport services, the working group can consider: sequence
>>>>>>>   preservation, various degrees of reliability, low delay vs. high t=
hroughput.
>>>>>=20
>>>>> I think here we=E2=80=99re once again running into the difficulty of t=
he ambiguity of the word =E2=80=9Ctransport=E2=80=9D, especially in the IETF=E2=
=80=A6 If we have defined Transport Services in terms of the transport proto=
col earlier in the document, can we actually phrase this
>>>>>=20
>>>>> - Identify Transport Services provided by IETF protocols and congestio=
n control mechanisms
>>>>=20
>>>> Agreed
>>>>=20
>>>>=20
>>>>>>>>> OLD:
>>>>>>>>> - Specify experimental mechanisms to deliver a transport service.
>>>>>>>>>   This will explain how to select and engage a protocol, and how
>>>>>>>>>   to discover the availability of protocols on an interface (both
>>>>>>>>>   end system and path support), in order to provide a basis for
>>>>>>>>>   incremental deployment.
>>>>>>>>>=20
>>>>>>>>> NEW:
>>>>>>>>> - Specify experimental mechanisms to deliver a transport protocol.=

>>>>>>>>>   This will explain how to select and engage a protocol, and how
>>>>>>>>>   to discover the availability of protocol services on an interfac=
e (both
>>>>>>>>>=20
>>>>>>>>>   end system and path support), in order to provide a basis for
>>>>>>>>>   incremental deployment.
>>>>>>>=20
>>>>>>>=20
>>>>>>> Disagree. "deliver a transport protocol" is weird. The intention was=
 to say "provide a transport service", maybe "deliver" is a bad choice of wo=
rds here? So I suggest:
>>>>>>>=20
>>>>>>> NEW:
>>>>>>> - Specify experimental mechanisms to provide a transport service.
>>>>>>>   This will explain how to select and engage a protocol, and how
>>>>>>>   to discover the availability of protocols on an interface (both
>>>>>>>   end system and path support), in order to provide a basis for
>>>>>>>   incremental deployment.
>>>>>=20
>>>>> Specify experimental mechanisms to provide a given Transport Service.=20=

>>>>> This will explain how to select and engage an appropriate protocol and=
=20
>>>>> how to discover which protocols are available for a given connection.=20=

>>>>> This will provide a basis for incremental deployment.
>>>>=20
>>>> Agreed.
>>>>=20
>>>>=20
>>>>>>>>>  "The Working Group will coordinate closely with other Working Gro=
ups and
>>>>>>>>> IRTF Research Groups."
>>>>>>>>> You should list the WGs you have in mind.
>>>>>>>=20
>>>>>>> I agree that it looks odd as it stands. I'm not sure what the right a=
pproach is here (simply remove? or what are these groups?) - e.g. Spencer wo=
uld know better than me=E2=80=A6
>>>>>=20
>>>>>=20
>>>>> I think the key thing here was that we aren=E2=80=99t only limiting ou=
rselves to working with the IETF but are also interested in getting input fr=
om the IRTF. However I think we can drop this
>>>>=20
>>>> Agreed.
>>>>=20
>>>> Cheers,
>>>> Michael
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> Taps mailing list
>>>> Taps@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/taps
>>>=20
>>> _______________________________________________
>>> Taps mailing list
>>> Taps@ietf.org
>>> https://www.ietf.org/mailman/listinfo/taps
>>=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

--Apple-Mail-ACB4C3EB-53D4-4282-B510-BD8AAEEA44F9
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


one thing matters here, now: this is n=
ot about charter text, right?

Sent from my iPhone

On 28=
. juni 2014, at 16:46, Aaron Falk <falk-ietf@dgftech.com> wrote:

Sounds like there are two points here worth teasing=
 apart:

1. "reliable erasure-free DELIVERY" vs "reliable error-free CONTE=
NT that is delivered" are different




=

and&n=
bsp;




2. Each is a 'dimension' rather than a binary characteristic (like, say, i=
n order delivery)




--aaron


On Sat, Jun 28, 2014 at 6:08 AM, Marie-Jose Montpetit <mar=
ie@mjmontpetit.com> wrote:



I would say that we sho=
uld not limit it to one or the other but make it dependent on the applicatio=
n requirement.



Marie-Jos=C3=A9 Montpetit




On Jun 28, 2014, at 5:31, <l.wood@surrey.ac.uk> wrote:






on reliability, are we talking of reliable erasure-free DELIVERY or reliable=
 error-free CONTENT that is delivered?



Two dimensions here. We spent a few years debating the nuances in DTNRG.
=



e.g. TCP is thought to offer both, but its payload content check is weak. SC=
TP can vary delivery reliability, while its payload check is stronger. UDP-L=
ite doesn't give reliable delivery, its content check can vary, etc.



From: Taps <taps-bounces@ietf.org> on behalf of Anna Brun=
strom <anna.br=
unstrom@kau.se>



Sent: Saturday, 28 June 2014 1:07:41 AM

To: taps@ietf.org<=
/a>

Cc: bclaise@ci=
sco.com; spencerdawkins.ietf@gmail.com

Subject: Re: [Taps] Charter bikeshed #1 - "transport service"

 




Hi,



Repeating one of my comments on the long mail to this more manageable versio=
n that Micheal produced while I was reading.



Anna 



On 2014-06-27 16:38, Michael Welzl wrote:




Hi,







I'll cut away a lot now, and only address things that need addressing b=
elow:
















On 27. juni 2014, at 16:21, Toby Moncaster <toby.moncaster@cl.cam.ac.uk>=
 wrote:






[snip]












I agree with Michael here. I think we could end up with a much less clearly w=
orded charter if we go down that route. If there is a need to be more precis=
e then I=E2=80=99d favour adding something near the beginning of the charter=
 along the lines of the definition I
 put in the Problem Statement document. Namely:  "A Transport Service is any service provided by the transport=
 layer that can only be correctly implemented with information from the appl=
ication.=E2=80=9DWe could then include 2 or
 3 example services 















I agree. Putting that definition in the=
re would be nice.



































    - full reliability










    - latency-limited reliability

















Yes, reliability is a service, and fine to include in the list. But I'd=
 rather replace this with any of:


"various degrees of reliability" or "various forms of reliability" or "=
full / latency-limited / no reliability"


...or something like that.  One item, not two, anyway.


















Hmmm. I=E2=80=99d rather we had something like =E2=80=9CDegree of relia=
bility from unreliable to full reliability."














Agree.






























Second, using the phrase "congestion control" binds the application req=
uirement to a specific mechanism. I'd rather use something like "low delay v=
s. high throughput=E2=80=9D.













Perhaps this would best be expressed as =E2=80=9CTrading off latency an=
d throughput"















Agree.



























I don't know if this list is correct or complete. T=
his should be the WG

job to compile it.

Btw, adding this list to the charter, as a starting point, would make

sense.











So, to summarize, here's the complete list that I suggest:







- sequence preservation


- various degrees of reliability


- low delay vs. high throughput













I=E2=80=99d rephrase this as:







- ordering/sequence preservation


- degree of reliability 


- latency vs throughput














Agree, this is nicer!






























How do we call the transport that support those 5 t=
hings? a transport

protocol? a transport service?

The "services" term is used multiple times within the charter.

Sometimes I understand it as a "transport protocol" (like in the first

sentence in the charter),

And sometimes I may interpret it as Brian's "dimensions of transport" or
=

criteria.



Potentially use "criteria" and "transport protocol"

Alternatively, only use "transport services" when it means "criteria, and
"transport protocol".

I tried to do the latter below.














Again, detailed comments in line:












OLD:



Conjointly, transport protocols such as SCTP, DCCP, MPTCP,

UDP-Lite and the LEDBAT congestion control mechanism extend

the set of transport services that are available to

applications, beyond those provided by TCP and UDP. For

example, SCTP provides potentially faster reliable delivery

for applications that can accept blocks of data out of order,

and LEDBAT provides low-priority "scavenger" communication.



NEW:

Conjointly, transport protocols such as SCTP, DCCP, MPTCP,

UDP-Lite and the LEDBAT congestion control mechanism extend

the set of transport protocols that are available to

applications, beyond those provided by TCP and UDP. For

example, SCTP provides potentially faster reliable delivery

for applications that can accept blocks of data out of order,

and LEDBAT provides low-priority "scavenger" communication.










Disagree, I'd rather leave it as it is to stress that applications use servi=
ces, not protocols.


















I actually think changing that to protocols might be a good thing, sinc=
e it highlights how complex the landscape has become. 


















I disagree. The "For example" list gets very strange as examples of transpor=
t protocols. I also agree with Michael's original objection: stressing that a=
pplications use services is important.














Okay, fine by me. I don't have a strong opinion here either way.





































OLD:



- Identify services provided by existing IETF transport protocols

  and congestion control mechanisms. The resulting document will
  provide guidance on making a choice among available mechanisms
  and protocols to obtain a certain transport service.





NEW:



- Identify transport services provided by existing IETF transport

protocols

  and congestion control mechanisms. The resulting document will
  provide guidance on making a choice among available mechanisms
  and protocols to obtain a certain transport service. As a starti=
ng

point

  for transport services, the working group can consider: message<=
br>
atomicity,

  stream fragmentation, sequence preservation, head-of-line blocki=
ng

avoidance,

  sub-channels, full reliability, latency-limited reliability,
=

loss-sensitive

  congestion control, delay-sensitive congestion control, endpoint=


address agility,

  privacy and integrity, and path-state propagation (NAT/Firewall)=
.











Sentence 1: "transport services provided by ..  transport protocol=
s" doesn't seem to make things clearer. I'd rather keep "services" in this s=
entence - what this means gets concrete anyway due to the list that follows i=
n sentence 3, and there the phrase
 "transport services" is used anyway. The list should be changed, as I argue=
d above. I suggest:







NEW:







- Identify services provided by existing IETF transport protocols

  and congestion control mechanisms. The resulting document will

  provide guidance on making a choice among available mechanisms

  and protocols to obtain a certain transport service. As a starting po=
int


  for transport services, the working group can consider: sequence=



  preservation, various degrees of reliability, low delay vs. high=
 throughput.















I think here we=E2=80=99re once again running into the difficulty of th=
e ambiguity of the word =E2=80=9Ctransport=E2=80=9D, especially in the IETF=E2=
=80=A6 If we have defined Transport Services in terms of the transport proto=
col earlier in the document, can we actually phrase this









- Identify Transport Services provided by IETF protocols and congestion=
 control mechanisms










Agreed


























OLD:

- Specify experimental mechanisms to deliver a transport service.

  This will explain how to select and engage a protocol, and how
  to discover the availability of protocols on an interface (both<=
br>
  end system and path support), in order to provide a basis for
  incremental deployment.



NEW:

- Specify experimental mechanisms to deliver a transport protocol.

  This will explain how to select and engage a protocol, and how
  to discover the availability of protocol services on an interfac=
e (both



  end system and path support), in order to provide a basis for
  incremental deployment.















Disagree. "deliver a transport protocol" is weird. The intention was to say "=
provide a transport service", maybe "deliver" is a bad choice of words here?=
 So I suggest:







NEW:

- Specify experimental mechanisms to provide a transport service.

  This will explain how to select and engage a protocol, and how

  to discover the availability of protocols on an interface (both

  end system and path support), in order to provide a basis for

  incremental deployment.













Specify experimental mechanisms to provide a given Transport Service.&n=
bsp;


This will explain how to select and engage an appropriate protocol and&=
nbsp;


how to discover which protocols are available for a given connection.&n=
bsp;


This will provide a basis for incremental deployment.











Agreed.


























 "The Working Group will coordinate closely w=
ith other Working Groups and

IRTF Research Groups."

You should list the WGs you have in mind.











I agree that it looks odd as it stands. I'm not sure what the right app=
roach is here (simply remove? or what are these groups?) - e.g. Spencer woul=
d know better than me=E2=80=A6


















I think the key thing here was that we aren=E2=80=99t only limiting our=
selves to working with the IETF but are also interested in getting input fro=
m the IRTF. However I think we can drop this










Agreed.







Cheers,


Michael











 


_______________________________________________
Taps mailing list
Taps@ietf.org
htt=
ps://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

htt=
ps://www.ietf.org/mailman/listinfo/taps





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

--Apple-Mail-ACB4C3EB-53D4-4282-B510-BD8AAEEA44F9--


From nobody Sun Jun 29 02:42:56 2014
Return-Path: 
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41911A0444 for ; Sun, 29 Jun 2014 02:42:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level: 
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 wIO8XSljzYF1 for ; Sun, 29 Jun 2014 02:42:49 -0700 (PDT)
Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 C84D11A043D for ; Sun, 29 Jun 2014 02:42:48 -0700 (PDT)
Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1X1BdE-0008BF-6l; Sun, 29 Jun 2014 11:42:44 +0200
Received: from 089144222109.atnat0031.highway.bob.at ([89.144.222.109] helo=[192.168.0.100]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1X1Bcu-0007vc-HO; Sun, 29 Jun 2014 11:42:44 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail=_B9842C65-BB1A-4F81-A521-BDCFAF65F8F0"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Michael Welzl 
In-Reply-To: 
Date: Sun, 29 Jun 2014 11:42:17 +0200
Message-Id: <01441810-A702-4DC2-B74C-6C0DC6F5235B@ifi.uio.no>
References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACAFDA.3060303@gmail.com> <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> <53AD74D8.9010906@gmail.com>  <33966B16-D15B-49E5-BEBD-C8DE990F8028@ifi.uio.no> <53AD88BD.6090003@kau.se> <0305821c865245e08cc4531ff66d9c7d@AMSPR06MB439.eurprd06.prod.outlook.com> <12FABC6F-187D-479C-8A72-4D1FBC5C25FC@mjmontpetit.com>  
To: Aaron Falk 
X-Mailer: Apple Mail (2.1878.2)
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 1 sum rcpts/h 8 sum msgs/h 2 total rcpts 17968 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 07D099901BF073E8C95F0EE618FFCD1978D9D4EB
X-UiO-SPAM-Test: remote_host: 89.144.222.109 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 4 max/h 2 blacklist 0 greylist 0 ratelimit 0
Archived-At: http://mailarchive.ietf.org/arch/msg/taps/gCOlwOmdxdERmJsIQPLv-1tPcSY
Cc: "" , Marie-Jose Montpetit , Spencer Dawkins , "" , "bclaise@cisco.com" , "" 
Subject: Re: [Taps] Charter bikeshed #1 - "transport service"
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Jun 2014 09:42:54 -0000

--Apple-Mail=_B9842C65-BB1A-4F81-A521-BDCFAF65F8F0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

If noone reacts by tomorrow, I'd suggest to assume the list's charter =
discussion has converged with Anna's last message.

I didn't want to kill off this discussion, however. I'll answer Aaron's =
email but with a different subject  :-)

Cheers,
Michael


On 28. juni 2014, at 19:12, Michael Welzl  wrote:

> one thing matters here, now: this is not about charter text, right?
>=20
> Sent from my iPhone
>=20
> On 28. juni 2014, at 16:46, Aaron Falk  wrote:
>=20
>> Sounds like there are two points here worth teasing apart:
>>=20
>> 1. "reliable erasure-free DELIVERY" vs "reliable error-free CONTENT =
that is delivered" are different
>>=20
>> and=20
>>=20
>> 2. Each is a 'dimension' rather than a binary characteristic (like, =
say, in order delivery)
>>=20
>> --aaron
>>=20
>>=20
>> On Sat, Jun 28, 2014 at 6:08 AM, Marie-Jose Montpetit =
 wrote:
>> I would say that we should not limit it to one or the other but make =
it dependent on the application requirement.
>>=20
>> Marie-Jos=E9 Montpetit
>> marie@mjmontpetit.com
>> mariejo@mit.edu
>>=20
>> On Jun 28, 2014, at 5:31,  wrote:
>>=20
>>> on reliability, are we talking of reliable erasure-free DELIVERY or =
reliable error-free CONTENT that is delivered?
>>>=20
>>> Two dimensions here. We spent a few years debating the nuances in =
DTNRG.
>>>=20
>>> e.g. TCP is thought to offer both, but its payload content check is =
weak. SCTP can vary delivery reliability, while its payload check is =
stronger. UDP-Lite doesn't give reliable delivery, its content check can =
vary, etc.=20
>>> From: Taps  on behalf of Anna Brunstrom =

>>> Sent: Saturday, 28 June 2014 1:07:41 AM
>>> To: taps@ietf.org
>>> Cc: bclaise@cisco.com; spencerdawkins.ietf@gmail.com
>>> Subject: Re: [Taps] Charter bikeshed #1 - "transport service"
>>> =20
>>> Hi,
>>>=20
>>> Repeating one of my comments on the long mail to this more =
manageable version that Micheal produced while I was reading.
>>>=20
>>> Anna=20
>>>=20
>>> On 2014-06-27 16:38, Michael Welzl wrote:
>>>> Hi,
>>>>=20
>>>> I'll cut away a lot now, and only address things that need =
addressing below:
>>>>=20
>>>>=20
>>>> On 27. juni 2014, at 16:21, Toby Moncaster =
 wrote:
>>>>=20
>>>> [snip]
>>>>=20
>>>>> I agree with Michael here. I think we could end up with a much =
less clearly worded charter if we go down that route. If there is a need =
to be more precise then I=92d favour adding something near the beginning =
of the charter along the lines of the definition I put in the Problem =
Statement document. Namely:  "A Transport Service is any service =
provided by the transport layer that can only be correctly implemented =
with information from the application.=94We could then include 2 or
>>>>>  3 example services=20
>>>>=20
>>>>=20
>>>> I agree. Putting that definition in there would be nice.
>>>>=20
>>>>=20
>>>>=20
>>>>>>>>>     - full reliability
>>>>>>>>>     - latency-limited reliability
>>>>>>>>=20
>>>>>>>=20
>>>>>>> Yes, reliability is a service, and fine to include in the list. =
But I'd rather replace this with any of:
>>>>>>> "various degrees of reliability" or "various forms of =
reliability" or "full / latency-limited / no reliability"
>>>>>>> ...or something like that.  One item, not two, anyway.
>>>>>=20
>>>>>=20
>>>>> Hmmm. I=92d rather we had something like =93Degree of reliability =
from unreliable to full reliability."
>>>>=20
>>>> Agree.
>>>>=20
>>>>=20
>>>>>>> Second, using the phrase "congestion control" binds the =
application requirement to a specific mechanism. I'd rather use =
something like "low delay vs. high throughput=94.
>>>>>=20
>>>>> Perhaps this would best be expressed as =93Trading off latency and =
throughput"
>>>>=20
>>>> Agree.
>>>>=20
>>>>=20
>>>>>>>>> I don't know if this list is correct or complete. This should =
be the WG
>>>>>>>>> job to compile it.
>>>>>>>>> Btw, adding this list to the charter, as a starting point, =
would make
>>>>>>>>> sense.
>>>>>>>=20
>>>>>>> So, to summarize, here's the complete list that I suggest:
>>>>>>>=20
>>>>>>> - sequence preservation
>>>>>>> - various degrees of reliability
>>>>>>> - low delay vs. high throughput
>>>>>=20
>>>>> I=92d rephrase this as:
>>>>>=20
>>>>> - ordering/sequence preservation
>>>>> - degree of reliability=20
>>>>> - latency vs throughput
>>>>=20
>>>> Agree, this is nicer!
>>>>=20
>>>>=20
>>>>>>>>> How do we call the transport that support those 5 things? a =
transport
>>>>>>>>> protocol? a transport service?
>>>>>>>>> The "services" term is used multiple times within the charter.
>>>>>>>>> Sometimes I understand it as a "transport protocol" (like in =
the first
>>>>>>>>> sentence in the charter),
>>>>>>>>> And sometimes I may interpret it as Brian's "dimensions of =
transport" or
>>>>>>>>> criteria.
>>>>>>>>>=20
>>>>>>>>> Potentially use "criteria" and "transport protocol"
>>>>>>>>> Alternatively, only use "transport services" when it means =
"criteria, and
>>>>>>>>> "transport protocol".
>>>>>>>>> I tried to do the latter below.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>=20
>>>>>>> Again, detailed comments in line:
>>>>>>>=20
>>>>>>>=20
>>>>>>>>> OLD:
>>>>>>>>>=20
>>>>>>>>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
>>>>>>>>> UDP-Lite and the LEDBAT congestion control mechanism extend
>>>>>>>>> the set of transport services that are available to
>>>>>>>>> applications, beyond those provided by TCP and UDP. For
>>>>>>>>> example, SCTP provides potentially faster reliable delivery
>>>>>>>>> for applications that can accept blocks of data out of order,
>>>>>>>>> and LEDBAT provides low-priority "scavenger" communication.
>>>>>>>>>=20
>>>>>>>>> NEW:
>>>>>>>>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
>>>>>>>>> UDP-Lite and the LEDBAT congestion control mechanism extend
>>>>>>>>> the set of transport protocols that are available to
>>>>>>>>> applications, beyond those provided by TCP and UDP. For
>>>>>>>>> example, SCTP provides potentially faster reliable delivery
>>>>>>>>> for applications that can accept blocks of data out of order,
>>>>>>>>> and LEDBAT provides low-priority "scavenger" communication.
>>>>>>>=20
>>>>>>> Disagree, I'd rather leave it as it is to stress that =
applications use services, not protocols.
>>>>>=20
>>>>>=20
>>>>> I actually think changing that to protocols might be a good thing, =
since it highlights how complex the landscape has become.=20
>>>>=20
>>>=20
>>> I disagree. The "For example" list gets very strange as examples of =
transport protocols. I also agree with Michael's original objection: =
stressing that applications use services is important.
>>>=20
>>>=20
>>>=20
>>>> Okay, fine by me. I don't have a strong opinion here either way.
>>>>=20
>>>>=20
>>>>>>>>> OLD:
>>>>>>>>>=20
>>>>>>>>> - Identify services provided by existing IETF transport =
protocols
>>>>>>>>>   and congestion control mechanisms. The resulting document =
will
>>>>>>>>>   provide guidance on making a choice among available =
mechanisms
>>>>>>>>>   and protocols to obtain a certain transport service.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> NEW:
>>>>>>>>>=20
>>>>>>>>> - Identify transport services provided by existing IETF =
transport
>>>>>>>>> protocols
>>>>>>>>>   and congestion control mechanisms. The resulting document =
will
>>>>>>>>>   provide guidance on making a choice among available =
mechanisms
>>>>>>>>>   and protocols to obtain a certain transport service. As a =
starting
>>>>>>>>> point
>>>>>>>>>   for transport services, the working group can consider: =
message
>>>>>>>>> atomicity,
>>>>>>>>>   stream fragmentation, sequence preservation, head-of-line =
blocking
>>>>>>>>> avoidance,
>>>>>>>>>   sub-channels, full reliability, latency-limited reliability,
>>>>>>>>> loss-sensitive
>>>>>>>>>   congestion control, delay-sensitive congestion control, =
endpoint
>>>>>>>>> address agility,
>>>>>>>>>   privacy and integrity, and path-state propagation =
(NAT/Firewall).
>>>>>>>=20
>>>>>>> Sentence 1: "transport services provided by ..  transport =
protocols" doesn't seem to make things clearer. I'd rather keep =
"services" in this sentence - what this means gets concrete anyway due =
to the list that follows in sentence 3, and there the phrase "transport =
services" is used anyway. The list should be changed, as I argued above. =
I suggest:
>>>>>>>=20
>>>>>>> NEW:
>>>>>>>=20
>>>>>>> - Identify services provided by existing IETF transport =
protocols
>>>>>>>   and congestion control mechanisms. The resulting document will
>>>>>>>   provide guidance on making a choice among available mechanisms
>>>>>>>   and protocols to obtain a certain transport service. As a =
starting point
>>>>>>>   for transport services, the working group can consider: =
sequence
>>>>>>>   preservation, various degrees of reliability, low delay vs. =
high throughput.
>>>>>=20
>>>>> I think here we=92re once again running into the difficulty of the =
ambiguity of the word =93transport=94, especially in the IETF=85 If we =
have defined Transport Services in terms of the transport protocol =
earlier in the document, can we actually phrase this
>>>>>=20
>>>>> - Identify Transport Services provided by IETF protocols and =
congestion control mechanisms
>>>>=20
>>>> Agreed
>>>>=20
>>>>=20
>>>>>>>>> OLD:
>>>>>>>>> - Specify experimental mechanisms to deliver a transport =
service.
>>>>>>>>>   This will explain how to select and engage a protocol, and =
how
>>>>>>>>>   to discover the availability of protocols on an interface =
(both
>>>>>>>>>   end system and path support), in order to provide a basis =
for
>>>>>>>>>   incremental deployment.
>>>>>>>>>=20
>>>>>>>>> NEW:
>>>>>>>>> - Specify experimental mechanisms to deliver a transport =
protocol.
>>>>>>>>>   This will explain how to select and engage a protocol, and =
how
>>>>>>>>>   to discover the availability of protocol services on an =
interface (both
>>>>>>>>>=20
>>>>>>>>>   end system and path support), in order to provide a basis =
for
>>>>>>>>>   incremental deployment.
>>>>>>>=20
>>>>>>>=20
>>>>>>> Disagree. "deliver a transport protocol" is weird. The intention =
was to say "provide a transport service", maybe "deliver" is a bad =
choice of words here? So I suggest:
>>>>>>>=20
>>>>>>> NEW:
>>>>>>> - Specify experimental mechanisms to provide a transport =
service.
>>>>>>>   This will explain how to select and engage a protocol, and how
>>>>>>>   to discover the availability of protocols on an interface =
(both
>>>>>>>   end system and path support), in order to provide a basis for
>>>>>>>   incremental deployment.
>>>>>=20
>>>>> Specify experimental mechanisms to provide a given Transport =
Service.=20
>>>>> This will explain how to select and engage an appropriate protocol =
and=20
>>>>> how to discover which protocols are available for a given =
connection.=20
>>>>> This will provide a basis for incremental deployment.
>>>>=20
>>>> Agreed.
>>>>=20
>>>>=20
>>>>>>>>>  "The Working Group will coordinate closely with other Working =
Groups and
>>>>>>>>> IRTF Research Groups."
>>>>>>>>> You should list the WGs you have in mind.
>>>>>>>=20
>>>>>>> I agree that it looks odd as it stands. I'm not sure what the =
right approach is here (simply remove? or what are these groups?) - e.g. =
Spencer would know better than me=85
>>>>>=20
>>>>>=20
>>>>> I think the key thing here was that we aren=92t only limiting =
ourselves to working with the IETF but are also interested in getting =
input from the IRTF. However I think we can drop this
>>>>=20
>>>> Agreed.
>>>>=20
>>>> Cheers,
>>>> Michael
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> Taps mailing list
>>>> Taps@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/taps
>>>=20
>>> _______________________________________________
>>> Taps mailing list
>>> Taps@ietf.org
>>> https://www.ietf.org/mailman/listinfo/taps
>>=20
>> _______________________________________________
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
>>=20
>>=20
>> _______________________________________________
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps


--Apple-Mail=_B9842C65-BB1A-4F81-A521-BDCFAF65F8F0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

If =
noone reacts by tomorrow, I'd suggest to assume the list's charter =
discussion has converged with Anna's last message.

I =
didn't want to kill off this discussion, however. I'll answer Aaron's =
email but with a different subject =
 :-)

Cheers,
Michael

On 28. juni 2014, at 19:12, Michael Welzl =
<michawe@ifi.uio.no> =
wrote:

one thing matters here, now: =
this is not about charter text, right?

Sent from my =
iPhone

On 28. juni 2014, at 16:46, Aaron Falk <falk-ietf@dgftech.com> =
wrote:

Sounds =
like there are two points here worth teasing =
apart:

1. "reliable =
erasure-free DELIVERY" vs "reliable error-free CONTENT that is =
delivered" are different




and 




2. Each is a =
'dimension' rather than a binary characteristic (like, say, in order =
delivery)




--aaron
=



On =
Sat, Jun 28, 2014 at 6:08 AM, Marie-Jose Montpetit <marie@mjmontpetit.com> wrote:



I=
 would say that we should not limit it to one or the other but make it =
dependent on the application requirement.



Marie-Jos=E9 Montpetit




On Jun 28, 2014, at 5:31, <l.wood@surrey.ac.uk> =
wrote:






on reliability, are we talking of reliable erasure-free DELIVERY or =
reliable error-free CONTENT that is delivered?



Two dimensions here. We spent a few years debating the nuances in =
DTNRG.



e.g. TCP is thought to offer both, but its payload content check is =
weak. SCTP can vary delivery reliability, while its payload check is =
stronger. UDP-Lite doesn't give reliable delivery, its content check can =
vary, etc.



From: Taps <taps-bounces@ietf.org> on behalf of Anna =
Brunstrom <anna.brunstrom@kau.se>



Sent: Saturday, 28 June 2014 1:07:41 AM

To: taps@ietf.org

Cc: bclaise@cisco.com; spencerdawkins.ietf@gmail.com

Subject: Re: [Taps] Charter bikeshed #1 - "transport =
service"

 




Hi,



Repeating one of my comments on the long mail to this more manageable =
version that Micheal produced while I was reading.



Anna 



On 2014-06-27 16:38, Michael Welzl wrote:




Hi,







I'll cut away a lot now, and only address things that need =
addressing below:
















On 27. juni 2014, at 16:21, Toby Moncaster <toby.moncaster@cl.cam.ac.uk> wrote:






[snip]












I agree with Michael here. I think we could end up with a much less =
clearly worded charter if we go down that route. If there is a need to =
be more precise then I=92d favour adding something near the beginning of =
the charter along the lines of the definition I
 put in the Problem Statement document. Namely:  "A Transport Service is any service =
provided by the transport layer that can only be correctly implemented =
with information from the application.=94We could then include 2 or
 3 example services 















I agree. Putting that definition in =
there would be nice.



































    - full reliability










    - latency-limited =
reliability

















Yes, reliability is a service, and fine to include in the list. But =
I'd rather replace this with any of:


"various degrees of reliability" or "various forms of reliability" =
or "full / latency-limited / no reliability"


...or something like that.  One item, not two, anyway.


















Hmmm. I=92d rather we had something like =93Degree of reliability =
from unreliable to full reliability."














Agree.






























Second, using the phrase "congestion control" binds the application =
requirement to a specific mechanism. I'd rather use something like "low =
delay vs. high throughput=94.













Perhaps this would best be expressed as =93Trading off latency and =
throughput"















Agree.



























I don't know if this list is correct or =
complete. This should be the WG

job to compile it.

Btw, adding this list to the charter, as a starting point, would =
make

sense.











So, to summarize, here's the complete list that I suggest:







- sequence preservation


- various degrees of reliability


- low delay vs. high throughput













I=92d rephrase this as:







- ordering/sequence preservation


- degree of reliability 


- latency vs throughput














Agree, this is nicer!






























How do we call the transport that support =
those 5 things? a transport

protocol? a transport service?

The "services" term is used multiple times within the charter.

Sometimes I understand it as a "transport protocol" (like in the =
first

sentence in the charter),

And sometimes I may interpret it as Brian's "dimensions of transport" =
or

criteria.



Potentially use "criteria" and "transport protocol"

Alternatively, only use "transport services" when it means "criteria, =
and

"transport protocol".

I tried to do the latter below.














Again, detailed comments in line:












OLD:



Conjointly, transport protocols such as SCTP, DCCP, MPTCP,

UDP-Lite and the LEDBAT congestion control mechanism extend

the set of transport services that are available to

applications, beyond those provided by TCP and UDP. For

example, SCTP provides potentially faster reliable delivery

for applications that can accept blocks of data out of order,

and LEDBAT provides low-priority "scavenger" communication.



NEW:

Conjointly, transport protocols such as SCTP, DCCP, MPTCP,

UDP-Lite and the LEDBAT congestion control mechanism extend

the set of transport protocols that are available to

applications, beyond those provided by TCP and UDP. For

example, SCTP provides potentially faster reliable delivery

for applications that can accept blocks of data out of order,

and LEDBAT provides low-priority "scavenger" communication.










Disagree, I'd rather leave it as it is to stress that applications use =
services, not protocols.


















I actually think changing that to protocols might be a good thing, =
since it highlights how complex the landscape has become. 


















I disagree. The "For example" list gets very strange as examples of =
transport protocols. I also agree with Michael's original objection: =
stressing that applications use services is important.














Okay, fine by me. I don't have a strong opinion here either =
way.





































OLD:



- Identify services provided by existing IETF transport protocols

  and congestion control mechanisms. The resulting document =
will

  provide guidance on making a choice among available =
mechanisms

  and protocols to obtain a certain transport service.





NEW:



- Identify transport services provided by existing IETF transport

protocols

  and congestion control mechanisms. The resulting document =
will

  provide guidance on making a choice among available =
mechanisms

  and protocols to obtain a certain transport service. As a =
starting

point

  for transport services, the working group can consider: =
message

atomicity,

  stream fragmentation, sequence preservation, head-of-line =
blocking

avoidance,

  sub-channels, full reliability, latency-limited =
reliability,

loss-sensitive

  congestion control, delay-sensitive congestion control, =
endpoint

address agility,

  privacy and integrity, and path-state propagation =
(NAT/Firewall).











Sentence 1: "transport services provided by ..  transport =
protocols" doesn't seem to make things clearer. I'd rather keep =
"services" in this sentence - what this means gets concrete anyway due =
to the list that follows in sentence 3, and there the phrase
 "transport services" is used anyway. The list should be changed, as I =
argued above. I suggest:







NEW:







- Identify services provided by existing IETF transport =
protocols

  and congestion control mechanisms. The resulting document =
will

  provide guidance on making a choice among available =
mechanisms

  and protocols to obtain a certain transport service. As a =
starting point


  for transport services, the working group can consider: =
sequence


  preservation, various degrees of reliability, low delay vs. =
high throughput.















I think here we=92re once again running into the difficulty of the =
ambiguity of the word =93transport=94, especially in the IETF=85 If we =
have defined Transport Services in terms of the transport protocol =
earlier in the document, can we actually phrase this









- Identify Transport Services provided by IETF protocols and =
congestion control mechanisms










Agreed


























OLD:

- Specify experimental mechanisms to deliver a transport service.

  This will explain how to select and engage a protocol, and =
how

  to discover the availability of protocols on an interface =
(both

  end system and path support), in order to provide a basis =
for

  incremental deployment.



NEW:

- Specify experimental mechanisms to deliver a transport protocol.

  This will explain how to select and engage a protocol, and =
how

  to discover the availability of protocol services on an =
interface (both



  end system and path support), in order to provide a basis =
for

  incremental deployment.















Disagree. "deliver a transport protocol" is weird. The intention was to =
say "provide a transport service", maybe "deliver" is a bad choice of =
words here? So I suggest:







NEW:

- Specify experimental mechanisms to provide a transport service.

  This will explain how to select and engage a protocol, and =
how

  to discover the availability of protocols on an interface =
(both

  end system and path support), in order to provide a basis for

  incremental deployment.













Specify experimental mechanisms to provide a given Transport =
Service. 


This will explain how to select and engage an appropriate protocol =
and 


how to discover which protocols are available for a given =
connection. 


This will provide a basis for incremental deployment.











Agreed.


























 "The Working Group will coordinate =
closely with other Working Groups and

IRTF Research Groups."

You should list the WGs you have in mind.











I agree that it looks odd as it stands. I'm not sure what the right =
approach is here (simply remove? or what are these groups?) - e.g. =
Spencer would know better than me=85


















I think the key thing here was that we aren=92t only limiting =
ourselves to working with the IETF but are also interested in getting =
input from the IRTF. However I think we can drop this










Agreed.







Cheers,


Michael











 


_______________________________________________
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/m=
ailman/listinfo/taps
____________________=
___________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/taps

=

--Apple-Mail=_B9842C65-BB1A-4F81-A521-BDCFAF65F8F0--


From nobody Sun Jun 29 03:07:27 2014
Return-Path: 
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B7D1A044D for ; Sun, 29 Jun 2014 03:07:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Level: 
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 36z2frm2hAX7 for ; Sun, 29 Jun 2014 03:07:21 -0700 (PDT)
Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A95941A0444 for ; Sun, 29 Jun 2014 03:07:20 -0700 (PDT)
Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1X1C0x-0007fA-Pf; Sun, 29 Jun 2014 12:07:15 +0200
Received: from 089144222109.atnat0031.highway.bob.at ([89.144.222.109] helo=[192.168.0.100]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1X1C0q-0008CJ-TV; Sun, 29 Jun 2014 12:07:15 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail=_84CD210B-A6DE-4C02-8B7C-E8BDFB9B67E2"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Michael Welzl 
In-Reply-To: 
Date: Sun, 29 Jun 2014 12:07:01 +0200
Message-Id: 
References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACAFDA.3060303@gmail.com> <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> <53AD74D8.9010906@gmail.com>  <33966B16-D15B-49E5-BEBD-C8DE990F8028@ifi.uio.no> <53AD88BD.6090003@kau.se> <0305821c865245e08cc4531ff66d9c7d@AMSPR06MB439.eurprd06.prod.outlook.com> <12FABC6F-187D-479C-8A72-4D1FBC5C25FC@mjmontpetit.com> 
To: Aaron Falk 
X-Mailer: Apple Mail (2.1878.2)
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 1 sum rcpts/h 10 sum msgs/h 1 total rcpts 17975 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 8C1D0D1E8FBC3A796613C5FD32CB77B861D85464
X-UiO-SPAM-Test: remote_host: 89.144.222.109 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 5 max/h 2 blacklist 0 greylist 0 ratelimit 0
Archived-At: http://mailarchive.ietf.org/arch/msg/taps/0RX4HGUevusThht7iH2wJT46Kdo
Cc: "" , Marie-Jose Montpetit , Spencer Dawkins , "" , "bclaise@cisco.com" , "" 
Subject: [Taps] Erasure-free vs. error-free
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Jun 2014 10:07:25 -0000

--Apple-Mail=_84CD210B-A6DE-4C02-8B7C-E8BDFB9B67E2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I hope the subject is ok  :)   now, to the point:

I agree, on both accounts.

Cheers,
Michael



On 28. juni 2014, at 16:46, Aaron Falk  wrote:

> Sounds like there are two points here worth teasing apart:
>=20
> 1. "reliable erasure-free DELIVERY" vs "reliable error-free CONTENT =
that is delivered" are different
>=20
> and=20
>=20
> 2. Each is a 'dimension' rather than a binary characteristic (like, =
say, in order delivery)
>=20
> --aaron
>=20
>=20
> On Sat, Jun 28, 2014 at 6:08 AM, Marie-Jose Montpetit =
 wrote:
> I would say that we should not limit it to one or the other but make =
it dependent on the application requirement.
>=20
> Marie-Jos=E9 Montpetit
> marie@mjmontpetit.com
> mariejo@mit.edu
>=20
> On Jun 28, 2014, at 5:31,  wrote:
>=20
>> on reliability, are we talking of reliable erasure-free DELIVERY or =
reliable error-free CONTENT that is delivered?
>>=20
>> Two dimensions here. We spent a few years debating the nuances in =
DTNRG.
>>=20
>> e.g. TCP is thought to offer both, but its payload content check is =
weak. SCTP can vary delivery reliability, while its payload check is =
stronger. UDP-Lite doesn't give reliable delivery, its content check can =
vary, etc.=20
>> From: Taps  on behalf of Anna Brunstrom =

>> Sent: Saturday, 28 June 2014 1:07:41 AM
>> To: taps@ietf.org
>> Cc: bclaise@cisco.com; spencerdawkins.ietf@gmail.com
>> Subject: Re: [Taps] Charter bikeshed #1 - "transport service"
>> =20
>> Hi,
>>=20
>> Repeating one of my comments on the long mail to this more manageable =
version that Micheal produced while I was reading.
>>=20
>> Anna=20
>>=20
>> On 2014-06-27 16:38, Michael Welzl wrote:
>>> Hi,
>>>=20
>>> I'll cut away a lot now, and only address things that need =
addressing below:
>>>=20
>>>=20
>>> On 27. juni 2014, at 16:21, Toby Moncaster =
 wrote:
>>>=20
>>> [snip]
>>>=20
>>>> I agree with Michael here. I think we could end up with a much less =
clearly worded charter if we go down that route. If there is a need to =
be more precise then I=92d favour adding something near the beginning of =
the charter along the lines of the definition I put in the Problem =
Statement document. Namely:  "A Transport Service is any service =
provided by the transport layer that can only be correctly implemented =
with information from the application.=94We could then include 2 or
>>>>  3 example services=20
>>>=20
>>>=20
>>> I agree. Putting that definition in there would be nice.
>>>=20
>>>=20
>>>=20
>>>>>>>>     - full reliability
>>>>>>>>     - latency-limited reliability
>>>>>>>=20
>>>>>>=20
>>>>>> Yes, reliability is a service, and fine to include in the list. =
But I'd rather replace this with any of:
>>>>>> "various degrees of reliability" or "various forms of =
reliability" or "full / latency-limited / no reliability"
>>>>>> ...or something like that.  One item, not two, anyway.
>>>>=20
>>>>=20
>>>> Hmmm. I=92d rather we had something like =93Degree of reliability =
from unreliable to full reliability."
>>>=20
>>> Agree.
>>>=20
>>>=20
>>>>>> Second, using the phrase "congestion control" binds the =
application requirement to a specific mechanism. I'd rather use =
something like "low delay vs. high throughput=94.
>>>>=20
>>>> Perhaps this would best be expressed as =93Trading off latency and =
throughput"
>>>=20
>>> Agree.
>>>=20
>>>=20
>>>>>>>> I don't know if this list is correct or complete. This should =
be the WG
>>>>>>>> job to compile it.
>>>>>>>> Btw, adding this list to the charter, as a starting point, =
would make
>>>>>>>> sense.
>>>>>>=20
>>>>>> So, to summarize, here's the complete list that I suggest:
>>>>>>=20
>>>>>> - sequence preservation
>>>>>> - various degrees of reliability
>>>>>> - low delay vs. high throughput
>>>>=20
>>>> I=92d rephrase this as:
>>>>=20
>>>> - ordering/sequence preservation
>>>> - degree of reliability=20
>>>> - latency vs throughput
>>>=20
>>> Agree, this is nicer!
>>>=20
>>>=20
>>>>>>>> How do we call the transport that support those 5 things? a =
transport
>>>>>>>> protocol? a transport service?
>>>>>>>> The "services" term is used multiple times within the charter.
>>>>>>>> Sometimes I understand it as a "transport protocol" (like in =
the first
>>>>>>>> sentence in the charter),
>>>>>>>> And sometimes I may interpret it as Brian's "dimensions of =
transport" or
>>>>>>>> criteria.
>>>>>>>>=20
>>>>>>>> Potentially use "criteria" and "transport protocol"
>>>>>>>> Alternatively, only use "transport services" when it means =
"criteria, and
>>>>>>>> "transport protocol".
>>>>>>>> I tried to do the latter below.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>=20
>>>>>> Again, detailed comments in line:
>>>>>>=20
>>>>>>=20
>>>>>>>> OLD:
>>>>>>>>=20
>>>>>>>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
>>>>>>>> UDP-Lite and the LEDBAT congestion control mechanism extend
>>>>>>>> the set of transport services that are available to
>>>>>>>> applications, beyond those provided by TCP and UDP. For
>>>>>>>> example, SCTP provides potentially faster reliable delivery
>>>>>>>> for applications that can accept blocks of data out of order,
>>>>>>>> and LEDBAT provides low-priority "scavenger" communication.
>>>>>>>>=20
>>>>>>>> NEW:
>>>>>>>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
>>>>>>>> UDP-Lite and the LEDBAT congestion control mechanism extend
>>>>>>>> the set of transport protocols that are available to
>>>>>>>> applications, beyond those provided by TCP and UDP. For
>>>>>>>> example, SCTP provides potentially faster reliable delivery
>>>>>>>> for applications that can accept blocks of data out of order,
>>>>>>>> and LEDBAT provides low-priority "scavenger" communication.
>>>>>>=20
>>>>>> Disagree, I'd rather leave it as it is to stress that =
applications use services, not protocols.
>>>>=20
>>>>=20
>>>> I actually think changing that to protocols might be a good thing, =
since it highlights how complex the landscape has become.=20
>>>=20
>>=20
>> I disagree. The "For example" list gets very strange as examples of =
transport protocols. I also agree with Michael's original objection: =
stressing that applications use services is important.
>>=20
>>=20
>>=20
>>> Okay, fine by me. I don't have a strong opinion here either way.
>>>=20
>>>=20
>>>>>>>> OLD:
>>>>>>>>=20
>>>>>>>> - Identify services provided by existing IETF transport =
protocols
>>>>>>>>   and congestion control mechanisms. The resulting document =
will
>>>>>>>>   provide guidance on making a choice among available =
mechanisms
>>>>>>>>   and protocols to obtain a certain transport service.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> NEW:
>>>>>>>>=20
>>>>>>>> - Identify transport services provided by existing IETF =
transport
>>>>>>>> protocols
>>>>>>>>   and congestion control mechanisms. The resulting document =
will
>>>>>>>>   provide guidance on making a choice among available =
mechanisms
>>>>>>>>   and protocols to obtain a certain transport service. As a =
starting
>>>>>>>> point
>>>>>>>>   for transport services, the working group can consider: =
message
>>>>>>>> atomicity,
>>>>>>>>   stream fragmentation, sequence preservation, head-of-line =
blocking
>>>>>>>> avoidance,
>>>>>>>>   sub-channels, full reliability, latency-limited reliability,
>>>>>>>> loss-sensitive
>>>>>>>>   congestion control, delay-sensitive congestion control, =
endpoint
>>>>>>>> address agility,
>>>>>>>>   privacy and integrity, and path-state propagation =
(NAT/Firewall).
>>>>>>=20
>>>>>> Sentence 1: "transport services provided by ..  transport =
protocols" doesn't seem to make things clearer. I'd rather keep =
"services" in this sentence - what this means gets concrete anyway due =
to the list that follows in sentence 3, and there the phrase "transport =
services" is used anyway. The list should be changed, as I argued above. =
I suggest:
>>>>>>=20
>>>>>> NEW:
>>>>>>=20
>>>>>> - Identify services provided by existing IETF transport protocols
>>>>>>   and congestion control mechanisms. The resulting document will
>>>>>>   provide guidance on making a choice among available mechanisms
>>>>>>   and protocols to obtain a certain transport service. As a =
starting point
>>>>>>   for transport services, the working group can consider: =
sequence
>>>>>>   preservation, various degrees of reliability, low delay vs. =
high throughput.
>>>>=20
>>>> I think here we=92re once again running into the difficulty of the =
ambiguity of the word =93transport=94, especially in the IETF=85 If we =
have defined Transport Services in terms of the transport protocol =
earlier in the document, can we actually phrase this
>>>>=20
>>>> - Identify Transport Services provided by IETF protocols and =
congestion control mechanisms
>>>=20
>>> Agreed
>>>=20
>>>=20
>>>>>>>> OLD:
>>>>>>>> - Specify experimental mechanisms to deliver a transport =
service.
>>>>>>>>   This will explain how to select and engage a protocol, and =
how
>>>>>>>>   to discover the availability of protocols on an interface =
(both
>>>>>>>>   end system and path support), in order to provide a basis for
>>>>>>>>   incremental deployment.
>>>>>>>>=20
>>>>>>>> NEW:
>>>>>>>> - Specify experimental mechanisms to deliver a transport =
protocol.
>>>>>>>>   This will explain how to select and engage a protocol, and =
how
>>>>>>>>   to discover the availability of protocol services on an =
interface (both
>>>>>>>>=20
>>>>>>>>   end system and path support), in order to provide a basis for
>>>>>>>>   incremental deployment.
>>>>>>=20
>>>>>>=20
>>>>>> Disagree. "deliver a transport protocol" is weird. The intention =
was to say "provide a transport service", maybe "deliver" is a bad =
choice of words here? So I suggest:
>>>>>>=20
>>>>>> NEW:
>>>>>> - Specify experimental mechanisms to provide a transport service.
>>>>>>   This will explain how to select and engage a protocol, and how
>>>>>>   to discover the availability of protocols on an interface (both
>>>>>>   end system and path support), in order to provide a basis for
>>>>>>   incremental deployment.
>>>>=20
>>>> Specify experimental mechanisms to provide a given Transport =
Service.=20
>>>> This will explain how to select and engage an appropriate protocol =
and=20
>>>> how to discover which protocols are available for a given =
connection.=20
>>>> This will provide a basis for incremental deployment.
>>>=20
>>> Agreed.
>>>=20
>>>=20
>>>>>>>>  "The Working Group will coordinate closely with other Working =
Groups and
>>>>>>>> IRTF Research Groups."
>>>>>>>> You should list the WGs you have in mind.
>>>>>>=20
>>>>>> I agree that it looks odd as it stands. I'm not sure what the =
right approach is here (simply remove? or what are these groups?) - e.g. =
Spencer would know better than me=85
>>>>=20
>>>>=20
>>>> I think the key thing here was that we aren=92t only limiting =
ourselves to working with the IETF but are also interested in getting =
input from the IRTF. However I think we can drop this
>>>=20
>>> Agreed.
>>>=20
>>> Cheers,
>>> Michael
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> Taps mailing list
>>> Taps@ietf.org
>>> https://www.ietf.org/mailman/listinfo/taps
>>=20
>> _______________________________________________
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
>=20
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
>=20
>=20
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps


--Apple-Mail=_84CD210B-A6DE-4C02-8B7C-E8BDFB9B67E2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

I hope =
the subject is ok  :)   now, to the =
point:

I agree, on both =
accounts.

Cheers,
Michael


On 28. juni 2014, at =
16:46, Aaron Falk <falk-ietf@dgftech.com> =
wrote:

Sounds like there are two points here =
worth teasing apart:

1. "reliable =
erasure-free DELIVERY" vs "reliable error-free CONTENT that is =
delivered" are different




and 




2. Each is a =
'dimension' rather than a binary characteristic (like, say, in order =
delivery)




--aaron
=



On =
Sat, Jun 28, 2014 at 6:08 AM, Marie-Jose Montpetit <marie@mjmontpetit.com> wrote:



I=
 would say that we should not limit it to one or the other but make it =
dependent on the application requirement.



Marie-Jos=E9 Montpetit




On Jun 28, 2014, at 5:31, <l.wood@surrey.ac.uk> =
wrote:






on reliability, are we talking of reliable erasure-free DELIVERY or =
reliable error-free CONTENT that is delivered?



Two dimensions here. We spent a few years debating the nuances in =
DTNRG.



e.g. TCP is thought to offer both, but its payload content check is =
weak. SCTP can vary delivery reliability, while its payload check is =
stronger. UDP-Lite doesn't give reliable delivery, its content check can =
vary, etc.



From: Taps <taps-bounces@ietf.org> on behalf of Anna =
Brunstrom <anna.brunstrom@kau.se>



Sent: Saturday, 28 June 2014 1:07:41 AM

To: taps@ietf.org

Cc: bclaise@cisco.com; spencerdawkins.ietf@gmail.com

Subject: Re: [Taps] Charter bikeshed #1 - "transport =
service"

 




Hi,



Repeating one of my comments on the long mail to this more manageable =
version that Micheal produced while I was reading.



Anna 



On 2014-06-27 16:38, Michael Welzl wrote:




Hi,







I'll cut away a lot now, and only address things that need =
addressing below:
















On 27. juni 2014, at 16:21, Toby Moncaster <toby.moncaster@cl.cam.ac.uk> wrote:






[snip]












I agree with Michael here. I think we could end up with a much less =
clearly worded charter if we go down that route. If there is a need to =
be more precise then I=92d favour adding something near the beginning of =
the charter along the lines of the definition I
 put in the Problem Statement document. Namely:  "A Transport Service is any service =
provided by the transport layer that can only be correctly implemented =
with information from the application.=94We could then include 2 or
 3 example services 















I agree. Putting that definition in =
there would be nice.



































    - full reliability










    - latency-limited =
reliability

















Yes, reliability is a service, and fine to include in the list. But =
I'd rather replace this with any of:


"various degrees of reliability" or "various forms of reliability" =
or "full / latency-limited / no reliability"


...or something like that.  One item, not two, anyway.


















Hmmm. I=92d rather we had something like =93Degree of reliability =
from unreliable to full reliability."














Agree.






























Second, using the phrase "congestion control" binds the application =
requirement to a specific mechanism. I'd rather use something like "low =
delay vs. high throughput=94.













Perhaps this would best be expressed as =93Trading off latency and =
throughput"















Agree.



























I don't know if this list is correct or =
complete. This should be the WG

job to compile it.

Btw, adding this list to the charter, as a starting point, would =
make

sense.











So, to summarize, here's the complete list that I suggest:







- sequence preservation


- various degrees of reliability


- low delay vs. high throughput













I=92d rephrase this as:







- ordering/sequence preservation


- degree of reliability 


- latency vs throughput














Agree, this is nicer!






























How do we call the transport that support =
those 5 things? a transport

protocol? a transport service?

The "services" term is used multiple times within the charter.

Sometimes I understand it as a "transport protocol" (like in the =
first

sentence in the charter),

And sometimes I may interpret it as Brian's "dimensions of transport" =
or

criteria.



Potentially use "criteria" and "transport protocol"

Alternatively, only use "transport services" when it means "criteria, =
and

"transport protocol".

I tried to do the latter below.














Again, detailed comments in line:












OLD:



Conjointly, transport protocols such as SCTP, DCCP, MPTCP,

UDP-Lite and the LEDBAT congestion control mechanism extend

the set of transport services that are available to

applications, beyond those provided by TCP and UDP. For

example, SCTP provides potentially faster reliable delivery

for applications that can accept blocks of data out of order,

and LEDBAT provides low-priority "scavenger" communication.



NEW:

Conjointly, transport protocols such as SCTP, DCCP, MPTCP,

UDP-Lite and the LEDBAT congestion control mechanism extend

the set of transport protocols that are available to

applications, beyond those provided by TCP and UDP. For

example, SCTP provides potentially faster reliable delivery

for applications that can accept blocks of data out of order,

and LEDBAT provides low-priority "scavenger" communication.










Disagree, I'd rather leave it as it is to stress that applications use =
services, not protocols.


















I actually think changing that to protocols might be a good thing, =
since it highlights how complex the landscape has become. 


















I disagree. The "For example" list gets very strange as examples of =
transport protocols. I also agree with Michael's original objection: =
stressing that applications use services is important.














Okay, fine by me. I don't have a strong opinion here either =
way.





































OLD:



- Identify services provided by existing IETF transport protocols

  and congestion control mechanisms. The resulting document =
will

  provide guidance on making a choice among available =
mechanisms

  and protocols to obtain a certain transport service.





NEW:



- Identify transport services provided by existing IETF transport

protocols

  and congestion control mechanisms. The resulting document =
will

  provide guidance on making a choice among available =
mechanisms

  and protocols to obtain a certain transport service. As a =
starting

point

  for transport services, the working group can consider: =
message

atomicity,

  stream fragmentation, sequence preservation, head-of-line =
blocking

avoidance,

  sub-channels, full reliability, latency-limited =
reliability,

loss-sensitive

  congestion control, delay-sensitive congestion control, =
endpoint

address agility,

  privacy and integrity, and path-state propagation =
(NAT/Firewall).











Sentence 1: "transport services provided by ..  transport =
protocols" doesn't seem to make things clearer. I'd rather keep =
"services" in this sentence - what this means gets concrete anyway due =
to the list that follows in sentence 3, and there the phrase
 "transport services" is used anyway. The list should be changed, as I =
argued above. I suggest:







NEW:







- Identify services provided by existing IETF transport =
protocols

  and congestion control mechanisms. The resulting document =
will

  provide guidance on making a choice among available =
mechanisms

  and protocols to obtain a certain transport service. As a =
starting point


  for transport services, the working group can consider: =
sequence


  preservation, various degrees of reliability, low delay vs. =
high throughput.















I think here we=92re once again running into the difficulty of the =
ambiguity of the word =93transport=94, especially in the IETF=85 If we =
have defined Transport Services in terms of the transport protocol =
earlier in the document, can we actually phrase this









- Identify Transport Services provided by IETF protocols and =
congestion control mechanisms










Agreed


























OLD:

- Specify experimental mechanisms to deliver a transport service.

  This will explain how to select and engage a protocol, and =
how

  to discover the availability of protocols on an interface =
(both

  end system and path support), in order to provide a basis =
for

  incremental deployment.



NEW:

- Specify experimental mechanisms to deliver a transport protocol.

  This will explain how to select and engage a protocol, and =
how

  to discover the availability of protocol services on an =
interface (both



  end system and path support), in order to provide a basis =
for

  incremental deployment.















Disagree. "deliver a transport protocol" is weird. The intention was to =
say "provide a transport service", maybe "deliver" is a bad choice of =
words here? So I suggest:







NEW:

- Specify experimental mechanisms to provide a transport service.

  This will explain how to select and engage a protocol, and =
how

  to discover the availability of protocols on an interface =
(both

  end system and path support), in order to provide a basis for

  incremental deployment.













Specify experimental mechanisms to provide a given Transport =
Service. 


This will explain how to select and engage an appropriate protocol =
and 


how to discover which protocols are available for a given =
connection. 


This will provide a basis for incremental deployment.











Agreed.


























 "The Working Group will coordinate =
closely with other Working Groups and

IRTF Research Groups."

You should list the WGs you have in mind.











I agree that it looks odd as it stands. I'm not sure what the right =
approach is here (simply remove? or what are these groups?) - e.g. =
Spencer would know better than me=85


















I think the key thing here was that we aren=92t only limiting =
ourselves to working with the IETF but are also interested in getting =
input from the IRTF. However I think we can drop this










Agreed.







Cheers,


Michael











 


_______________________________________________
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/ma=
ilman/listinfo/taps

=

--Apple-Mail=_84CD210B-A6DE-4C02-8B7C-E8BDFB9B67E2--


From nobody Sun Jun 29 04:48:30 2014
Return-Path: 
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2961A0496 for ; Sun, 29 Jun 2014 04:48:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
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 Vr967ozowisS for ; Sun, 29 Jun 2014 04:48:24 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.148]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3BF01A0467 for ; Sun, 29 Jun 2014 04:48:23 -0700 (PDT)
Received: from [85.158.136.51:3089] by server-12.bemta-5.messagelabs.com id 2F/09-27841-50DFFA35; Sun, 29 Jun 2014 11:48:21 +0000
X-Env-Sender: l.wood@surrey.ac.uk
X-Msg-Ref: server-16.tower-49.messagelabs.com!1404042500!23383446!1
X-Originating-IP: [131.227.200.43]
X-StarScan-Received: 
X-StarScan-Version: 6.11.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 22868 invoked from network); 29 Jun 2014 11:48:21 -0000
Received: from exht022p.surrey.ac.uk (HELO EXHT022P.surrey.ac.uk) (131.227.200.43) by server-16.tower-49.messagelabs.com with AES128-SHA encrypted SMTP; 29 Jun 2014 11:48:21 -0000
Received: from EXHY022V.surrey.ac.uk (131.227.201.104) by EXHT022P.surrey.ac.uk (131.227.200.43) with Microsoft SMTP Server (TLS) id 8.3.342.0; Sun, 29 Jun 2014 12:48:20 +0100
Received: from emea01-am1-obe.outbound.protection.outlook.com (131.227.201.241) by EXHY022v.surrey.ac.uk (131.227.201.104) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 29 Jun 2014 12:48:19 +0100
Received: from AMSPR06MB438.eurprd06.prod.outlook.com (10.242.23.15) by AMSPR06MB024.eurprd06.prod.outlook.com (10.242.82.28) with Microsoft SMTP Server (TLS) id 15.0.974.11; Sun, 29 Jun 2014 11:48:19 +0000
Received: from AMSPR06MB439.eurprd06.prod.outlook.com (10.242.23.19) by AMSPR06MB438.eurprd06.prod.outlook.com (10.242.23.15) with Microsoft SMTP Server (TLS) id 15.0.969.15; Sun, 29 Jun 2014 11:48:18 +0000
Received: from AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) by AMSPR06MB439.eurprd06.prod.outlook.com ([10.242.23.19]) with mapi id 15.00.0969.007; Sun, 29 Jun 2014 11:48:18 +0000
From: 
To: , 
Thread-Topic: [Taps] Charter bikeshed #1 - "transport service"
Thread-Index: AQHPkg3Qpp9PvhY+OkO75h7vCz/t/5uFAgmAgAAEsACAAAhAgIAAeIHZgADGGACAAE3OAIAAKLKAgAEUpoCAACLNMA==
Date: Sun, 29 Jun 2014 11:48:18 +0000
Message-ID: <29a76b83add64d6cbe70b53a37cb419e@AMSPR06MB439.eurprd06.prod.outlook.com>
References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACAFDA.3060303@gmail.com> <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> <53AD74D8.9010906@gmail.com>  <33966B16-D15B-49E5-BEBD-C8DE990F8028@ifi.uio.no> <53AD88BD.6090003@kau.se> <0305821c865245e08cc4531ff66d9c7d@AMSPR06MB439.eurprd06.prod.outlook.com> <12FABC6F-187D-479C-8A72-4D1FBC5C25FC@mjmontpetit.com>  , <01441810-A702-4DC2-B74C-6C0DC6F5235B@ifi.uio.no>
In-Reply-To: <01441810-A702-4DC2-B74C-6C0DC6F5235B@ifi.uio.no>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [124.149.114.231]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 025796F161
x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(24454002)(377424004)(377454003)(74662001)(20776003)(79102001)(99396002)(76482001)(87936001)(4396001)(106116001)(95666004)(2656002)(83072002)(46102001)(77982001)(86362001)(80022001)(64706001)(107046002)(76576001)(85306003)(33646001)(74502001)(93886003)(16236675004)(74482001)(106356001)(74316001)(15975445006)(21056001)(101416001)(54356999)(76176999)(50986999)(19580395003)(105586002)(81542001)(66066001)(81342001)(83322001)(85852003)(19580405001)(17413003)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR06MB438; H:AMSPR06MB439.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_29a76b83add64d6cbe70b53a37cb419eAMSPR06MB439eurprd06pro_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: AMSPR06MB438.eurprd06.prod.outlook.com
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:
X-CrossPremisesHeadersFiltered: EXHY022v.surrey.ac.uk
Archived-At: http://mailarchive.ietf.org/arch/msg/taps/1eI3Y_FkXTavWR9od8RXRINyHR8
Cc: bclaise@cisco.com, marie@mjmontpetit.com, spencerdawkins.ietf@gmail.com, anna.brunstrom@kau.se, taps@ietf.org
Subject: Re: [Taps] Charter bikeshed #1 - "transport service"
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Jun 2014 11:48:29 -0000

--_000_29a76b83add64d6cbe70b53a37cb419eAMSPR06MB439eurprd06pro_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

I had to look up bikeshed and bikeshedding.

Wasn't there a recent RFC on not using slang?
________________________________
From: Michael Welzl 
Sent: Sunday, 29 June 2014 7:42:17 PM
To: Aaron Falk
Cc: Wood L Dr (Electronic Eng); Marie-Jose Montpetit; Spencer Dawkins; ; bclaise@cisco.com; 
Subject: Re: [Taps] Charter bikeshed #1 - "transport service"

If noone reacts by tomorrow, I'd suggest to assume the list's charter discu=
ssion has converged with Anna's last message.

I didn't want to kill off this discussion, however. I'll answer Aaron's ema=
il but with a different subject  :-)

Cheers,
Michael


On 28. juni 2014, at 19:12, Michael Welzl > wrote:

one thing matters here, now: this is not about charter text, right?

Sent from my iPhone

On 28. juni 2014, at 16:46, Aaron Falk > wrote:

Sounds like there are two points here worth teasing apart:

1. "reliable erasure-free DELIVERY" vs "reliable error-free CONTENT that is=
 delivered" are different

and

2. Each is a 'dimension' rather than a binary characteristic (like, say, in=
 order delivery)

--aaron


On Sat, Jun 28, 2014 at 6:08 AM, Marie-Jose Montpetit > wrote:
I would say that we should not limit it to one or the other but make it dep=
endent on the application requirement.

Marie-Jos=E9 Montpetit
marie@mjmontpetit.com
mariejo@mit.edu

On Jun 28, 2014, at 5:31, >=
 wrote:

on reliability, are we talking of reliable erasure-free DELIVERY or reliabl=
e error-free CONTENT that is delivered?

Two dimensions here. We spent a few years debating the nuances in DTNRG.

e.g. TCP is thought to offer both, but its payload content check is weak. S=
CTP can vary delivery reliability, while its payload check is stronger. UDP=
-Lite doesn't give reliable delivery, its content check can vary, etc.
________________________________
From: Taps > on behalf =
of Anna Brunstrom >
Sent: Saturday, 28 June 2014 1:07:41 AM
To: taps@ietf.org
Cc: bclaise@cisco.com; spencerdawkins.ietf@gmail.=
com
Subject: Re: [Taps] Charter bikeshed #1 - "transport service"

Hi,

Repeating one of my comments on the long mail to this more manageable versi=
on that Micheal produced while I was reading.

Anna

On 2014-06-27 16:38, Michael Welzl wrote:
Hi,

I'll cut away a lot now, and only address things that need addressing below=
:


On 27. juni 2014, at 16:21, Toby Moncaster > wrote:

[snip]

I agree with Michael here. I think we could end up with a much less clearly=
 worded charter if we go down that route. If there is a need to be more pre=
cise then I=92d favour adding something near the beginning of the charter a=
long the lines of the definition I put in the Problem Statement document. N=
amely:  "A Transport Service is any service provided by the transport layer=
 that can only be correctly implemented with information from the applicati=
on.=94We could then include 2 or 3 example services

I agree. Putting that definition in there would be nice.


    - full reliability
    - latency-limited reliability

Yes, reliability is a service, and fine to include in the list. But I'd rat=
her replace this with any of:
"various degrees of reliability" or "various forms of reliability" or "full=
 / latency-limited / no reliability"
...or something like that.  One item, not two, anyway.


Hmmm. I=92d rather we had something like =93Degree of reliability from unre=
liable to full reliability."

Agree.


Second, using the phrase "congestion control" binds the application require=
ment to a specific mechanism. I'd rather use something like "low delay vs. =
high throughput=94.

Perhaps this would best be expressed as =93Trading off latency and throughp=
ut"

Agree.


I don't know if this list is correct or complete. This should be the WG
job to compile it.
Btw, adding this list to the charter, as a starting point, would make
sense.

So, to summarize, here's the complete list that I suggest:

- sequence preservation
- various degrees of reliability
- low delay vs. high throughput

I=92d rephrase this as:

- ordering/sequence preservation
- degree of reliability
- latency vs throughput

Agree, this is nicer!


How do we call the transport that support those 5 things? a transport
protocol? a transport service?
The "services" term is used multiple times within the charter.
Sometimes I understand it as a "transport protocol" (like in the first
sentence in the charter),
And sometimes I may interpret it as Brian's "dimensions of transport" or
criteria.

Potentially use "criteria" and "transport protocol"
Alternatively, only use "transport services" when it means "criteria, and
"transport protocol".
I tried to do the latter below.



Again, detailed comments in line:


OLD:

Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
UDP-Lite and the LEDBAT congestion control mechanism extend
the set of transport services that are available to
applications, beyond those provided by TCP and UDP. For
example, SCTP provides potentially faster reliable delivery
for applications that can accept blocks of data out of order,
and LEDBAT provides low-priority "scavenger" communication.

NEW:
Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
UDP-Lite and the LEDBAT congestion control mechanism extend
the set of transport protocols that are available to
applications, beyond those provided by TCP and UDP. For
example, SCTP provides potentially faster reliable delivery
for applications that can accept blocks of data out of order,
and LEDBAT provides low-priority "scavenger" communication.

Disagree, I'd rather leave it as it is to stress that applications use serv=
ices, not protocols.


I actually think changing that to protocols might be a good thing, since it=
 highlights how complex the landscape has become.


I disagree. The "For example" list gets very strange as examples of transpo=
rt protocols. I also agree with Michael's original objection: stressing tha=
t applications use services is important.



Okay, fine by me. I don't have a strong opinion here either way.


OLD:

- Identify services provided by existing IETF transport protocols
  and congestion control mechanisms. The resulting document will
  provide guidance on making a choice among available mechanisms
  and protocols to obtain a certain transport service.


NEW:

- Identify transport services provided by existing IETF transport
protocols
  and congestion control mechanisms. The resulting document will
  provide guidance on making a choice among available mechanisms
  and protocols to obtain a certain transport service. As a starting
point
  for transport services, the working group can consider: message
atomicity,
  stream fragmentation, sequence preservation, head-of-line blocking
avoidance,
  sub-channels, full reliability, latency-limited reliability,
loss-sensitive
  congestion control, delay-sensitive congestion control, endpoint
address agility,
  privacy and integrity, and path-state propagation (NAT/Firewall).

Sentence 1: "transport services provided by ..  transport protocols" doesn'=
t seem to make things clearer. I'd rather keep "services" in this sentence =
- what this means gets concrete anyway due to the list that follows in sent=
ence 3, and there the phrase "transport services" is used anyway. The list =
should be changed, as I argued above. I suggest:

NEW:

- Identify services provided by existing IETF transport protocols
  and congestion control mechanisms. The resulting document will
  provide guidance on making a choice among available mechanisms
  and protocols to obtain a certain transport service. As a starting point
  for transport services, the working group can consider: sequence
  preservation, various degrees of reliability, low delay vs. high throughp=
ut.

I think here we=92re once again running into the difficulty of the ambiguit=
y of the word =93transport=94, especially in the IETF=85 If we have defined=
 Transport Services in terms of the transport protocol earlier in the docum=
ent, can we actually phrase this

- Identify Transport Services provided by IETF protocols and congestion con=
trol mechanisms

Agreed


OLD:
- Specify experimental mechanisms to deliver a transport service.
  This will explain how to select and engage a protocol, and how
  to discover the availability of protocols on an interface (both
  end system and path support), in order to provide a basis for
  incremental deployment.

NEW:
- Specify experimental mechanisms to deliver a transport protocol.
  This will explain how to select and engage a protocol, and how
  to discover the availability of protocol services on an interface (both

  end system and path support), in order to provide a basis for
  incremental deployment.


Disagree. "deliver a transport protocol" is weird. The intention was to say=
 "provide a transport service", maybe "deliver" is a bad choice of words he=
re? So I suggest:

NEW:
- Specify experimental mechanisms to provide a transport service.
  This will explain how to select and engage a protocol, and how
  to discover the availability of protocols on an interface (both
  end system and path support), in order to provide a basis for
  incremental deployment.

Specify experimental mechanisms to provide a given Transport Service.
This will explain how to select and engage an appropriate protocol and
how to discover which protocols are available for a given connection.
This will provide a basis for incremental deployment.

Agreed.


 "The Working Group will coordinate closely with other Working Groups and
IRTF Research Groups."
You should list the WGs you have in mind.

I agree that it looks odd as it stands. I'm not sure what the right approac=
h is here (simply remove? or what are these groups?) - e.g. Spencer would k=
now better than me=85


I think the key thing here was that we aren=92t only limiting ourselves to =
working with the IETF but are also interested in getting input from the IRT=
F. However I think we can drop this

Agreed.

Cheers,
Michael




_______________________________________________
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


--_000_29a76b83add64d6cbe70b53a37cb419eAMSPR06MB439eurprd06pro_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable






I had to look up bikeshed and bikeshedding.



Wasn't there a recent RFC on not using slang?




From: Michael Welzl <mic=
hawe@ifi.uio.no>

Sent: Sunday, 29 June 2014 7:42:17 PM

To: Aaron Falk

Cc: Wood L Dr (Electronic Eng); Marie-Jose Montpetit; Spencer Dawkin=
s; <anna.brunstrom@kau.se>; bclaise@cisco.com; <taps@ietf.org><=
br>
Subject: Re: [Taps] Charter bikeshed #1 - "transport service&qu=
ot;

 




If noone reacts by tomorrow, I'd suggest to assume the list's charter =
discussion has converged with Anna's last message.






I didn't want to kill off this discussion, however. I'll answer Aaron'=
s email but with a different subject  :-)







Cheers,


Michael












On 28. juni 2014, at 19:12, Michael Welzl <michawe@ifi.uio.no> wrote:








one thing matters here, now: this is not about charter text, right?


Sent from my iPhone




On 28. juni 2014, at 16:46, Aaron Falk <falk-ietf@dgftech.com> wrote:








Sounds like there are two points here worth teasing apart:






1. "r=
eliable erasure-free DELIVERY" vs "reliable error-free CONTENT th=
at is delivered" are different







and <=
/span>







2. Each is=
 a 'dimension' rather than a binary characteristic (like, say, in order del=
ivery)







--aaron









On Sat, Jun 28, 2014 at 6:08 AM, Marie-Jose Mont=
petit 
<marie@mjmont=
petit.com> wrote:






I would say that we should not limit it to one or the other but make i=
t dependent on the application requirement.



Marie-Jos=E9 Montpetit










on reliability, are we talking of reliable erasur=
e-free DELIVERY or reliable error-free CONTENT that is delivered?



Two dimensions here. We spent a few years debating the nuances in DTNRG.


e.g. TCP is thought to offer both, but its payload content check is weak. S=
CTP can vary delivery reliability, while its payload check is stronger. UDP=
-Lite doesn't give reliable delivery, its content check can vary, etc.



From: Taps <taps-bounces@ietf.org> on behalf of Anna Brunstrom <anna.brunstrom@kau.se=
>

Sent: Saturday, 28 June 2014 1:07:41 AM

To: taps@ietf.org=


Cc: bclaise@c=
isco.com;
spencerd=
awkins.ietf@gmail.com

Subject: Re: [Taps] Charter bikeshed #1 - "transport service&qu=
ot;

 




Hi,



Repeating one of my comments on the long mail to this more manageable versi=
on that Micheal produced while I was reading.



Anna 



On 2014-06-27 16:38, Michael Welzl wrote:




Hi,







I'll cut away a lot now, and only address things that need addressing =
below:
















On 27. juni 2014, at 16:21, Toby Moncaster <toby.moncaster@cl.cam.ac.uk&g=
t; wrote:






[snip]











I agree with Michael here. I think we c=
ould end up with a much less clearly worded charter if we go down that rout=
e. If there is a need to be more precise then I=92d favour adding something=
 near the beginning of the charter along
 the lines of the definition I put in the Problem Statement document. Namel=
y:  "A Transport Service is =
any service provided by the transport layer that can only be correctly impl=
emented with information from the application.=94We
 could then include 2 or 3 example services 












I =
agree. Putting that definition in there would be nice.































    - full reliability










    - latency-limited reliability

















Yes, reliability is a service, and fine to include in the list. But I'=
d rather replace this with any of:


"various degrees of reliability" or "various forms of r=
eliability" or "full / latency-limited / no reliability"

...or something like that.  One item, not two, anyway.


















Hmmm. I=92d rather we had something like =93Degree of reliability from=
 unreliable to full reliability."














Agree.




























Second, using the phrase "congestion control" binds the appl=
ication requirement to a specific mechanism. I'd rather use something like =
"low delay vs. high throughput=94.













Perhaps this would best be expressed as =93Trading off latency and thr=
oughput"















Agree.

























I don't know if this list is correct or complete.=
 This should be the WG

job to compile it.

Btw, adding this list to the charter, as a starting point, would make

sense.











So, to summarize, here's the complete list that I suggest:







- sequence preservation


- various degrees of reliability


- low delay vs. high throughput













I=92d rephrase this as:







- ordering/sequence preservation


- degree of reliability 


- latency vs throughput














Agree, this is nicer!




























How do we call the transport that support those 5=
 things? a transport

protocol? a transport service?

The "services" term is used multiple times within the charter.
Sometimes I understand it as a "transport protocol" (like in the =
first

sentence in the charter),

And sometimes I may interpret it as Brian's "dimensions of transport&q=
uot; or

criteria.



Potentially use "criteria" and "transport protocol"

Alternatively, only use "transport services" when it means "=
criteria, and

"transport protocol".

I tried to do the latter below.














Again, detailed comments in line:












OLD:



Conjointly, transport protocols such as SCTP, DCCP, MPTCP,

UDP-Lite and the LEDBAT congestion control mechanism extend

the set of transport services that are available to

applications, beyond those provided by TCP and UDP. For

example, SCTP provides potentially faster reliable delivery

for applications that can accept blocks of data out of order,

and LEDBAT provides low-priority "scavenger" communication.



NEW:

Conjointly, transport protocols such as SCTP, DCCP, MPTCP,

UDP-Lite and the LEDBAT congestion control mechanism extend

the set of transport protocols that are available to

applications, beyond those provided by TCP and UDP. For

example, SCTP provides potentially faster reliable delivery

for applications that can accept blocks of data out of order,

and LEDBAT provides low-priority "scavenger" communication.










Disagree, I'd rather leave it as it is to stress that applications use serv=
ices, not protocols.


















I actually think changing that to protocols might be a good thing, sin=
ce it highlights how complex the landscape has become. 


















I disagree. The "For example" list gets very strange as examples =
of transport protocols. I also agree with Michael's original objection: str=
essing that applications use services is important.














Okay, fine by me. I don't have a strong opinion here either way.



































OLD:



- Identify services provided by existing IETF transport protocols

  and congestion control mechanisms. The resulting document will<=
br>
  provide guidance on making a choice among available mechanisms<=
br>
  and protocols to obtain a certain transport service.





NEW:



- Identify transport services provided by existing IETF transport

protocols

  and congestion control mechanisms. The resulting document will<=
br>
  provide guidance on making a choice among available mechanisms<=
br>
  and protocols to obtain a certain transport service. As a start=
ing

point

  for transport services, the working group can consider: message=


atomicity,

  stream fragmentation, sequence preservation, head-of-line block=
ing

avoidance,

  sub-channels, full reliability, latency-limited reliability,
loss-sensitive

  congestion control, delay-sensitive congestion control, endpoin=
t

address agility,

  privacy and integrity, and path-state propagation (NAT/Firewall=
).











Sentence 1: "transport services provided by ..  transport pr=
otocols" doesn't seem to make things clearer. I'd rather keep "se=
rvices" in this sentence - what this means gets concrete anyway due to=
 the list that follows in sentence 3, and there the phrase
 "transport services" is used anyway. The list should be changed,=
 as I argued above. I suggest:







NEW:







- Identify services provided by existing IETF transport protocols

  and congestion control mechanisms. The resulting document will

  provide guidance on making a choice among available mechanisms

  and protocols to obtain a certain transport service. As a starting p=
oint


  for transport services, the working group can consider: sequenc=
e


  preservation, various degrees of reliability, low delay vs. hig=
h throughput.















I think here we=92re once again running into the difficulty of the amb=
iguity of the word =93transport=94, especially in the IETF=85 If we have de=
fined Transport Services in terms of the transport protocol earlier in the =
document, can we actually phrase this







- Identify Transport Services provided by IETF protocols and congestio=
n control mechanisms










Agreed
























OLD:

- Specify experimental mechanisms to deliver a transport service.

  This will explain how to select and engage a protocol, and how<=
br>
  to discover the availability of protocols on an interface (both=


  end system and path support), in order to provide a basis for
  incremental deployment.



NEW:

- Specify experimental mechanisms to deliver a transport protocol.

  This will explain how to select and engage a protocol, and how<=
br>
  to discover the availability of protocol services on an interfa=
ce (both



  end system and path support), in order to provide a basis for
  incremental deployment.















Disagree. "deliver a transport protocol" is weird. The intention =
was to say "provide a transport service", maybe "deliver&quo=
t; is a bad choice of words here? So I suggest:







NEW:

- Specify experimental mechanisms to provide a transport service.

  This will explain how to select and engage a protocol, and how

  to discover the availability of protocols on an interface (both

  end system and path support), in order to provide a basis for

  incremental deployment.













Specify experimental mechanisms to provide a given Transport Service.&=
nbsp;


This will explain how to select and engage an appropriate protocol and=
 


how to discover which protocols are available for a given connection.&=
nbsp;


This will provide a basis for incremental deployment.











Agreed.
























 "The Working Group will coordinate clo=
sely with other Working Groups and

IRTF Research Groups."

You should list the WGs you have in mind.











I agree that it looks odd as it stands. I'm not sure what the right ap=
proach is here (simply remove? or what are these groups?) - e.g. Spencer wo=
uld know better than me=85


















I think the key thing here was that we aren=92t only limiting ourselve=
s to working with the IETF but are also interested in getting input from th=
e IRTF. However I think we can drop this










Agreed.







Cheers,


Michael











 


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











___________________________________________=
____

Taps mailing list

Taps@ietf.org<=
/span>

https://www.ietf.org/mailman/listinfo/taps











_______________________________________________

Taps mailing list

Taps@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/taps














___________________________________________=
____

Taps mailing list

Taps@ietf.org

https://www.ie=
tf.org/mailman/listinfo/taps





_______________________________________________

Taps mailing list

Taps@ietf.org

https://www.ietf.org/mailman/listinfo/taps














--_000_29a76b83add64d6cbe70b53a37cb419eAMSPR06MB439eurprd06pro_--


From nobody Sun Jun 29 06:05:54 2014
Return-Path: 
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EB81A04AC for ; Sun, 29 Jun 2014 06:05:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level: 
X-Spam-Status: No, score=-15.151 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_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 9f4mHOwGXJQX for ; Sun, 29 Jun 2014 06:05:43 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2651A04A2 for ; Sun, 29 Jun 2014 06:05:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=79259; q=dns/txt; s=iport; t=1404047143; x=1405256743; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=dNCnrvrUhWw5O9oEBK9aXd5Avsf2aVoj2q6ykgSE3BY=; b=bqSgZb8Hf+pW9i2Zeu7dgxQbsOH8aJ5z2MrwDLZUhleTLKu2YohzYwp/ ikEKjfoS4ad11/UbHv0I3a1ZBCiAa3qxWxzYDuXRnV0GCgzZLp4T1J4rp Ap48tvK+ZvUIkLtwk989dL6cH/yR6ECHxqaxVUXceEPJKPydfbtERelom Q=;
X-IronPort-AV: E=Sophos;i="5.01,570,1400025600";  d="scan'208,217";a="336267288"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP; 29 Jun 2014 13:05:42 +0000
Received: from ELEAR-M-C3ZS.CISCO.COM (rtp-vpn4-755.cisco.com [10.82.210.243]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s5TD5fpK003473; Sun, 29 Jun 2014 13:05:41 GMT
Message-ID: <53B00F25.2080500@cisco.com>
Date: Sun, 29 Jun 2014 09:05:41 -0400
From: Eliot Lear 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Michael Welzl , Aaron Falk 
References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACAFDA.3060303@gmail.com> <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> <53AD74D8.9010906@gmail.com>  <33966B16-D15B-49E5-BEBD-C8DE990F8028@ifi.uio.no> <53AD88BD.6090003@kau.se> <0305821c865245e08cc4531ff66d9c7d@AMSPR06MB439.eurprd06.prod.outlook.com> <12FABC6F-187D-479C-8A72-4D1FBC5C25FC@mjmontpetit.com>   <01441810-A702-4DC2-B74C-6C0DC6F5235B@ifi.uio.no>
In-Reply-To: <01441810-A702-4DC2-B74C-6C0DC6F5235B@ifi.uio.no>
X-Enigmail-Version: 1.6
Content-Type: multipart/alternative; boundary="------------030806030802000602030101"
Archived-At: http://mailarchive.ietf.org/arch/msg/taps/aSw6vjokCdEXIG-6OasNa-wgiwg
Cc: "" , Marie-Jose Montpetit , Spencer Dawkins , "" , "bclaise@cisco.com" , "" 
Subject: Re: [Taps] Charter bikeshed #1 - "transport service"
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Jun 2014 13:05:49 -0000

This is a multi-part message in MIME format.
--------------030806030802000602030101
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Michael,

Probably a good idea to put out a clean version of what you believe we
have converged on. There's a lot of depth to this discussion, much in
the form of >>>>,

Eliot

On 6/29/14, 5:42 AM, Michael Welzl wrote:
> If noone reacts by tomorrow, I'd suggest to assume the list's charter
> discussion has converged with Anna's last message.
>
> I didn't want to kill off this discussion, however. I'll answer
> Aaron's email but with a different subject  :-)
>
> Cheers,
> Michael
>
>
> On 28. juni 2014, at 19:12, Michael Welzl  > wrote:
>
>> one thing matters here, now: this is not about charter text, right?
>>
>> Sent from my iPhone
>>
>> On 28. juni 2014, at 16:46, Aaron Falk > > wrote:
>>
>>> Sounds like there are two points here worth teasing apart:
>>>
>>> 1. "reliable erasure-free DELIVERY" vs "reliable error-free CONTENT
>>> that is delivered" are different
>>>
>>> and 
>>>
>>> 2. Each is a 'dimension' rather than a binary characteristic (like,
>>> say, in order delivery)
>>>
>>> --aaron
>>>
>>>
>>> On Sat, Jun 28, 2014 at 6:08 AM, Marie-Jose Montpetit
>>> > wrote:
>>>
>>>     I would say that we should not limit it to one or the other but
>>>     make it dependent on the application requirement.
>>>
>>>     Marie-José Montpetit
>>>     marie@mjmontpetit.com 
>>>     mariejo@mit.edu 
>>>
>>>     On Jun 28, 2014, at 5:31, >>     > wrote:
>>>
>>>>     on reliability, are we talking of reliable erasure-free
>>>>     DELIVERY or reliable error-free CONTENT that is delivered?
>>>>
>>>>     Two dimensions here. We spent a few years debating the nuances
>>>>     in DTNRG.
>>>>
>>>>     e.g. TCP is thought to offer both, but its payload content
>>>>     check is weak. SCTP can vary delivery reliability, while its
>>>>     payload check is stronger. UDP-Lite doesn't give reliable
>>>>     delivery, its content check can vary, etc.
>>>>     ------------------------------------------------------------------------
>>>>     *From:* Taps >>>     > on behalf of Anna Brunstrom
>>>>     >
>>>>     *Sent:* Saturday, 28 June 2014 1:07:41 AM
>>>>     *To:* taps@ietf.org 
>>>>     *Cc:* bclaise@cisco.com ;
>>>>     spencerdawkins.ietf@gmail.com
>>>>     
>>>>     *Subject:* Re: [Taps] Charter bikeshed #1 - "transport service"
>>>>      
>>>>     Hi,
>>>>
>>>>     Repeating one of my comments on the long mail to this more
>>>>     manageable version that Micheal produced while I was reading.
>>>>
>>>>     Anna
>>>>
>>>>     On 2014-06-27 16:38, Michael Welzl wrote:
>>>>>     Hi,
>>>>>
>>>>>     I'll cut away a lot now, and only address things that need
>>>>>     addressing below:
>>>>>
>>>>>
>>>>>     On 27. juni 2014, at 16:21, Toby Moncaster
>>>>>     >>>>     > wrote:
>>>>>
>>>>>     [snip]
>>>>>
>>>>>>     I agree with Michael here. I think we could end up with a
>>>>>>     much less clearly worded charter if we go down that route. If
>>>>>>     there is a need to be more precise then I’d favour adding
>>>>>>     something near the beginning of the charter along the lines
>>>>>>     of the definition I put in the Problem Statement document.
>>>>>>     Namely:  "A Transport Service is any service provided by the
>>>>>>     transport layer that can only be correctly implemented with
>>>>>>     information from the application.”We could then include 2 or
>>>>>>     3 example services
>>>>>
>>>>>     I agree. Putting that definition in there would be nice.
>>>>>
>>>>>
>>>>>>>>>>         - full reliability
>>>>>>>>>>         - latency-limited reliability
>>>>>>>>>
>>>>>>>>     Yes, reliability is a service, and fine to include in the
>>>>>>>>     list. But I'd rather replace this with any of:
>>>>>>>>     "various degrees of reliability" or "various forms of
>>>>>>>>     reliability" or "full / latency-limited / no reliability"
>>>>>>>>     ...or something like that.  One item, not two, anyway.
>>>>>>
>>>>>>
>>>>>>     Hmmm. I’d rather we had something like “Degree of reliability
>>>>>>     from unreliable to full reliability."
>>>>>
>>>>>     Agree.
>>>>>
>>>>>
>>>>>>>>     Second, using the phrase "congestion control" binds the
>>>>>>>>     application requirement to a specific mechanism. I'd rather
>>>>>>>>     use something like "low delay vs. high throughput”.
>>>>>>
>>>>>>     Perhaps this would best be expressed as “Trading off latency
>>>>>>     and throughput"
>>>>>
>>>>>     Agree.
>>>>>
>>>>>
>>>>>>>>>>     I don't know if this list is correct or complete. This
>>>>>>>>>>     should be the WG
>>>>>>>>>>     job to compile it.
>>>>>>>>>>     Btw, adding this list to the charter, as a starting
>>>>>>>>>>     point, would make
>>>>>>>>>>     sense.
>>>>>>>>
>>>>>>>>     So, to summarize, here's the complete list that I suggest:
>>>>>>>>
>>>>>>>>     - sequence preservation
>>>>>>>>     - various degrees of reliability
>>>>>>>>     - low delay vs. high throughput
>>>>>>
>>>>>>     I’d rephrase this as:
>>>>>>
>>>>>>     - ordering/sequence preservation
>>>>>>     - degree of reliability 
>>>>>>     - latency vs throughput
>>>>>
>>>>>     Agree, this is nicer!
>>>>>
>>>>>
>>>>>>>>>>     How do we call the transport that support those 5 things?
>>>>>>>>>>     a transport
>>>>>>>>>>     protocol? a transport service?
>>>>>>>>>>     The "services" term is used multiple times within the
>>>>>>>>>>     charter.
>>>>>>>>>>     Sometimes I understand it as a "transport protocol" (like
>>>>>>>>>>     in the first
>>>>>>>>>>     sentence in the charter),
>>>>>>>>>>     And sometimes I may interpret it as Brian's "dimensions
>>>>>>>>>>     of transport" or
>>>>>>>>>>     criteria.
>>>>>>>>>>
>>>>>>>>>>     Potentially use "criteria" and "transport protocol"
>>>>>>>>>>     Alternatively, only use "transport services" when it
>>>>>>>>>>     means "criteria, and
>>>>>>>>>>     "transport protocol".
>>>>>>>>>>     I tried to do the latter below.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>     Again, detailed comments in line:
>>>>>>>>
>>>>>>>>
>>>>>>>>>>     OLD:
>>>>>>>>>>
>>>>>>>>>>     Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
>>>>>>>>>>     UDP-Lite and the LEDBAT congestion control mechanism extend
>>>>>>>>>>     the set of transport services that are available to
>>>>>>>>>>     applications, beyond those provided by TCP and UDP. For
>>>>>>>>>>     example, SCTP provides potentially faster reliable delivery
>>>>>>>>>>     for applications that can accept blocks of data out of order,
>>>>>>>>>>     and LEDBAT provides low-priority "scavenger" communication.
>>>>>>>>>>
>>>>>>>>>>     NEW:
>>>>>>>>>>     Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
>>>>>>>>>>     UDP-Lite and the LEDBAT congestion control mechanism extend
>>>>>>>>>>     the set of transport protocols that are available to
>>>>>>>>>>     applications, beyond those provided by TCP and UDP. For
>>>>>>>>>>     example, SCTP provides potentially faster reliable delivery
>>>>>>>>>>     for applications that can accept blocks of data out of order,
>>>>>>>>>>     and LEDBAT provides low-priority "scavenger" communication.
>>>>>>>>
>>>>>>>>     Disagree, I'd rather leave it as it is to stress that
>>>>>>>>     applications use services, not protocols.
>>>>>>
>>>>>>
>>>>>>     I actually think changing that to protocols might be a good
>>>>>>     thing, since it highlights how complex the landscape has become. 
>>>>>
>>>>
>>>>     I disagree. The "For example" list gets very strange as
>>>>     examples of transport protocols. I also agree with Michael's
>>>>     original objection: stressing that applications use services is
>>>>     important.
>>>>
>>>>
>>>>
>>>>>     Okay, fine by me. I don't have a strong opinion here either way.
>>>>>
>>>>>
>>>>>>>>>>     OLD:
>>>>>>>>>>
>>>>>>>>>>     - Identify services provided by existing IETF transport
>>>>>>>>>>     protocols
>>>>>>>>>>       and congestion control mechanisms. The resulting
>>>>>>>>>>     document will
>>>>>>>>>>       provide guidance on making a choice among available
>>>>>>>>>>     mechanisms
>>>>>>>>>>       and protocols to obtain a certain transport service.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>     NEW:
>>>>>>>>>>
>>>>>>>>>>     - Identify transport services provided by existing IETF
>>>>>>>>>>     transport
>>>>>>>>>>     protocols
>>>>>>>>>>       and congestion control mechanisms. The resulting
>>>>>>>>>>     document will
>>>>>>>>>>       provide guidance on making a choice among available
>>>>>>>>>>     mechanisms
>>>>>>>>>>       and protocols to obtain a certain transport service. As
>>>>>>>>>>     a starting
>>>>>>>>>>     point
>>>>>>>>>>       for transport services, the working group can consider:
>>>>>>>>>>     message
>>>>>>>>>>     atomicity,
>>>>>>>>>>       stream fragmentation, sequence preservation,
>>>>>>>>>>     head-of-line blocking
>>>>>>>>>>     avoidance,
>>>>>>>>>>       sub-channels, full reliability, latency-limited
>>>>>>>>>>     reliability,
>>>>>>>>>>     loss-sensitive
>>>>>>>>>>       congestion control, delay-sensitive congestion control,
>>>>>>>>>>     endpoint
>>>>>>>>>>     address agility,
>>>>>>>>>>       privacy and integrity, and path-state propagation
>>>>>>>>>>     (NAT/Firewall).
>>>>>>>>
>>>>>>>>     Sentence 1: "transport services provided by ..  transport
>>>>>>>>     protocols" doesn't seem to make things clearer. I'd rather
>>>>>>>>     keep "services" in this sentence - what this means gets
>>>>>>>>     concrete anyway due to the list that follows in sentence 3,
>>>>>>>>     and there the phrase "transport services" is used anyway.
>>>>>>>>     The list should be changed, as I argued above. I suggest:
>>>>>>>>
>>>>>>>>     NEW:
>>>>>>>>
>>>>>>>>     - Identify services provided by existing IETF transport
>>>>>>>>     protocols
>>>>>>>>       and congestion control mechanisms. The resulting document
>>>>>>>>     will
>>>>>>>>       provide guidance on making a choice among available
>>>>>>>>     mechanisms
>>>>>>>>       and protocols to obtain a certain transport service. As a
>>>>>>>>     starting point
>>>>>>>>       for transport services, the working group can consider:
>>>>>>>>     sequence
>>>>>>>>       preservation, various degrees of reliability, low delay
>>>>>>>>     vs. high throughput.
>>>>>>
>>>>>>     I think here we’re once again running into the difficulty of
>>>>>>     the ambiguity of the word “transport”, especially in the
>>>>>>     IETF… If we have defined Transport Services in terms of the
>>>>>>     transport protocol earlier in the document, can we actually
>>>>>>     phrase this
>>>>>>
>>>>>>     - Identify Transport Services provided by IETF protocols and
>>>>>>     congestion control mechanisms
>>>>>
>>>>>     Agreed
>>>>>
>>>>>
>>>>>>>>>>     OLD:
>>>>>>>>>>     - Specify experimental mechanisms to deliver a transport
>>>>>>>>>>     service.
>>>>>>>>>>       This will explain how to select and engage a protocol,
>>>>>>>>>>     and how
>>>>>>>>>>       to discover the availability of protocols on an
>>>>>>>>>>     interface (both
>>>>>>>>>>       end system and path support), in order to provide a
>>>>>>>>>>     basis for
>>>>>>>>>>       incremental deployment.
>>>>>>>>>>
>>>>>>>>>>     NEW:
>>>>>>>>>>     - Specify experimental mechanisms to deliver a transport
>>>>>>>>>>     protocol.
>>>>>>>>>>       This will explain how to select and engage a protocol,
>>>>>>>>>>     and how
>>>>>>>>>>       to discover the availability of protocol services on an
>>>>>>>>>>     interface (both
>>>>>>>>>>
>>>>>>>>>>       end system and path support), in order to provide a
>>>>>>>>>>     basis for
>>>>>>>>>>       incremental deployment.
>>>>>>>>
>>>>>>>>
>>>>>>>>     Disagree. "deliver a transport protocol" is weird. The
>>>>>>>>     intention was to say "provide a transport service", maybe
>>>>>>>>     "deliver" is a bad choice of words here? So I suggest:
>>>>>>>>
>>>>>>>>     NEW:
>>>>>>>>     - Specify experimental mechanisms to provide a transport
>>>>>>>>     service.
>>>>>>>>       This will explain how to select and engage a protocol,
>>>>>>>>     and how
>>>>>>>>       to discover the availability of protocols on an interface
>>>>>>>>     (both
>>>>>>>>       end system and path support), in order to provide a basis for
>>>>>>>>       incremental deployment.
>>>>>>
>>>>>>     Specify experimental mechanisms to provide a given Transport
>>>>>>     Service. 
>>>>>>     This will explain how to select and engage an appropriate
>>>>>>     protocol and 
>>>>>>     how to discover which protocols are available for a given
>>>>>>     connection. 
>>>>>>     This will provide a basis for incremental deployment.
>>>>>
>>>>>     Agreed.
>>>>>
>>>>>
>>>>>>>>>>      "The Working Group will coordinate closely with other
>>>>>>>>>>     Working Groups and
>>>>>>>>>>     IRTF Research Groups."
>>>>>>>>>>     You should list the WGs you have in mind.
>>>>>>>>
>>>>>>>>     I agree that it looks odd as it stands. I'm not sure what
>>>>>>>>     the right approach is here (simply remove? or what are
>>>>>>>>     these groups?) - e.g. Spencer would know better than me…
>>>>>>
>>>>>>
>>>>>>     I think the key thing here was that we aren’t only limiting
>>>>>>     ourselves to working with the IETF but are also interested in
>>>>>>     getting input from the IRTF. However I think we can drop this
>>>>>
>>>>>     Agreed.
>>>>>
>>>>>     Cheers,
>>>>>     Michael
>>>>>
>>>>>
>>>>>
>>>>>     _______________________________________________
>>>>>     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


--------------030806030802000602030101
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Michael,

    

    Probably a good idea to put out a clean version of what you believe
    we have converged on. There's a lot of depth to this discussion,
    much in the form of >>>>,

    

    Eliot

    

    
On 6/29/14, 5:42 AM, Michael Welzl
      wrote:

    

    

      
      If noone reacts by tomorrow, I'd suggest to assume the list's
      charter discussion has converged with Anna's last message.
      


      

      
I didn't want to kill off this discussion, however. I'll
        answer Aaron's email but with a different subject  :-)

      


      

      
Cheers,

      
Michael

      


      

      


        

          
On 28. juni 2014, at 19:12, Michael Welzl <michawe@ifi.uio.no>
            wrote:

          

          

            

              
one thing matters here, now: this is not about
                charter text, right?

                

                Sent from my iPhone

              


                On 28. juni 2014, at 16:46, Aaron Falk <falk-ietf@dgftech.com>
                wrote:

                

              

              

                
Sounds like there are two points here
                  worth teasing apart:
                  


                  

                  
1. "reliable
                      erasure-free DELIVERY" vs "reliable error-free
                      CONTENT that is delivered" are different

                  


                    

                  
and 

                  


                    

                  
2.
                      Each is a 'dimension' rather than a binary
                      characteristic (like, say, in order delivery)

                  


                    

                  
--aaron

                

                


                  

                  
On Sat, Jun 28, 2014 at 6:08
                    AM, Marie-Jose Montpetit <marie@mjmontpetit.com>
                    wrote:

                    

                      

                        
I would say that we should not limit it to
                          one or the other but make it dependent on the
                          application requirement.

                          

                          Marie-José Montpetit
                          
                          
                        

                        

                          

                            


                              On Jun 28, 2014, at 5:31, <l.wood@surrey.ac.uk>
                              wrote:

                              

                            

                            

                              on reliability, are we talking of reliable
                              erasure-free DELIVERY or reliable
                              error-free CONTENT that is delivered?

                              

                              Two dimensions here. We spent a few years
                              debating the nuances in DTNRG.

                              

                              e.g. TCP is thought to offer both, but its
                              payload content check is weak. SCTP can
                              vary delivery reliability, while its
                              payload check is stronger. UDP-Lite
                              doesn't give reliable delivery, its
                              content check can vary, etc.
                              

                              
From: Taps <taps-bounces@ietf.org>
                                  on behalf of Anna Brunstrom <anna.brunstrom@kau.se>

                                  Sent: Saturday, 28 June 2014
                                  1:07:41 AM

                                  To: taps@ietf.org

                                  Cc: bclaise@cisco.com;
                                  spencerdawkins.ietf@gmail.com

                                  Subject: Re: [Taps] Charter
                                  bikeshed #1 - "transport service"
                                
 

                              

                              
Hi,

                                

                                Repeating one of my comments on the long
                                mail to this more manageable version
                                that Micheal produced while I was
                                reading.

                                

                                Anna 

                                

                                On 2014-06-27 16:38, Michael Welzl
                                wrote:

                                

                                  
Hi,

                                  


                                  

                                  
I'll cut away a lot now, and only
                                    address things that need addressing
                                    below:

                                  


                                  

                                  


                                  

                                  

                                    

                                      
On 27. juni 2014, at 16:21,
                                        Toby Moncaster <toby.moncaster@cl.cam.ac.uk>
                                        wrote:

                                      


                                      

                                      [snip]

                                    


                                    

                                    

                                      

                                        

                                          I agree with Michael here. I
                                          think we could end up with a
                                          much less clearly worded
                                          charter if we go down that
                                          route. If there is a need to
                                          be more precise then I’d
                                          favour adding something near
                                          the beginning of the charter
                                          along the lines of the
                                          definition I put in the
                                          Problem Statement document.
                                          Namely:  "A
                                            Transport Service is any
                                            service provided by the
                                            transport layer that can
                                            only be correctly
                                            implemented with information
                                            from the application.”We
                                            could then include 2 or 3
                                            example services 

                                      

                                      

                                        

                                          

                                          

                                      

                                      

                                        I
                                          agree. Putting that definition
                                          in there would be nice.

                                      

                                        

                                        

                                    

                                    


                                    

                                    

                                      

                                        

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      
    -
                                                        full reliability

                                                      

                                                    

                                                    

                                                      

                                                        
 
                                                            -
                                                          latency-limited
                                                          reliability

                                                        

                                                      

                                                      

                                                        


                                                        

                                                      

                                                    

                                                    
Yes,
                                                      reliability is a
                                                      service, and fine
                                                      to include in the
                                                      list. But I'd
                                                      rather replace
                                                      this with any of:

                                                    
"various
                                                      degrees of
                                                      reliability" or
                                                      "various forms of
                                                      reliability" or
                                                      "full /
                                                      latency-limited /
                                                      no reliability"

                                                    
...or something
                                                      like that.  One
                                                      item, not two,
                                                      anyway.

                                                  

                                                

                                              

                                              


                                              

                                              


                                              

                                              
Hmmm. I’d rather we
                                                had something like
                                                “Degree of reliability
                                                from unreliable to full
                                                reliability."

                                            

                                          

                                        

                                      

                                      


                                      

                                      Agree.

                                    


                                    

                                    


                                    

                                    

                                      

                                        

                                          

                                            

                                              

                                                

                                                  

                                                    
Second, using
                                                      the phrase
                                                      "congestion
                                                      control" binds the
                                                      application
                                                      requirement to a
                                                      specific
                                                      mechanism. I'd
                                                      rather use
                                                      something like
                                                      "low delay vs.
                                                      high throughput”.

                                                  

                                                

                                              

                                              


                                              

                                              
Perhaps this would
                                                best be expressed as
                                                “Trading off latency and
                                                throughput"

                                            

                                          

                                        

                                      

                                      


                                      

                                      
Agree.

                                      


                                      

                                      

                                      

                                        

                                          

                                            

                                              

                                                

                                                  

                                                    

                                                      
I
                                                        don't know if
                                                        this list is
                                                        correct or
                                                        complete. This
                                                        should be the WG

                                                        job to compile
                                                        it.

                                                        Btw, adding this
                                                        list to the
                                                        charter, as a
                                                        starting point,
                                                        would make

                                                        sense.

                                                      

                                                    

                                                    


                                                    

                                                    
So, to
                                                      summarize, here's
                                                      the complete list
                                                      that I suggest:

                                                    


                                                    

                                                    
- sequence
                                                      preservation

                                                    
- various
                                                      degrees of
                                                      reliability

                                                    
- low delay vs.
                                                      high throughput

                                                  

                                                

                                              

                                              


                                              

                                              
I’d rephrase this as:

                                              


                                              

                                              
- ordering/sequence
                                                preservation

                                              
- degree of
                                                reliability 

                                              
- latency vs
                                                throughput

                                            

                                          

                                        

                                      

                                      


                                      

                                      Agree, this is nicer!

                                    


                                    

                                    


                                    

                                    

                                      

                                        

                                          

                                            

                                              

                                                

                                                  

                                                    
How do
                                                      we call the
                                                      transport that
                                                      support those 5
                                                      things? a
                                                      transport

                                                      protocol? a
                                                      transport service?

                                                      The "services"
                                                      term is used
                                                      multiple times
                                                      within the
                                                      charter.

                                                      Sometimes I
                                                      understand it as a
                                                      "transport
                                                      protocol" (like in
                                                      the first

                                                      sentence in the
                                                      charter),

                                                      And sometimes I
                                                      may interpret it
                                                      as Brian's
                                                      "dimensions of
                                                      transport" or

                                                      criteria.

                                                      

                                                      Potentially use
                                                      "criteria" and
                                                      "transport
                                                      protocol"

                                                      Alternatively,
                                                      only use
                                                      "transport
                                                      services" when it
                                                      means "criteria,
                                                      and

                                                      "transport
                                                      protocol".

                                                      I tried to do the
                                                      latter below.

                                                      

                                                      

                                                    

                                                  

                                                  


                                                  

                                                  Again, detailed
                                                  comments in line:

                                                


                                                

                                                


                                                  

                                                    
OLD:

                                                      

                                                      Conjointly,
                                                      transport
                                                      protocols such as
                                                      SCTP, DCCP, MPTCP,

                                                      UDP-Lite and the
                                                      LEDBAT congestion
                                                      control mechanism
                                                      extend

                                                      the set of
                                                      transport services
                                                      that are available
                                                      to

                                                      applications,
                                                      beyond those
                                                      provided by TCP
                                                      and UDP. For

                                                      example, SCTP
                                                      provides
                                                      potentially faster
                                                      reliable delivery

                                                      for applications
                                                      that can accept
                                                      blocks of data out
                                                      of order,

                                                      and LEDBAT
                                                      provides
                                                      low-priority
                                                      "scavenger"
                                                      communication.

                                                      

                                                      NEW:

                                                      Conjointly,
                                                      transport
                                                      protocols such as
                                                      SCTP, DCCP, MPTCP,

                                                      UDP-Lite and the
                                                      LEDBAT congestion
                                                      control mechanism
                                                      extend

                                                      the set of
                                                      transport
                                                      protocols that are
                                                      available to

                                                      applications,
                                                      beyond those
                                                      provided by TCP
                                                      and UDP. For

                                                      example, SCTP
                                                      provides
                                                      potentially faster
                                                      reliable delivery

                                                      for applications
                                                      that can accept
                                                      blocks of data out
                                                      of order,

                                                      and LEDBAT
                                                      provides
                                                      low-priority
                                                      "scavenger"
                                                      communication.

                                                    

                                                  

                                                  


                                                  

                                                  Disagree, I'd rather
                                                  leave it as it is to
                                                  stress that
                                                  applications use
                                                  services, not
                                                  protocols.

                                              

                                            

                                          

                                          


                                          

                                          


                                          

                                          
I actually think changing
                                            that to protocols might be a
                                            good thing, since it
                                            highlights how complex the
                                            landscape has become. 

                                        

                                      

                                      


                                      

                                    

                                  

                                

                                

                                I disagree. The "For example" list gets
                                very strange as examples of transport
                                protocols. I also agree with Michael's
                                original objection: stressing that
                                applications use services is important.

                                

                                

                                

                                

                                  

                                    

                                      
Okay, fine by me. I don't
                                        have a strong opinion here
                                        either way.

                                    

                                  

                                

                                

                                  

                                    

                                      


                                      

                                      

                                      

                                        

                                          

                                            

                                              

                                                

                                                  

                                                    
OLD:

                                                      

                                                      - Identify
                                                      services provided
                                                      by existing IETF
                                                      transport
                                                      protocols

                                                        and congestion
                                                      control
                                                      mechanisms. The
                                                      resulting document
                                                      will

                                                        provide guidance
                                                      on making a choice
                                                      among available
                                                      mechanisms

                                                        and protocols to
                                                      obtain a certain
                                                      transport service.

                                                      

                                                      

                                                      NEW:

                                                      

                                                      - Identify
                                                      transport services
                                                      provided by
                                                      existing IETF
                                                      transport

                                                      protocols

                                                        and congestion
                                                      control
                                                      mechanisms. The
                                                      resulting document
                                                      will

                                                        provide guidance
                                                      on making a choice
                                                      among available
                                                      mechanisms

                                                        and protocols to
                                                      obtain a certain
                                                      transport service.
                                                      As a starting

                                                      point

                                                        for transport
                                                      services, the
                                                      working group can
                                                      consider: message

                                                      atomicity,

                                                        stream
                                                      fragmentation,
                                                      sequence
                                                      preservation,
                                                      head-of-line
                                                      blocking

                                                      avoidance,

                                                        sub-channels,
                                                      full reliability,
                                                      latency-limited
                                                      reliability,

                                                      loss-sensitive

                                                        congestion
                                                      control,
                                                      delay-sensitive
                                                      congestion
                                                      control, endpoint

                                                      address agility,

                                                        privacy and
                                                      integrity, and
                                                      path-state
                                                      propagation
                                                      (NAT/Firewall).

                                                    

                                                  

                                                  


                                                  

                                                  
Sentence 1:
                                                    "transport services
                                                    provided by ..
                                                     transport
                                                    protocols" doesn't
                                                    seem to make things
                                                    clearer. I'd rather
                                                    keep "services" in
                                                    this sentence - what
                                                    this means gets
                                                    concrete anyway due
                                                    to the list that
                                                    follows in sentence
                                                    3, and there the
                                                    phrase "transport
                                                    services" is used
                                                    anyway. The list
                                                    should be changed,
                                                    as I argued above. I
                                                    suggest:

                                                  


                                                  

                                                  
NEW:

                                                  


                                                  

                                                  
- Identify
                                                    services provided by
                                                    existing IETF
                                                    transport protocols

                                                      and congestion
                                                    control mechanisms.
                                                    The resulting
                                                    document will

                                                      provide guidance
                                                    on making a choice
                                                    among available
                                                    mechanisms

                                                      and protocols to
                                                    obtain a certain
                                                    transport service.
                                                    As a starting point

                                                  
  for transport
                                                    services, the
                                                    working group can
                                                    consider: sequence

                                                  
  preservation,
                                                    various degrees of
                                                    reliability, low
                                                    delay vs. high
                                                    throughput.

                                                

                                              

                                            

                                          

                                          


                                          

                                          
I think here we’re once
                                            again running into the
                                            difficulty of the ambiguity
                                            of the word “transport”,
                                            especially in the IETF… If
                                            we have defined Transport
                                            Services in terms of the
                                            transport protocol earlier
                                            in the document, can we
                                            actually phrase this

                                          


                                          

                                          
- Identify Transport
                                            Services provided by IETF
                                            protocols and congestion
                                            control mechanisms

                                        

                                      

                                      


                                      

                                      Agreed

                                    


                                    

                                    


                                      

                                        

                                          

                                            

                                              

                                                

                                                  

                                                    
OLD:

                                                      - Specify
                                                      experimental
                                                      mechanisms to
                                                      deliver a
                                                      transport service.

                                                        This will
                                                      explain how to
                                                      select and engage
                                                      a protocol, and
                                                      how

                                                        to discover the
                                                      availability of
                                                      protocols on an
                                                      interface (both

                                                        end system and
                                                      path support), in
                                                      order to provide a
                                                      basis for

                                                        incremental
                                                      deployment.

                                                      

                                                      NEW:

                                                      - Specify
                                                      experimental
                                                      mechanisms to
                                                      deliver a
                                                      transport
                                                      protocol.

                                                        This will
                                                      explain how to
                                                      select and engage
                                                      a protocol, and
                                                      how

                                                        to discover the
                                                      availability of
                                                      protocol services
                                                      on an interface
                                                      (both

                                                      

                                                        end system and
                                                      path support), in
                                                      order to provide a
                                                      basis for

                                                        incremental
                                                      deployment.

                                                    

                                                  

                                                  


                                                  

                                                  


                                                  

                                                  Disagree. "deliver a
                                                  transport protocol" is
                                                  weird. The intention
                                                  was to say "provide a
                                                  transport service",
                                                  maybe "deliver" is a
                                                  bad choice of words
                                                  here? So I suggest:

                                                


                                                

                                                
NEW:

                                                  - Specify experimental
                                                  mechanisms to provide
                                                  a transport service.

                                                    This will explain
                                                  how to select and
                                                  engage a protocol, and
                                                  how

                                                    to discover the
                                                  availability of
                                                  protocols on an
                                                  interface (both

                                                    end system and path
                                                  support), in order to
                                                  provide a basis for

                                                    incremental
                                                  deployment.

                                              

                                            

                                          

                                          


                                          

                                          
Specify experimental
                                            mechanisms to provide a
                                            given Transport Service. 

                                          
This will explain how to
                                            select and engage an
                                            appropriate protocol and 

                                          
how to discover which
                                            protocols are available for
                                            a given connection. 

                                          
This will provide a basis
                                            for incremental deployment.

                                        

                                      

                                      


                                      

                                      
Agreed.

                                      


                                      

                                      


                                      

                                      

                                        

                                          

                                            

                                              

                                                

                                                  
 "The
                                                    Working Group will
                                                    coordinate closely
                                                    with other Working
                                                    Groups and

                                                    IRTF Research
                                                    Groups."

                                                    You should list the
                                                    WGs you have in
                                                    mind.

                                                  

                                                

                                                


                                                

                                                
I agree that it
                                                  looks odd as it
                                                  stands. I'm not sure
                                                  what the right
                                                  approach is here
                                                  (simply remove? or
                                                  what are these
                                                  groups?) - e.g.
                                                  Spencer would know
                                                  better than me…

                                              

                                            

                                          

                                          


                                          

                                          


                                          

                                          
I think the key thing
                                            here was that we aren’t only
                                            limiting ourselves to
                                            working with the IETF but
                                            are also interested in
                                            getting input from the IRTF.
                                            However I think we can drop
                                            this

                                        

                                      

                                      


                                      

                                      Agreed.

                                    


                                    

                                    
Cheers,

                                    
Michael

                                    


                                    

                                  

                                  

                                  

                                  

                                  
_______________________________________________
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


    

    

  


--------------030806030802000602030101--


From nobody Sun Jun 29 06:32:38 2014
Return-Path: 
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3951A04B8 for ; Sun, 29 Jun 2014 06:32:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 7xTKwvi7DYCA for ; Sun, 29 Jun 2014 06:32:35 -0700 (PDT)
Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 132131A04AC for ; Sun, 29 Jun 2014 06:32:35 -0700 (PDT)
Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1X1FDa-00037O-Er; Sun, 29 Jun 2014 15:32:30 +0200
Received: from 089144222109.atnat0031.highway.bob.at ([89.144.222.109] helo=[192.168.0.100]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1X1FDX-0006ri-KX; Sun, 29 Jun 2014 15:32:30 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Michael Welzl 
In-Reply-To: <53B00F25.2080500@cisco.com>
Date: Sun, 29 Jun 2014 15:32:15 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6985717F-D141-430B-A151-8D63D3CC61B8@ifi.uio.no>
References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACAFDA.3060303@gmail.com> <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> <53AD74D8.9010906@gmail.com>  <33966B16-D15B-49E5-BEBD-C8DE990F8028@ifi.uio.no> <53AD88BD.6090003@kau.se> <0305821c865245e08cc4531ff66d9c7d@AMSPR06MB439.eurprd06.prod.outlook.com> <12FABC6F-187D-479C-8A72-4D1FBC5C25FC@mjmontpetit.com>   <01441810-A702-4DC2-B74C-6C0DC6F5235B@ifi.uio.no> <53B00F25.2080500@cisco.com>
To: Eliot Lear 
X-Mailer: Apple Mail (2.1878.2)
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 1 sum rcpts/h 11 sum msgs/h 2 total rcpts 17986 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: DA0F230C313320DBACDAC715412BBA6D5D02A9DE
X-UiO-SPAM-Test: remote_host: 89.144.222.109 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 9 max/h 2 blacklist 0 greylist 0 ratelimit 0
Archived-At: http://mailarchive.ietf.org/arch/msg/taps/Hkj2AZEVtmg8MqmaiE3NKzCRyvs
Cc: Aaron Falk , "" , Marie-Jose Montpetit , Spencer Dawkins , "" , "bclaise@cisco.com" , "" 
Subject: Re: [Taps] Charter bikeshed #1 - "transport service"
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Jun 2014 13:32:38 -0000

On 29. juni 2014, at 15:05, Eliot Lear  wrote:

> Michael,
>=20
> Probably a good idea to put out a clean version of what you believe we =
have converged on. There's a lot of depth to this discussion, much in =
the form of >>>>,
>=20
> Eliot

Great, suggestion, thanks!  It's below.
Note, this is only an update based on Benoit's comments - some others =
have proposed smaller changes (e.g., not starting the charter with =
"Conjointly, ..." ) and I'll leave those up to Spencer  (myself, I'm not =
even a native speaker after all).

Cheers,
Michael



ADD, NEAR THE BEGINNING OF THE CHARTER:

A Transport Service is any service provided by the transport layer that =
can only be correctly implemented with information from the application.



OLD:

Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
UDP-Lite and the LEDBAT congestion control mechanism extend
the set of transport services that are available to
applications, beyond those provided by TCP and UDP. For
example, SCTP provides potentially faster reliable delivery
for applications that can accept blocks of data out of order,
and LEDBAT provides low-priority "scavenger" communication.

NEW:
Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
UDP-Lite and the LEDBAT congestion control mechanism extend
the set of Transport Services that are available to
applications, beyond those provided by TCP and UDP. For
example, SCTP provides potentially faster reliable delivery
for applications that can accept blocks of data out of order,
and LEDBAT provides low-priority "scavenger" communication.



OLD:

- Identify services provided by existing IETF transport protocols
  and congestion control mechanisms. The resulting document will
  provide guidance on making a choice among available mechanisms
  and protocols to obtain a certain transport service.


NEW:

- Identify Transport services provided by existing IETF protocols
  and congestion control mechanisms. The resulting document will
  provide guidance on making a choice among available mechanisms
  and protocols to obtain a certain transport service. As a starting =
point
  for transport services, the working group can consider:
  ordering/sequence preservation, degree of reliability, latency vs =
throughput.




OLD:

- Specify a subset of those services identified in item 1, which
  end systems supporting TAPS need to provide and provide guidance
  on choosing among available mechanisms and protocols to obtain
  a given transport service.

NEW:
- Specify a subset of those transport services identified in item 1,
which end systems supporting TAPS need to provide and provide guidance
  on choosing among available mechanisms and protocols.


OLD:
- Specify experimental mechanisms to deliver a transport service.
  This will explain how to select and engage a protocol, and how
  to discover the availability of protocols on an interface (both
  end system and path support), in order to provide a basis for
  incremental deployment.

NEW:
- Specify experimental mechanisms to provide a given Transport Service.=20=

This will explain how to select and engage an appropriate protocol and=20=

how to discover which protocols are available for a given connection.=20
This will provide a basis for incremental deployment.


OLD:

    There are many ways in which this problem could be addressed;
    while it may not yet be clear what the best way forward could
    be, any approach to provide a richer set of transport services
    to applications will have to begin with the identification of
    the services that current transport protocols provide.

NEW (this paragraph would make more sense after the 3 bullet points "the
Working Group will")

    The Working Group deliverables will help an application
    programmer identify the important transport services for his
    application and determine if those transport services are available
    on the end points and along the path in the network. An approach to
    provide a richer set of transport services to applications (which
    could be part of a future charter) has to begin with the
identification of
    the services that current transport protocols provide.


OLD:

 "The Working Group will coordinate closely with other Working Groups =
and
IRTF Research Groups."

NEW:  Remove this sentence.


From nobody Sun Jun 29 06:38:24 2014
Return-Path: 
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC1C1A04B9 for ; Sun, 29 Jun 2014 06:38:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 PcnmaDKzWF1J for ; Sun, 29 Jun 2014 06:38:19 -0700 (PDT)
Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 3C4071A04B8 for ; Sun, 29 Jun 2014 06:38:19 -0700 (PDT)
Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1X1FJ9-0005A7-0j; Sun, 29 Jun 2014 15:38:15 +0200
Received: from 089144222109.atnat0031.highway.bob.at ([89.144.222.109] helo=[192.168.0.100]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1X1FJ8-00084Z-27; Sun, 29 Jun 2014 15:38:14 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Michael Welzl 
In-Reply-To: <6985717F-D141-430B-A151-8D63D3CC61B8@ifi.uio.no>
Date: Sun, 29 Jun 2014 15:38:05 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACAFDA.3060303@gmail.com> <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> <53AD74D8.9010906@gmail.com>  <33966B16-D15B-49E5-BEBD-C8DE990F8028@ifi.uio.no> <53AD88BD.6090003@kau.se> <0305821c865245e08cc4531ff66d9c7d@AMSPR06MB439.eurprd06.prod.outlook.com> <12FABC6F-187D-479C-8A72-4D1FBC5C25FC@mjmontpetit.com>   <01441810-A702-4DC2-B74C-6C0DC6F5235B@ifi.uio.no> <53B00F25.2080500@cisco.com> <6985717F-D141-430B-A151-8D63D3CC61B8@ifi.uio.no>
To: Eliot Lear 
X-Mailer: Apple Mail (2.1878.2)
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 17 msgs/h 3 sum rcpts/h 20 sum msgs/h 4 total rcpts 17995 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 6E3F37CF3FFB5CB1E33F7C7A003A1AC55C5A4D83
X-UiO-SPAM-Test: remote_host: 89.144.222.109 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 11 max/h 3 blacklist 0 greylist 0 ratelimit 0
Archived-At: http://mailarchive.ietf.org/arch/msg/taps/SJtmXl1MsZGDtcQOsRIPFhnB6kU
Cc: Aaron Falk , "" , Marie-Jose Montpetit , Spencer Dawkins , "" , "bclaise@cisco.com" , "" 
Subject: Re: [Taps] Charter bikeshed #1 - "transport service"
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Jun 2014 13:38:21 -0000

Sorry for the extra email - just to avoid confusing things even more:


> Great, suggestion, thanks!  It's below.
> Note, this is only an update based on Benoit's comments - some others =
have proposed smaller changes (e.g., not starting the charter with =
"Conjointly, ..." ) and I'll leave those up to Spencer  (myself, I'm not =
even a native speaker after all).

No need to search the list for even more comments  :-)   I should have =
said "some others in the IESG, as shown in the datatracker".

Cheers,
Michael


From nobody Sun Jun 29 14:13:59 2014
Return-Path: 
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449671A0027 for ; Sun, 29 Jun 2014 14:13:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level: 
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
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 XWs7kuFdLUkX for ; Sun, 29 Jun 2014 14:13:53 -0700 (PDT)
Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.149]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D09D1A0025 for ; Sun, 29 Jun 2014 14:13:52 -0700 (PDT)
Received: from [195.245.231.67:13298] by server-13.bemta-5.messagelabs.com id 50/F3-02995-E8180B35; Sun, 29 Jun 2014 21:13:50 +0000
X-Env-Sender: l.wood@surrey.ac.uk
X-Msg-Ref: server-7.tower-82.messagelabs.com!1404076430!26928624!1
X-Originating-IP: [131.227.200.35]
X-StarScan-Received: 
X-StarScan-Version: 6.11.3; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 25456 invoked from network); 29 Jun 2014 21:13:50 -0000
Received: from exht021p.surrey.ac.uk (HELO EXHT021P.surrey.ac.uk) (131.227.200.35) by server-7.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 29 Jun 2014 21:13:50 -0000
Received: from EXHY012V.surrey.ac.uk (131.227.201.103) by EXHT021P.surrey.ac.uk (131.227.200.35) with Microsoft SMTP Server (TLS) id 8.3.348.2; Sun, 29 Jun 2014 22:13:49 +0100
Received: from emea01-db3-obe.outbound.protection.outlook.com (131.227.201.241) by EXHY012v.surrey.ac.uk (131.227.201.103) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 29 Jun 2014 22:13:49 +0100
Received: from AM3PR06MB434.eurprd06.prod.outlook.com (10.242.112.17) by AM3PR06MB435.eurprd06.prod.outlook.com (10.242.112.21) with Microsoft SMTP Server (TLS) id 15.0.974.11; Sun, 29 Jun 2014 21:13:48 +0000
Received: from AM3PR06MB434.eurprd06.prod.outlook.com ([10.242.112.17]) by AM3PR06MB434.eurprd06.prod.outlook.com ([10.242.112.17]) with mapi id 15.00.0974.002; Sun, 29 Jun 2014 21:13:48 +0000
From: 
To: , 
Thread-Topic: [Taps] Charter bikeshed #1 - "transport service"
Thread-Index: AQHPk98Epp9PvhY+OkO75h7vCz/t/w==
Date: Sun, 29 Jun 2014 21:13:47 +0000
Message-ID: <1404042502262.95004@surrey.ac.uk>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [124.149.114.231]
x-microsoft-antispam: BCL:0;PCL:0;RULEID:
x-forefront-prvs: 025796F161
x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199002)(377424004)(377454003)(24454002)(85306003)(74502001)(31966008)(86362001)(64706001)(74662001)(101416001)(74482001)(92566001)(92726001)(95666004)(20776003)(19580405001)(36756003)(15975445006)(19580395003)(4396001)(83072002)(46102001)(85852003)(76482001)(83322001)(50986999)(99396002)(54356999)(2656002)(87936001)(80022001)(66066001)(79102001)(77982001)(81542001)(81342001)(106356001)(106116001)(21056001)(105586002)(107046002)(17413003); DIR:OUT; SFP:; SCL:1; SRVR:AM3PR06MB435; H:AM3PR06MB434.eurprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; LANG:en; 
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OrganizationHeadersPreserved: AM3PR06MB435.eurprd06.prod.outlook.com
X-CrossPremisesHeadersFiltered: EXHY012v.surrey.ac.uk
Archived-At: http://mailarchive.ietf.org/arch/msg/taps/T6RpqlHmcB4d4V7Zhi9c3_BFuhw
Cc: bclaise@cisco.com, marie@mjmontpetit.com, spencerdawkins.ietf@gmail.com, anna.brunstrom@kau.se, taps@ietf.org
Subject: Re: [Taps] Charter bikeshed #1 - "transport service"
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Jun 2014 21:13:56 -0000

I had to look up bikeshed and bikeshedding.=0A=
=0A=
=0A=
Wasn't there a recent RFC on not using slang?=0A=
________________________________=0A=
From: Michael Welzl =0A=
Sent: Sunday, 29 June 2014 7:42:17 PM=0A=
To: Aaron Falk=0A=
Cc: Wood L Dr (Electronic Eng); Marie-Jose Montpetit; Spencer Dawkins; ; bclaise@cisco.com; =0A=
Subject: Re: [Taps] Charter bikeshed #1 - "transport service"=0A=
=0A=
If noone reacts by tomorrow, I'd suggest to assume the list's charter discu=
ssion has converged with Anna's last message.=0A=
=0A=
I didn't want to kill off this discussion, however. I'll answer Aaron's ema=
il but with a different subject  :-)=0A=
=0A=
Cheers,=0A=
Michael=0A=
=0A=
=0A=
On 28. juni 2014, at 19:12, Michael Welzl > wrote:=0A=
=0A=
one thing matters here, now: this is not about charter text, right?=0A=
=0A=
Sent from my iPhone=0A=
=0A=
On 28. juni 2014, at 16:46, Aaron Falk > wrote:=0A=
=0A=
Sounds like there are two points here worth teasing apart:=0A=
=0A=
1. "reliable erasure-free DELIVERY" vs "reliable error-free CONTENT that is=
 delivered" are different=0A=
=0A=
and=0A=
=0A=
2. Each is a 'dimension' rather than a binary characteristic (like, say, in=
 order delivery)=0A=
=0A=
--aaron=0A=
=0A=
=0A=
On Sat, Jun 28, 2014 at 6:08 AM, Marie-Jose Montpetit > wrote:=0A=
I would say that we should not limit it to one or the other but make it dep=
endent on the application requirement.=0A=
=0A=
Marie-Jos=E9 Montpetit=0A=
marie@mjmontpetit.com=0A=
mariejo@mit.edu=0A=
=0A=
On Jun 28, 2014, at 5:31, >=
 wrote:=0A=
=0A=
on reliability, are we talking of reliable erasure-free DELIVERY or reliabl=
e error-free CONTENT that is delivered?=0A=
=0A=
Two dimensions here. We spent a few years debating the nuances in DTNRG.=0A=
=0A=
e.g. TCP is thought to offer both, but its payload content check is weak. S=
CTP can vary delivery reliability, while its payload check is stronger. UDP=
-Lite doesn't give reliable delivery, its content check can vary, etc.=0A=
________________________________=0A=
From: Taps > on behalf =
of Anna Brunstrom >=0A=
Sent: Saturday, 28 June 2014 1:07:41 AM=0A=
To: taps@ietf.org=0A=
Cc: bclaise@cisco.com; spencerdawkins.ietf@gmail.=
com=0A=
Subject: Re: [Taps] Charter bikeshed #1 - "transport service"=0A=
=0A=
Hi,=0A=
=0A=
Repeating one of my comments on the long mail to this more manageable versi=
on that Micheal produced while I was reading.=0A=
=0A=
Anna=0A=
=0A=
On 2014-06-27 16:38, Michael Welzl wrote:=0A=
Hi,=0A=
=0A=
I'll cut away a lot now, and only address things that need addressing below=
:=0A=
=0A=
=0A=
On 27. juni 2014, at 16:21, Toby Moncaster > wrote:=0A=
=0A=
[snip]=0A=
=0A=
I agree with Michael here. I think we could end up with a much less clearly=
 worded charter if we go down that route. If there is a need to be more pre=
cise then I=92d favour adding something near the beginning of the charter a=
long the lines of the definition I put in the Problem Statement document. N=
amely:  "A Transport Service is any service provided by the transport layer=
 that can only be correctly implemented with information from the applicati=
on.=94We could then include 2 or 3 example services=0A=
=0A=
I agree. Putting that definition in there would be nice.=0A=
=0A=
=0A=
    - full reliability=0A=
    - latency-limited reliability=0A=
=0A=
Yes, reliability is a service, and fine to include in the list. But I'd rat=
her replace this with any of:=0A=
"various degrees of reliability" or "various forms of reliability" or "full=
 / latency-limited / no reliability"=0A=
...or something like that.  One item, not two, anyway.=0A=
=0A=
=0A=
Hmmm. I=92d rather we had something like =93Degree of reliability from unre=
liable to full reliability."=0A=
=0A=
Agree.=0A=
=0A=
=0A=
Second, using the phrase "congestion control" binds the application require=
ment to a specific mechanism. I'd rather use something like "low delay vs. =
high throughput=94.=0A=
=0A=
Perhaps this would best be expressed as =93Trading off latency and throughp=
ut"=0A=
=0A=
Agree.=0A=
=0A=
=0A=
I don't know if this list is correct or complete. This should be the WG=0A=
job to compile it.=0A=
Btw, adding this list to the charter, as a starting point, would make=0A=
sense.=0A=
=0A=
So, to summarize, here's the complete list that I suggest:=0A=
=0A=
- sequence preservation=0A=
- various degrees of reliability=0A=
- low delay vs. high throughput=0A=
=0A=
I=92d rephrase this as:=0A=
=0A=
- ordering/sequence preservation=0A=
- degree of reliability=0A=
- latency vs throughput=0A=
=0A=
Agree, this is nicer!=0A=
=0A=
=0A=
How do we call the transport that support those 5 things? a transport=0A=
protocol? a transport service?=0A=
The "services" term is used multiple times within the charter.=0A=
Sometimes I understand it as a "transport protocol" (like in the first=0A=
sentence in the charter),=0A=
And sometimes I may interpret it as Brian's "dimensions of transport" or=0A=
criteria.=0A=
=0A=
Potentially use "criteria" and "transport protocol"=0A=
Alternatively, only use "transport services" when it means "criteria, and=
=0A=
"transport protocol".=0A=
I tried to do the latter below.=0A=
=0A=
=0A=
=0A=
Again, detailed comments in line:=0A=
=0A=
=0A=
OLD:=0A=
=0A=
Conjointly, transport protocols such as SCTP, DCCP, MPTCP,=0A=
UDP-Lite and the LEDBAT congestion control mechanism extend=0A=
the set of transport services that are available to=0A=
applications, beyond those provided by TCP and UDP. For=0A=
example, SCTP provides potentially faster reliable delivery=0A=
for applications that can accept blocks of data out of order,=0A=
and LEDBAT provides low-priority "scavenger" communication.=0A=
=0A=
NEW:=0A=
Conjointly, transport protocols such as SCTP, DCCP, MPTCP,=0A=
UDP-Lite and the LEDBAT congestion control mechanism extend=0A=
the set of transport protocols that are available to=0A=
applications, beyond those provided by TCP and UDP. For=0A=
example, SCTP provides potentially faster reliable delivery=0A=
for applications that can accept blocks of data out of order,=0A=
and LEDBAT provides low-priority "scavenger" communication.=0A=
=0A=
Disagree, I'd rather leave it as it is to stress that applications use serv=
ices, not protocols.=0A=
=0A=
=0A=
I actually think changing that to protocols might be a good thing, since it=
 highlights how complex the landscape has become.=0A=
=0A=
=0A=
I disagree. The "For example" list gets very strange as examples of transpo=
rt protocols. I also agree with Michael's original objection: stressing tha=
t applications use services is important.=0A=
=0A=
=0A=
=0A=
Okay, fine by me. I don't have a strong opinion here either way.=0A=
=0A=
=0A=
OLD:=0A=
=0A=
- Identify services provided by existing IETF transport protocols=0A=
  and congestion control mechanisms. The resulting document will=0A=
  provide guidance on making a choice among available mechanisms=0A=
  and protocols to obtain a certain transport service.=0A=
=0A=
=0A=
NEW:=0A=
=0A=
- Identify transport services provided by existing IETF transport=0A=
protocols=0A=
  and congestion control mechanisms. The resulting document will=0A=
  provide guidance on making a choice among available mechanisms=0A=
  and protocols to obtain a certain transport service. As a starting=0A=
point=0A=
  for transport services, the working group can consider: message=0A=
atomicity,=0A=
  stream fragmentation, sequence preservation, head-of-line blocking=0A=
avoidance,=0A=
  sub-channels, full reliability, latency-limited reliability,=0A=
loss-sensitive=0A=
  congestion control, delay-sensitive congestion control, endpoint=0A=
address agility,=0A=
  privacy and integrity, and path-state propagation (NAT/Firewall).=0A=
=0A=
Sentence 1: "transport services provided by ..  transport protocols" doesn'=
t seem to make things clearer. I'd rather keep "services" in this sentence =
- what this means gets concrete anyway due to the list that follows in sent=
ence 3, and there the phrase "transport services" is used anyway. The list =
should be changed, as I argued above. I suggest:=0A=
=0A=
NEW:=0A=
=0A=
- Identify services provided by existing IETF transport protocols=0A=
  and congestion control mechanisms. The resulting document will=0A=
  provide guidance on making a choice among available mechanisms=0A=
  and protocols to obtain a certain transport service. As a starting point=
=0A=
  for transport services, the working group can consider: sequence=0A=
  preservation, various degrees of reliability, low delay vs. high throughp=
ut.=0A=
=0A=
I think here we=92re once again running into the difficulty of the ambiguit=
y of the word =93transport=94, especially in the IETF=85 If we have defined=
 Transport Services in terms of the transport protocol earlier in the docum=
ent, can we actually phrase this=0A=
=0A=
- Identify Transport Services provided by IETF protocols and congestion con=
trol mechanisms=0A=
=0A=
Agreed=0A=
=0A=
=0A=
OLD:=0A=
- Specify experimental mechanisms to deliver a transport service.=0A=
  This will explain how to select and engage a protocol, and how=0A=
  to discover the availability of protocols on an interface (both=0A=
  end system and path support), in order to provide a basis for=0A=
  incremental deployment.=0A=
=0A=
NEW:=0A=
- Specify experimental mechanisms to deliver a transport protocol.=0A=
  This will explain how to select and engage a protocol, and how=0A=
  to discover the availability of protocol services on an interface (both=
=0A=
=0A=
  end system and path support), in order to provide a basis for=0A=
  incremental deployment.=0A=
=0A=
=0A=
Disagree. "deliver a transport protocol" is weird. The intention was to say=
 "provide a transport service", maybe "deliver" is a bad choice of words he=
re? So I suggest:=0A=
=0A=
NEW:=0A=
- Specify experimental mechanisms to provide a transport service.=0A=
  This will explain how to select and engage a protocol, and how=0A=
  to discover the availability of protocols on an interface (both=0A=
  end system and path support), in order to provide a basis for=0A=
  incremental deployment.=0A=
=0A=
Specify experimental mechanisms to provide a given Transport Service.=0A=
This will explain how to select and engage an appropriate protocol and=0A=
how to discover which protocols are available for a given connection.=0A=
This will provide a basis for incremental deployment.=0A=
=0A=
Agreed.=0A=
=0A=
=0A=
 "The Working Group will coordinate closely with other Working Groups and=
=0A=
IRTF Research Groups."=0A=
You should list the WGs you have in mind.=0A=
=0A=
I agree that it looks odd as it stands. I'm not sure what the right approac=
h is here (simply remove? or what are these groups?) - e.g. Spencer would k=
now better than me=85=0A=
=0A=
=0A=
I think the key thing here was that we aren=92t only limiting ourselves to =
working with the IETF but are also interested in getting input from the IRT=
F. However I think we can drop this=0A=
=0A=
Agreed.=0A=
=0A=
Cheers,=0A=
Michael=0A=
=0A=
=0A=
=0A=
=0A=
_______________________________________________=0A=
Taps mailing list=0A=
Taps@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/taps=0A=
=0A=
=0A=
_______________________________________________=0A=
Taps mailing list=0A=
Taps@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/taps=0A=
=0A=
_______________________________________________=0A=
Taps mailing list=0A=
Taps@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/taps=0A=
=0A=
=0A=
_______________________________________________=0A=
Taps mailing list=0A=
Taps@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/taps=0A=
_______________________________________________=0A=
Taps mailing list=0A=
Taps@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/taps=0A=
=0A=


From nobody Sun Jun 29 15:00:04 2014
Return-Path: 
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4668B1A0049 for ; Sun, 29 Jun 2014 15:00:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.003
X-Spam-Level: 
X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 eY8rNONGI8Zi for ; Sun, 29 Jun 2014 14:59:59 -0700 (PDT)
Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id A3CD41A004D for ; Sun, 29 Jun 2014 14:59:57 -0700 (PDT)
Received: from [192.168.48.60] (business-088-079-076-034.static.arcor-ip.net [88.79.76.34]) by trammell.ch (Postfix) with ESMTPSA id 42AE11A0036; Sun, 29 Jun 2014 23:59:39 +0200 (CEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Brian Trammell 
In-Reply-To: <6985717F-D141-430B-A151-8D63D3CC61B8@ifi.uio.no>
Date: Sun, 29 Jun 2014 23:59:34 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <49BF6ED1-F699-43F2-A78F-DCCDD13685BD@trammell.ch>
References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACAFDA.3060303@gmail.com> <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> <53AD74D8.9010906@gmail.com>  <33966B16-D15B-49E5-BEBD-C8DE990F8028@ifi.uio.no> <53AD88BD.6090003@kau.se> <0305821c865245e08cc4531ff66d9c7d@AMSPR06MB439.eurprd06.prod.outlook.com> <12FABC6F-187D-479C-8A72-4D1FBC5C25FC@mjmontpetit.com>   <01441810-A702-4DC2-B74C-6C0DC6F5235B@ifi.uio.no> <53B00F25.2080500@cisco.com> <6985717F-D141-430B-A151-8D63D3CC61B8@ifi.uio.no>
To: Michael Welzl 
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/taps/S1U9NjrD4Aj5kKeynD-y-dcFnqU
Cc: Aaron Falk , Eliot Lear , "" , Marie-Jose Montpetit , Spencer Dawkins , "" , Benoit Claise , "" 
Subject: [Taps] services / dimensions / characteristics was Re: Charter bikeshed #1 - "transport service"
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Jun 2014 22:00:02 -0000

hi Michael, all,

The charter as edited looks good to me, thanks for pulling all this =
together!

That's the end of the content of this message relevant to the chartering =
discussion. What follows is a bikeshed of a different color.

To clarify (or at least, to obfuscate differently) this ("Brian's") =
list:

    - message atomicity
    - stream fragmentation
    - sequence preservation
    - head-of-line blocking avoidance
    - sub-channels
    - full reliability
    - latency-limited reliability
    - loss-sensitive congestion control
    - delay-sensitive congestion control
    - endpoint address agility
    - privacy and integrity
    - path-state propagation (NAT/FW)

was presented at the IAB/IESG retreat as a list of (examples of) =
"dimensions", not "services", and on further thought they're not =
dimensions either (since they lack orthogonality -- some may be / are =
dependent on others); rather, they're characteristics. Some might be =
things applications wan, some might be things applications must =
tolerate. The idea is that the requirements of a given "service" are =
built from a set of characteristics.

In the original list from which this was taken, the common services =
SOCK_STREAM (over TCP) and SOCK_DGRAM (over UDP) were columns, where =
these were the rows, in a table showing the relationship between =
services and characteristics. The list was presented specifically to =
make the point that the space of existing transports is smaller than the =
space of useful transports (is smaller than the space of possible =
transport protocols).

Latency/throughput tradeoffs -- though these are important =
characteristics from an application standpoint and IMO a key reason to =
fix the interfaces to transport protocols in the first place -- didn't =
make it on to *this* list as is (they're hiding behind the congestion =
control items), mainly because neither SOCK_STREAM nor SOCK_DGRAM with =
the current sockets interface have such a thing.

That said, what to call these is a hard question with a set of =
arbitrarily bad answers, so I'm in full support of an abbreviated list =
of examples in the charter for the sake of clarity, as long as it's =
equally clear that the list is not intended to be complete.

Cheers,

Brian


On 29 Jun 2014, at 15:32, Michael Welzl  wrote:

>=20
> On 29. juni 2014, at 15:05, Eliot Lear  wrote:
>=20
>> Michael,
>>=20
>> Probably a good idea to put out a clean version of what you believe =
we have converged on. There's a lot of depth to this discussion, much in =
the form of >>>>,
>>=20
>> Eliot
>=20
> Great, suggestion, thanks!  It's below.
> Note, this is only an update based on Benoit's comments - some others =
have proposed smaller changes (e.g., not starting the charter with =
"Conjointly, ..." ) and I'll leave those up to Spencer  (myself, I'm not =
even a native speaker after all).
>=20
> Cheers,
> Michael
>=20
>=20
>=20
> ADD, NEAR THE BEGINNING OF THE CHARTER:
>=20
> A Transport Service is any service provided by the transport layer =
that can only be correctly implemented with information from the =
application.
>=20
>=20
>=20
> OLD:
>=20
> Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
> UDP-Lite and the LEDBAT congestion control mechanism extend
> the set of transport services that are available to
> applications, beyond those provided by TCP and UDP. For
> example, SCTP provides potentially faster reliable delivery
> for applications that can accept blocks of data out of order,
> and LEDBAT provides low-priority "scavenger" communication.
>=20
> NEW:
> Conjointly, transport protocols such as SCTP, DCCP, MPTCP,
> UDP-Lite and the LEDBAT congestion control mechanism extend
> the set of Transport Services that are available to
> applications, beyond those provided by TCP and UDP. For
> example, SCTP provides potentially faster reliable delivery
> for applications that can accept blocks of data out of order,
> and LEDBAT provides low-priority "scavenger" communication.
>=20
>=20
>=20
> OLD:
>=20
> - Identify services provided by existing IETF transport protocols
>  and congestion control mechanisms. The resulting document will
>  provide guidance on making a choice among available mechanisms
>  and protocols to obtain a certain transport service.
>=20
>=20
> NEW:
>=20
> - Identify Transport services provided by existing IETF protocols
>  and congestion control mechanisms. The resulting document will
>  provide guidance on making a choice among available mechanisms
>  and protocols to obtain a certain transport service. As a starting =
point
>  for transport services, the working group can consider:
>  ordering/sequence preservation, degree of reliability, latency vs =
throughput.
>=20
>=20
>=20
>=20
> OLD:
>=20
> - Specify a subset of those services identified in item 1, which
>  end systems supporting TAPS need to provide and provide guidance
>  on choosing among available mechanisms and protocols to obtain
>  a given transport service.
>=20
> NEW:
> - Specify a subset of those transport services identified in item 1,
> which end systems supporting TAPS need to provide and provide guidance
>  on choosing among available mechanisms and protocols.
>=20
>=20
> OLD:
> - Specify experimental mechanisms to deliver a transport service.
>  This will explain how to select and engage a protocol, and how
>  to discover the availability of protocols on an interface (both
>  end system and path support), in order to provide a basis for
>  incremental deployment.
>=20
> NEW:
> - Specify experimental mechanisms to provide a given Transport =
Service.=20
> This will explain how to select and engage an appropriate protocol and=20=

> how to discover which protocols are available for a given connection.=20=

> This will provide a basis for incremental deployment.
>=20
>=20
> OLD:
>=20
>    There are many ways in which this problem could be addressed;
>    while it may not yet be clear what the best way forward could
>    be, any approach to provide a richer set of transport services
>    to applications will have to begin with the identification of
>    the services that current transport protocols provide.
>=20
> NEW (this paragraph would make more sense after the 3 bullet points =
"the
> Working Group will")
>=20
>    The Working Group deliverables will help an application
>    programmer identify the important transport services for his
>    application and determine if those transport services are available
>    on the end points and along the path in the network. An approach to
>    provide a richer set of transport services to applications (which
>    could be part of a future charter) has to begin with the
> identification of
>    the services that current transport protocols provide.
>=20
>=20
> OLD:
>=20
> "The Working Group will coordinate closely with other Working Groups =
and
> IRTF Research Groups."
>=20
> NEW:  Remove this sentence.
>=20
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps


From nobody Mon Jun 30 10:03:39 2014
Return-Path: 
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B361A03CB for ; Mon, 30 Jun 2014 10:03:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 KHHbaOiCnEce for ; Mon, 30 Jun 2014 10:03:20 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72D1E1A03B5 for ; Mon, 30 Jun 2014 10:03:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1380; q=dns/txt; s=iport; t=1404147799; x=1405357399; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=PeFZf4NAaObu1WPpj1I0piCadfjzMfgGhz8fSB0fKIA=; b=cIA3m2fUuYO9nGyjiG417jQyhC9ThuRyl5Sh1NR4uoklr+HR+niqxprc 5MZFJU+LWCGaxA9HPKsUbNF0XskCAO0hNesoSQBD6hmftfp9T3jSdGki9 +0VN6jry0lm7ecg94ORaBf/OlcZBexjCIoIgsW1P4qiRY77n6e9F+zkFV U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjoHAJeXsVOtJV2U/2dsb2JhbABagw2BLIJuqCwBAQEBAQEFAW4BmUYBGXUWdYQEAQEEIxFVAgEIDgwCJgICAjAVEAIEARKIQqtNnEAXgSuEOYkqgneBTAEElkeEF5N9g0KCMA
X-IronPort-AV: E=Sophos;i="5.01,576,1400025600"; d="scan'208";a="57123805"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP; 30 Jun 2014 17:03:18 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s5UH3IpV012990 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jun 2014 17:03:18 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Mon, 30 Jun 2014 12:03:18 -0500
From: "Joe Hildebrand (jhildebr)" 
To: Michael Welzl , "taps@ietf.org" 
Thread-Topic: [Taps] Stream vs. packet
Thread-Index: AQHPkhabptNYx8uCFEWciG2mTj4nr5uJ1XGA
Date: Mon, 30 Jun 2014 17:03:18 +0000
Message-ID: 
References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACAFDA.3060303@gmail.com> <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> <53AD74D8.9010906@gmail.com>  <87928669-2007-4F11-900E-1AD7030F08DD@ifi.uio.no>
In-Reply-To: <87928669-2007-4F11-900E-1AD7030F08DD@ifi.uio.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.3.140616
x-originating-ip: [10.129.24.156]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/taps/z_Ar367nsW3WiTyDjLlq4MXtv0I
Subject: Re: [Taps] Stream vs. packet
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jun 2014 17:03:26 -0000

T24gNi8yNy8xNCwgODo0NSBBTSwgIk1pY2hhZWwgV2VsemwiIDxtaWNoYXdlQGlmaS51aW8ubm8+
IHdyb3RlOg0KDQo+Q2FuIHdlIHRyeSB0byBtYWtlIGEgc2ltcGxlIGRlY2lzaW9uIGhlcmUsIGFz
IGEgZ3JvdXAsIHRvIG5ldmVyIGV2ZW4NCj5yZWFsbHkgY29uc2lkZXIgc3RyZWFtcyBhdCBhbGw/
DQo+DQo+DQo+SXQgc2VlbXMgdG8gbWUgdG8gYmUgc3RyYWlnaHRmb3J3YXJkIHRvIHByb3ZpZGUg
YSBzdHJlYW0tYmFzZWQgdHJhbnNwb3J0DQo+b3ZlciBhIG1lc3NhZ2UtYmFzZWQgdHJhbnNwb3J0
LCBzbyB0aGlzIGlzIHNvbWV0aGluZyB0aGF0IGNhbiBzaW1wbHkNCj5hbHdheXMgYmUgZG9uZS4g
VGh1cywgY2FuIHdlIGp1c3Qgd3JpdGUgYSBkaXNjbGFpbWVyIGluIG9uZSBvZiBvdXINCj5kb2N1
bWVudHMsIHJlY29tbWVuZGluZyB0aGF0IGFueSBUQVBTLXN1cHBvcnRpbmcNCj4gc3lzdGVtcyBj
YW4gcHJvdmlkZSBzdHJlYW0tYmFzZWQgdHJhbnNwb3J0IG9uIHRvcCBvZiB0aGUgbWVzc2FnZSBi
YXNlZA0KPnRyYW5zcG9ydCB0b28sIGJ1dCB0aGF0IGl0cyB1c2VycyBtdXN0IGJlIGF3YXJlIG9m
IGxpbWl0YXRpb25zIHRoYXQgYXJpc2UNCj5mcm9tIHN0cmVhbXMgKHN1Y2ggYXMgSE9MIGJsb2Nr
aW5nIGRlbGF5LCBubyBBTEYsIC4uKT8NCg0KTWF5YmUsIGlmIHdlIGFsc28gaGF2ZToNCg0KLSBy
ZXRyYW5zbWlzc2lvbg0KLSBvcmRlciBwcmVzZXJ2YXRpb24NCi0gb3B0aW9uYWwgbmFnbGUtaXNo
IGdyb3VwaW5nDQotIG9wdGlvbmFsIEZFQw0KLSB3aGF0ZXZlciBlbHNlIEknbSBtaXNzaW5nDQoN
CkF0IHdoaWNoIHBvaW50IGl0IG1pZ2h0IGJlIHN0cmFpZ2h0Zm9yd2FyZCB0byBidWlsZCBhIHN0
cmVhbSwgYnV0IHdlIHN0aWxsDQptaWdodCB3YW50IHRvIHN1Z2dlc3QgaG93IHRvIGNvbWJpbmUg
dGhlIGNoYXJhY3RlcmlzdGljcyB0b2dldGhlciBpbnRvIGENCmxhcmdlciBiaXQgb2YgZnVuY3Rp
b25hbGl0eS4NCg0KLS0gDQpKb2UgSGlsZGVicmFuZA0KDQoNCg0K


From nobody Mon Jun 30 10:16:44 2014
Return-Path: 
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF69A1A03A5 for ; Mon, 30 Jun 2014 10:16:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 ZCUl0NoUwktp for ; Mon, 30 Jun 2014 10:16:40 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DFA71A011B for ; Mon, 30 Jun 2014 10:16:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3064; q=dns/txt; s=iport; t=1404148600; x=1405358200; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=MPnpUKO203KpahAGXtyQKIbYO6DcaQbIkw7NL/15Anw=; b=QuX61D9oL06ScLC32+yvSWYm7n/0JeOS4ed2YI6yKi86K1BI7eOsguKZ JItWEpABZbSUSAEOggEATSN+Sl6wfYpKmOVDQ3NkadWlvpKmvgvRdH0jh aeBisiZnocSHRLGbEqf0cbDS6dhrHLr2dm8b5RS1DhD/UaQjWVVMBX8uL 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjYHACmbsVOtJV2Q/2dsb2JhbABagw2BLIJuqCwBAQEBAQEFAW4BmWB3FnWEAwEBAQQjEVcBIAICJgIEHxEVEgQTiC4DEZxHjyOVYA2GUheBK4Q5hnyFJYFMBZZHghmBfotPghyGEoNCgjA
X-IronPort-AV: E=Sophos;i="5.01,576,1400025600"; d="scan'208";a="336760881"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP; 30 Jun 2014 17:16:32 +0000
Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s5UHGWUc030402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 30 Jun 2014 17:16:32 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 30 Jun 2014 12:16:32 -0500
From: "Joe Hildebrand (jhildebr)" 
To: "taps@ietf.org" 
Thread-Topic: Hiding information from applications
Thread-Index: AQHPlIcJ1uyOhqAx5kqlBX4Y3Sjz/w==
Date: Mon, 30 Jun 2014 17:16:31 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.3.140616
x-originating-ip: [10.129.24.156]
Content-Type: text/plain; charset="utf-8"
Content-ID: <7DEC270AF5E08C46A904F8D88CCD980D@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/taps/-OzoaQ1WS5bhotNwSWL65mxqJeA
Subject: [Taps] Hiding information from applications
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jun 2014 17:16:41 -0000

Q29udGludWluZyBhIHRocmVhZCBvbiB0aGUgYWN0dWFsIHdvcmsgaW5zdGVhZCBvZiBvbiB0aGUg
Y2hhcnRlciwgc28gbmV3DQpzdWJqZWN0Lg0KDQoNCk9uIDYvMjcvMTQsIDg6MDQgQU0sICJNaWNo
YWVsIFdlbHpsIiA8bWljaGF3ZUBpZmkudWlvLm5vPiB3cm90ZToNCg0KPk9uIDI3LiBqdW5pIDIw
MTQsIGF0IDE1OjQyLCBTcGVuY2VyIERhd2tpbnMNCj48c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFp
bC5jb20+IHdyb3RlOg0KPg0KPj4gT24gb25lIHBvaW50ICh0aGF0IE1pY2hhZWwgc2FpZCBoZSB3
YXMgY29uZnVzZWQgYWJvdXQgYmVsb3csIHNvIG1heWJlDQo+PndvcnRoIGV4cGxhaW5pbmcgYmV0
dGVyKSwgQmVub2l0IGFuZCBJIHNwZW50IGFib3V0IDIwIG1pbnV0ZXMgdGFsa2luZw0KPj5iZWZv
cmUgaGUgYmFsbG90ZWQgaGlzIGJsb2NrLCBhbmQgb25lIHRoaW5nIHdlIHRhbGtlZCBhYm91dCB3
YXMgdGhlDQo+PmRpZmZlcmVuY2UgYmV0d2VlbiBhbiBhcHBsaWNhdGlvbiBrbm93aW5nIHdoYXQn
cyBhdmFpbGFibGUgb24gYSBwbGF0Zm9ybQ0KPj5hbmQga25vd2luZyB3aGF0J3MgYXZhaWxhYmxl
IG9uIHRoZSBwYXRoIGJldHdlZW4gdHdvIGVuZHBvaW50cyAoc28sIGlmIEkNCj4+Y2FuIHNlbmQg
VURQIHRvIGFueSBwb3J0IHRvIEJlbm9pdCwgYnV0IGEgZmlyZXdhbGwgYmV0d2VlbiBtZSBhbmQN
Cj4+TWljaGFlbCBkcm9wcyBhbGwgVURQIGV4Y2VwdCBmb3IgcG9ydCA1MywgYm90aCBvZiB0aG9z
ZSBmYWN0cyBhcmUNCj4+cmVsZXZhbnQpLg0KPj4gDQo+PiBUaGlzIGlzIHdoYXQgd2UgbWVhbnQg
d2hlbiBCZW5vaXQgc2FpZCAid2hpY2ggdHJhbnNwb3J0IGJ1aWxkaW5nIGJsb2Nrcw0KPj53b3Jr
IGZvciBtZSIgYmVsb3cuDQo+DQo+V2VsbCwgaW5kZWVkLCB0aGlzIGlzIGEgZGVzaWduIHRyYWRl
LW9mZiBoZXJlIHRoYXQgdGhlIGdyb3VwIG11c3QgZmlndXJlDQo+b3V0LiBUd28gZXhhbXBsZSBj
YXNlcyBoZXJlOg0KPg0KPjEpIE15IG93biBwcmVmZXJlbmNlOiBUQVBTIGhpZGVzIHByZXR0eSBt
dWNoIGV2ZXJ5dGhpbmcgdGhhdCdzDQo+cGF0aC1yZWxhdGVkIGZyb20gdGhlIGFwcGxpY2F0aW9u
LCBhbmQgd2Ugc2F5ICJpZiB5b3UgZG8gY2FyZSBhYm91dCBzdWNoDQo+ZGV0YWlscywgZG9uJ3Qg
dXNlIFRBUFMsIHVzZSB0aGUgcHJvdG9jb2wgeW91IHdpc2guIg0KPg0KPjIpIE1heWJlIHNvbWVv
bmUgZWxzZSdzLCBtYXliZSBCZW5vaXQncywgcHJlZmVyZW5jZTogVEFQUyBkb2VzIG5vdCBoaWRl
DQo+cGF0aC1yZWxhdGVkIGluZm9ybWF0aW9uIGZyb20gdGhlIGFwcGxpY2F0aW9uLg0KDQpUaGlz
IGlzIGxpa2VseSB0byBiZSBhbiBhcmVhIG9mIGxpdmVseSBkaXNjdXNzaW9uIGVhcmx5IGluIHRo
ZSBwcm9jZXNzLiAgSQ0KYWxtb3N0IGNvbXBsZXRlbHkgZGlzYWdyZWUgd2l0aCBoaWRpbmcgYW55
dGhpbmcgZnJvbSB0aGUgYXBwbGljYXRpb246DQoNCi0gVGhlIGFwcGxpY2F0aW9uIG5lZWRzIHRv
IGtub3cgd2hhdCBzZW1hbnRpY3MgaXQgZ290IGluIG9yZGVyIHRvIGRvDQoqYW55dGhpbmcqDQoN
Ci0gVGhlIGFwcGxpY2F0aW9uIGlzIGxpa2VseSBnb2luZyB0byBiZSB0aGUgdGhpbmcgaW1wbGVt
ZW50aW5nIHRoZQ0KcHJvdG9jb2wgYW55d2F5LCBzaW5jZSBJJ20gbmV2ZXIgZ29pbmcgdG8gZ2V0
IGVub3VnaCBPU2VzIHRvIGdpdmUgbWUgYSBuZXcNCmtlcm5lbCBpbnRlcmZhY2UgKGV2aWRlbmNl
OiBTQ1RQKQ0KDQotIFRoZSBzZW1hbnRpY3MgdGhhdCB0aGUgYXBwbGljYXRpb24gcmVxdWlyZXMg
aW4gb3JkZXIgdG8gZnVuY3Rpb24gYXJlDQptb3N0bHkga25vd24gYXQgcHJvdG9jb2wgZGVzaWdu
IHRpbWUNCg0KLSBIYXZpbmcgdG8gcnVuIGEgcmVzcG9uZGVyIChlLmcuIHNlcnZlcikgdGhhdCBp
bXBsZW1lbnRzIGFsbCBwb3NzaWJsZQ0KY29tYmluYXRpb25zIGlzIHByb2hpYml0aXZlbHkgZXhw
ZW5zaXZlIGluIHNldmVyYWwgZGltZW5zaW9ucy4gIEluDQpwcmFjdGljZSwgaXQncyBnb2luZyB0
byBiZSBqdXN0IGEgZmV3IHRoYXQgYXJlIChhZ2Fpbikga25vd24gYXQgcHJvdG9jb2wNCmRlc2ln
biB0aW1lDQoNCi0gVGhlIGFwcGxpY2F0aW9uIG1heSB3YW50IHRvIGJlIGFibGUgdG8gZW50ZXIg
aW50byBhIGRpc2N1c3Npb24gd2l0aCBvbmUNCm9yIG1vcmUgb2YgdGhlIGRldmljZXMgb24gcGF0
aCBpbiBvcmRlciB0byBuZWdvdGlhdGUgYmV0dGVyIHNlcnZpY2UNCg0KDQotLSANCkpvZSBIaWxk
ZWJyYW5kDQoNCg0KDQo=


From nobody Mon Jun 30 14:53:15 2014
Return-Path: 
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B801A0AF9 for ; Mon, 30 Jun 2014 14:53:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 LqdkvHodEJF1 for ; Mon, 30 Jun 2014 14:53:12 -0700 (PDT)
Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5B021A0AF4 for ; Mon, 30 Jun 2014 14:53:11 -0700 (PDT)
Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1X1jVd-0004BM-O9; Mon, 30 Jun 2014 23:53:09 +0200
Received: from 089144207189.atnat0016.highway.bob.at ([89.144.207.189] helo=[192.168.0.100]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1X1jVc-00077u-Mb; Mon, 30 Jun 2014 23:53:09 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Michael Welzl 
In-Reply-To: 
Date: Mon, 30 Jun 2014 23:53:01 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9DBC6468-F19B-444F-94A7-77E922FB2160@ifi.uio.no>
References: <20140625131549.16673.42918.idtracker@ietfa.amsl.com> <53ACAFDA.3060303@gmail.com> <139A8288-652E-46D3-88E4-F3D198BB9BDE@ifi.uio.no> <53AD74D8.9010906@gmail.com>  <87928669-2007-4F11-900E-1AD7030F08DD@ifi.uio.no> 
To: "Joe Hildebrand (jhildebr)" 
X-Mailer: Apple Mail (2.1878.2)
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 4 sum msgs/h 2 total rcpts 18024 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 5C1E7D6EF8F5747948095DA8CA2889B97447C093
X-UiO-SPAM-Test: remote_host: 89.144.207.189 spam_score: -49 maxlevel 80 minaction 2 bait 0 blacklist 0 greylist 0 ratelimit 0
Archived-At: http://mailarchive.ietf.org/arch/msg/taps/pEfqByPJfzJcqRyLqb6ldC4U2wQ
Cc: "taps@ietf.org" 
Subject: Re: [Taps] Stream vs. packet
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jun 2014 21:53:14 -0000

On 30. juni 2014, at 19:03, Joe Hildebrand (jhildebr) =
 wrote:

> On 6/27/14, 8:45 AM, "Michael Welzl"  wrote:
>=20
>> Can we try to make a simple decision here, as a group, to never even
>> really consider streams at all?
>>=20
>>=20
>> It seems to me to be straightforward to provide a stream-based =
transport
>> over a message-based transport, so this is something that can simply
>> always be done. Thus, can we just write a disclaimer in one of our
>> documents, recommending that any TAPS-supporting
>> systems can provide stream-based transport on top of the message =
based
>> transport too, but that its users must be aware of limitations that =
arise
>> from streams (such as HOL blocking delay, no ALF, ..)?
>=20
> Maybe, if we also have:
>=20
> - retransmission
> - order preservation
> - optional nagle-ish grouping
> - optional FEC
> - whatever else I'm missing
>=20
> At which point it might be straightforward to build a stream, but we =
still
> might want to suggest how to combine the characteristics together into =
a
> larger bit of functionality.

Sure; you can do all these things with messages, but it's harder or in =
some cases impossible with streams. You can turn much into a stream but =
not vice versa. Case in point: Minion - by merely introducing a marker =
in the byte stream that separates messages, all kinds of good things =
become possible.

Cheers,
Michael


From nobody Mon Jun 30 15:00:56 2014
Return-Path: 
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5551A0AF9 for ; Mon, 30 Jun 2014 15:00:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level: 
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
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 LWeYXaPXSkX7 for ; Mon, 30 Jun 2014 15:00:53 -0700 (PDT)
Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 958801A002E for ; Mon, 30 Jun 2014 15:00:52 -0700 (PDT)
Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1X1jd4-0005Ud-Ka; Tue, 01 Jul 2014 00:00:50 +0200
Received: from 089144207189.atnat0016.highway.bob.at ([89.144.207.189] helo=[192.168.0.100]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1X1jd3-0000oq-J2; Tue, 01 Jul 2014 00:00:50 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Michael Welzl 
In-Reply-To: 
Date: Tue, 1 Jul 2014 00:00:40 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <470E57AA-1AAA-4144-9D3D-6EF77EDABD54@ifi.uio.no>
References: 
To: "Joe Hildebrand (jhildebr)" 
X-Mailer: Apple Mail (2.1878.2)
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 4 sum msgs/h 1 total rcpts 18026 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 9947BF807CF805649880713A0E23003F1E6FCE3E
X-UiO-SPAM-Test: remote_host: 89.144.207.189 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1 max/h 1 blacklist 0 greylist 0 ratelimit 0
Archived-At: http://mailarchive.ietf.org/arch/msg/taps/aEyoj0M-2rUT_CUfSWLfkRkUFTk
Cc: "taps@ietf.org" 
Subject: Re: [Taps] Hiding information from applications
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Jun 2014 22:00:54 -0000

On 30. juni 2014, at 19:16, Joe Hildebrand (jhildebr) =
 wrote:

> Continuing a thread on the actual work instead of on the charter, so =
new
> subject.

and a very interesting discussion indeed! The crux of the matter  :-)


> On 6/27/14, 8:04 AM, "Michael Welzl"  wrote:
>=20
>> On 27. juni 2014, at 15:42, Spencer Dawkins
>>  wrote:
>>=20
>>> On one point (that Michael said he was confused about below, so =
maybe
>>> worth explaining better), Benoit and I spent about 20 minutes =
talking
>>> before he balloted his block, and one thing we talked about was the
>>> difference between an application knowing what's available on a =
platform
>>> and knowing what's available on the path between two endpoints (so, =
if I
>>> can send UDP to any port to Benoit, but a firewall between me and
>>> Michael drops all UDP except for port 53, both of those facts are
>>> relevant).
>>>=20
>>> This is what we meant when Benoit said "which transport building =
blocks
>>> work for me" below.
>>=20
>> Well, indeed, this is a design trade-off here that the group must =
figure
>> out. Two example cases here:
>>=20
>> 1) My own preference: TAPS hides pretty much everything that's
>> path-related from the application, and we say "if you do care about =
such
>> details, don't use TAPS, use the protocol you wish."
>>=20
>> 2) Maybe someone else's, maybe Benoit's, preference: TAPS does not =
hide
>> path-related information from the application.
>=20
> This is likely to be an area of lively discussion early in the =
process.  I
> almost completely disagree with hiding anything from the application:
>=20
> - The application needs to know what semantics it got in order to do
> *anything*

... which is why I should never have used the word "hiding". Very sorry =
for that. Provide information, yes, but relieve application programmers =
from having to worry about these things and give some control to =
whatever they use. Not every application programmer wants to care about =
each and every detail of what goes on along a path, all the time - I'm =
getting the impression that the view of "application programmers" or =
"apps" people is biased in the IETF, towards... well, the kinds of app =
programmers who attend the IETF  :-)


> - The application is likely going to be the thing implementing the
> protocol anyway, since I'm never going to get enough OSes to give me a =
new
> kernel interface (evidence: SCTP)

What's your "application"? You could have a middleware providing TAPS in =
user space.


> - The semantics that the application requires in order to function are
> mostly known at protocol design time

I agree, but we're discussing whether the application needs to be =
concerned with *path-specific* information.


> - Having to run a responder (e.g. server) that implements all possible
> combinations is prohibitively expensive in several dimensions.  In
> practice, it's going to be just a few that are (again) known at =
protocol
> design time

Okaaay... so...?


> - The application may want to be able to enter into a discussion with =
one
> or more of the devices on path in order to negotiate better service

May want to =3D> then it shall!  :-)

The question is really, what kinds of users are we building this for, =
and where do we draw the line re: flexibility vs. application control?

Cheers,
Michael


From nobody Mon Jun 30 17:00:14 2014
Return-Path: 
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7015F1A03F5 for ; Mon, 30 Jun 2014 17:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level: 
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 CVYwbiJUn4mQ for ; Mon, 30 Jun 2014 17:00:10 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 170DA1A002E for ; Mon, 30 Jun 2014 17:00:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6680; q=dns/txt; s=iport; t=1404172810; x=1405382410; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dLwC2c/1Bctmx0K906yuAUFxKNiIOY8aIVDet9WHaq4=; b=nJDGe1x54JTUee1NuwaEkOCKrvjUCOFHkW+u0aI0O2Qadm8+yLV4oIrc fZIbnEB4korY4fMMA+5h5Tlp9XaEmDnj1jLnbPUkbcWRoobj4skRMveyb qjHN7aFEAOleI2r5iIZdG/5UUsBusYsDsvHJSBZTYWcXUwJlnDWmjObBn s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Au0FAO34sVOtJA2E/2dsb2JhbABagw1SWoJuqDABAQEBAQEFAW6ZSwEZdxZ1hAQBAQQjETkMEAIBCA4MAiYCAgIwFRACBA4FG4gnq2mcOBeBK4Q5iEALChszB4J3gUwFlkeEF4FGigmILoNCgW5C
X-IronPort-AV: E=Sophos;i="5.01,578,1400025600"; d="scan'208";a="336921931"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-4.cisco.com with ESMTP; 01 Jul 2014 00:00:10 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s61009Bv026620 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 1 Jul 2014 00:00:09 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Mon, 30 Jun 2014 19:00:09 -0500
From: "Joe Hildebrand (jhildebr)" 
To: Michael Welzl 
Thread-Topic: [Taps] Hiding information from applications
Thread-Index: AQHPlIcJ1uyOhqAx5kqlBX4Y3Sjz/5uKiDkA//+8zAA=
Date: Tue, 1 Jul 2014 00:00:08 +0000
Message-ID: 
References:  <470E57AA-1AAA-4144-9D3D-6EF77EDABD54@ifi.uio.no>
In-Reply-To: <470E57AA-1AAA-4144-9D3D-6EF77EDABD54@ifi.uio.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.3.140616
x-originating-ip: [10.129.24.156]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/taps/5geh6DPNmXFdVq7CAGDiIMnesww
Cc: "taps@ietf.org" 
Subject: Re: [Taps] Hiding information from applications
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Jul 2014 00:00:12 -0000

T24gNi8zMC8xNCwgNDowMCBQTSwgIk1pY2hhZWwgV2VsemwiIDxtaWNoYXdlQGlmaS51aW8ubm8+
IHdyb3RlOg0KDQo+Li4uIHdoaWNoIGlzIHdoeSBJIHNob3VsZCBuZXZlciBoYXZlIHVzZWQgdGhl
IHdvcmQgImhpZGluZyIuIFZlcnkgc29ycnkNCj5mb3IgdGhhdC4gUHJvdmlkZSBpbmZvcm1hdGlv
biwgeWVzLCBidXQgcmVsaWV2ZSBhcHBsaWNhdGlvbiBwcm9ncmFtbWVycw0KPmZyb20gaGF2aW5n
IHRvIHdvcnJ5IGFib3V0IHRoZXNlIHRoaW5ncyBhbmQgZ2l2ZSBzb21lIGNvbnRyb2wgdG8gd2hh
dGV2ZXINCj50aGV5IHVzZS4gTm90IGV2ZXJ5IGFwcGxpY2F0aW9uIHByb2dyYW1tZXIgd2FudHMg
dG8gY2FyZSBhYm91dCBlYWNoIGFuZA0KPmV2ZXJ5IGRldGFpbCBvZiB3aGF0IGdvZXMgb24gYWxv
bmcgYSBwYXRoLCBhbGwgdGhlIHRpbWUgLSBJJ20gZ2V0dGluZyB0aGUNCj5pbXByZXNzaW9uIHRo
YXQgdGhlIHZpZXcgb2YgImFwcGxpY2F0aW9uIHByb2dyYW1tZXJzIiBvciAiYXBwcyIgcGVvcGxl
IGlzDQo+Ymlhc2VkIGluIHRoZSBJRVRGLCB0b3dhcmRzLi4uIHdlbGwsIHRoZSBraW5kcyBvZiBh
cHAgcHJvZ3JhbW1lcnMgd2hvDQo+YXR0ZW5kIHRoZSBJRVRGICA6LSkNCg0KUGVyaGFwcywgeWVz
LiAgSW4gbXkgbWluZCwgdGhlIHRhcmdldCBhdWRpZW5jZSBvZiBzb21lIG9mIHRoZXNlIGJpdHMg
YXJlDQpsaWJyYXJ5IGRldmVsb3BlcnMuICBUaGVzZSBmb2xrcyBjYW4gZXhwb3NlIGxvdHMgb2Yg
ZXZlbnRzIHRvIGhpZ2hlci1sZXZlbA0KcHJvZ3JhbW1lcnMsIG1vc3Qgb2Ygd2hpY2ggbWlnaHQg
YmUgaWdub3JlZCB0byBzdGFydC4gIEFzIGFuIGFwcGxpY2F0aW9uDQpnZXRzIG1vcmUgaW50ZXJl
c3RlZCBpbiBudWFuY2VkIHVzZXIgZXhwZXJpZW5jZSwgdGhlIGxpYnJhcnktdXNpbmcNCmRldmVs
b3BlciBjYW4gcGF5IGF0dGVudGlvbiB0byBtb3JlIGRldGFpbC4NCg0KPj4gLSBUaGUgYXBwbGlj
YXRpb24gaXMgbGlrZWx5IGdvaW5nIHRvIGJlIHRoZSB0aGluZyBpbXBsZW1lbnRpbmcgdGhlDQo+
PiBwcm90b2NvbCBhbnl3YXksIHNpbmNlIEknbSBuZXZlciBnb2luZyB0byBnZXQgZW5vdWdoIE9T
ZXMgdG8gZ2l2ZSBtZSBhDQo+Pm5ldw0KPj4ga2VybmVsIGludGVyZmFjZSAoZXZpZGVuY2U6IFND
VFApDQo+DQo+V2hhdCdzIHlvdXIgImFwcGxpY2F0aW9uIj8NCg0KSW4gZ2VuZXJhbCwgdGhlIGFw
cGxpY2F0aW9ucyBJIHRlbmQgdG8gdGhpbmsgYWJvdXQgaGF2ZSB0aGVzZSBwcm9wZXJ0aWVzOg0K
DQotIFlvdSBkb3dubG9hZCBpdCBmcm9tIHNvbWV3aGVyZSAoZS5nLiBJbnRlcm5ldCwgYXBwIHN0
b3JlLCBvciBjb3Jwb3JhdGUNCnJlcG9zaXRvcnkpDQotIFlvdSBpbnN0YWxsIGl0IHlvdXJzZWxm
IGluIGEgZGlyZWN0b3J5IG9mIHlvdXIgKG9yIHlvdXIgYWRtaW4ncywgb3IgeW91cg0KT1Mncykg
Y2hvb3NpbmcNCi0gSXQgcnVucyB3aXRoIHlvdXIgdXNlciBwcml2aWxlZ2VzLCBub3RoaW5nIG1v
cmUNCiAgLSBObyByYXcgc29ja2V0cw0KICAtIE5vIGxvdy1udW1iZXJlZCBwb3J0cw0KICAtIE5v
IGFjY2VzcyB0byBESENQIGluZm9ybWF0aW9uDQotIEl0IGlzIHJ1bm5pbmcgb24gb25lIG9yIG1v
cmUgb2YgbWFueSBvcGVyYXRpbmcgc3lzdGVtcw0KLSBJdCBpcyB3cml0dGVuIGluIG9uZSBvciBt
b3JlIG9mIG1hbnkgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzDQotIEl0IHNwZWFrcyBvbmx5IHRocm91
Z2ggdGhlIHNvY2tldCBBUEkgdG8gdGhlIGtlcm5lbCwgb3IgYSB3cmFwcGVyIGFyb3VuZA0KdGhh
dCBBUEkNCi0gSXQgaGFzIGFjY2VzcyB0byBtdWx0aXBsZSBhY3RpdmUgbmV0d29yayBpbnRlcmZh
Y2VzLCB3aXRoIHNvbWUgbGltaXRlZA0KYWJpbGl0eSB0byBlbnVtZXJhdGUgdGhvc2UgZGV2aWNl
cyBhbmQgZXZlbiBsZXNzIGFiaWxpdHkgdG8gcXVlcnkgdGhlDQpwcm9wZXJ0aWVzIG9mIHRob3Nl
IGludGVyZmFjZXMNCi0gSXRzIElQIGFkZHJlc3NlcyBjaGFuZ2UgYXQgbGVhc3QgbXVsdGlwbGUg
dGltZXMgcGVyIGRheSwgc29tZXRpbWVzDQptdWx0aXBsZSB0aW1lcyBwZXIgbWludXRlDQotIEl0
IGlzIGJlaGluZCBhIGNvcnBvcmF0ZSBmaXJld2FsbC9OQVQgd2l0aCBhbiBhZ2dyZXNzaXZlIGFk
bWluIG9yIGl0J3MNCmJlaGluZCBhIGNyYXBweSBjb25zdW1lciBmaXJld2FsbC9OQVQNCi0gSXQg
aGFzIGEgY3JhcHB5IEROUyBsaWJyYXJ5IHVudGlsIHRoZSBkZXZlbG9wZXIgZmluZHMNCmh0dHA6
Ly9nZXRkbnNhcGkubmV0Lw0KLSBJdCBtaWdodCBoYXZlIG9uZSBvciBtb3JlIElQQyBtZWNoYW5p
c21zLCBidXQgaXQgbWlnaHQgbm90IQ0KLSBJdCBtaWdodCBoYXZlIGZpbGVzeXN0ZW0gYWNjZXNz
DQotIEl0IG1pZ2h0IG5vdCBzdGF5IGNvbm5lY3RlZCB3aGVuIGl0IGdvZXMgaW50byB0aGUgYmFj
a2dyb3VuZA0KLSBJdCBtaWdodCBoYXZlIHRocmVhZHMNCi0gTGF0ZW5jeSBtYXR0ZXJzDQotIFNl
Y3VyaXR5IG1hdHRlcnMNCg0KLSBQb3dlciB1c2FnZSBtYXR0ZXJzDQotIFRoZSBhcHAgZGV2ZWxv
cGVyIGNhcmVzIG1vcmUgYWJvdXQgdXNlciBleHBlcmllbmNlIHRoYW4gcnVudGltZSBjb3N0DQot
IFRoZSBhcHAgZGV2ZWxvcGVyIGhhcyBzb21lIHNlcnZlci1zaWRlIHRlYW0gdGhleSBoYXZlIHRv
IHRhbGsgdG8sIHdobw0KdGhpbmtzIHRoZSBhcHAgZGV2ZWxvcGVyIGlzIGEgKHBlcmhhcHMpIG5l
Y2Vzc2FyeSBldmlsDQotIFRoZSBzZXJ2ZXIgZGV2ZWxvcGVycyBjYXJlIG1vcmUgYWJvdXQgY29z
dCBwZXIgdXNlciB0aGFuIHVzZXIgZXhwZXJpZW5jZQ0KLSBUaGUgYXBwIGRldmVsb3BlcnMgYW5k
IHNlcnZlciBkZXZlbG9wZXJzIGFyZSB1bml0ZWQgaW4gdGhlaXIgZGlzbGlrZSBvZg0KdGhlIGNv
cnBvcmF0ZSBmaXJld2FsbCBhZG1pbnMsIGFuZCB3aWxsIGNvbGx1ZGUgdG8gd29yayBhcm91bmQg
dGhlbSBpbg0Kb3JkZXIgdG8gZ2V0IHBhaWQuDQoNClRoZXJlIGFyZSBsaWtlbHkgb3RoZXIgcHJv
cGVydGllcyBJIGRpZG4ndCBtZW50aW9uIHRoYXQgYXJlIGludGVyZXN0aW5nLg0KU29tZSBvZiB0
aGVzZSBhcmUgbGlrZWx5IG5vdCBpbnRlcmVzdGluZyB0byBldmVyeW9uZSwgb3IgbWlnaHQgbm90
IGltcGFjdA0KdGhlIHNvbHV0aW9uIHNwYWNlLiAgSG93ZXZlciwgSSBmaWd1cmVkIEknZCBtYWtl
IGEgc3RhcnQuDQoNCj5Zb3UgY291bGQgaGF2ZSBhIG1pZGRsZXdhcmUgcHJvdmlkaW5nIFRBUFMg
aW4gdXNlciBzcGFjZS4NCg0KTWF5YmUuICBBcyBsb25nIGFzIEkgZGlkbid0IG5lZWQgdG8gYmUg
cm9vdCB0byBpbnN0YWxsIGl0IG9yIHJ1biBpdCBhbmQNCkknbSBydW5uaW5nIG9uIGFuIE9TIHdp
dGggYW4gZWZmZWN0aXZlIElQQyBtZWNoYW5pc20gdGhhdCBkaWRuJ3Qgb3BlbiB1cA0Kc2VjdXJp
dHkgaG9sZXMuDQoNCj4+IC0gVGhlIHNlbWFudGljcyB0aGF0IHRoZSBhcHBsaWNhdGlvbiByZXF1
aXJlcyBpbiBvcmRlciB0byBmdW5jdGlvbiBhcmUNCj4+IG1vc3RseSBrbm93biBhdCBwcm90b2Nv
bCBkZXNpZ24gdGltZQ0KPg0KPkkgYWdyZWUsIGJ1dCB3ZSdyZSBkaXNjdXNzaW5nIHdoZXRoZXIg
dGhlIGFwcGxpY2F0aW9uIG5lZWRzIHRvIGJlDQo+Y29uY2VybmVkIHdpdGggKnBhdGgtc3BlY2lm
aWMqIGluZm9ybWF0aW9uLg0KDQpJIHRoaW5rIHRoaXMgaXMgdGhlIGNydXggb2YgdGhlIGRpZmZl
cmVuY2UgaW4gYXBwcm9hY2hlcyB3ZSdyZSBkaXNjdXNzaW5nLg0KIElmIHRoZSBzZW1hbnRpYyBj
aGFuZ2VzIHdpdGggdGhlIHBhdGgsIEkgdGhpbmsgaXQncyBoYXJkIHRvIHdyaXRlIGFuDQphcHBs
aWNhdGlvbiB0aGF0IGNvbnRpbnVlcyB0byB3b3JrLg0KDQo+PiAtIEhhdmluZyB0byBydW4gYSBy
ZXNwb25kZXIgKGUuZy4gc2VydmVyKSB0aGF0IGltcGxlbWVudHMgYWxsIHBvc3NpYmxlDQo+PiBj
b21iaW5hdGlvbnMgaXMgcHJvaGliaXRpdmVseSBleHBlbnNpdmUgaW4gc2V2ZXJhbCBkaW1lbnNp
b25zLiAgSW4NCj4+IHByYWN0aWNlLCBpdCdzIGdvaW5nIHRvIGJlIGp1c3QgYSBmZXcgdGhhdCBh
cmUgKGFnYWluKSBrbm93biBhdCBwcm90b2NvbA0KPj4gZGVzaWduIHRpbWUNCj4NCj5Pa2FhYXku
Li4gc28uLi4/DQoNClNvIGhhdmluZyBhIGhlYXZ5d2VpZ2h0IG1lY2hhbmlzbSB0byB0cnkgMjAw
MCBvcHRpb25zIHdoZW4gb25seSAyIHdpbGwNCndvcmsgZG9lc24ndCBzZWVtIGxpa2Ugc29tZXRo
aW5nIEkgd291bGQgaW1wbGVtZW50LiAgQnV0IGl0J3MgcG9zc2libGUNCnRoZXJlJ3MgYSB3YXkg
Zm9yd2FyZCBJIGhhdmVuJ3Qgc2VlbiB5ZXQsIGFuZCBJIGxvb2sgZm9yd2FyZCB0byBoZWFyaW5n
DQptb3JlLg0KDQo+PiAtIFRoZSBhcHBsaWNhdGlvbiBtYXkgd2FudCB0byBiZSBhYmxlIHRvIGVu
dGVyIGludG8gYSBkaXNjdXNzaW9uIHdpdGgNCj4+b25lDQo+PiBvciBtb3JlIG9mIHRoZSBkZXZp
Y2VzIG9uIHBhdGggaW4gb3JkZXIgdG8gbmVnb3RpYXRlIGJldHRlciBzZXJ2aWNlDQo+DQo+TWF5
IHdhbnQgdG8gPT4gdGhlbiBpdCBzaGFsbCEgIDotKQ0KDQpJZiBpdCBoYXMgYSBtZWNoYW5pc20g
dG8gZG8gc28gdGhhdCBpcyBlYXN5IHRvIHVzZSwgc3RhbmRhcmRpemVkLCBhbmQNCmFjY2Vzc2li
bGUgZnJvbSB1c2VyIHNwYWNlLg0KDQo+VGhlIHF1ZXN0aW9uIGlzIHJlYWxseSwgd2hhdCBraW5k
cyBvZiB1c2VycyBhcmUgd2UgYnVpbGRpbmcgdGhpcyBmb3IsIGFuZA0KPndoZXJlIGRvIHdlIGRy
YXcgdGhlIGxpbmUgcmU6IGZsZXhpYmlsaXR5IHZzLiBhcHBsaWNhdGlvbiBjb250cm9sPw0KDQpZ
ZXMsIEkgdGhpbmsgdGhhdCdzIGV4YWN0bHkgdGhlIHF1ZXN0aW9uIHdlIG5lZWQgdG8gZXhwbG9y
ZSwgYW5kIEknbQ0KbG9va2luZyBmb3J3YXJkIHRvIGxlYXJuaW5nIGEgbG90IGluIHRoZSBwcm9j
ZXNzLg0KDQotLSANCkpvZSBIaWxkZWJyYW5kDQoNCg0KDQo=