From nobody Tue Nov 8 08:54:23 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902B81293D6 for ; Tue, 8 Nov 2016 08:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9rrbygfB4NT for ; Tue, 8 Nov 2016 08:54:19 -0800 (PST) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F11F6129420 for ; Tue, 8 Nov 2016 08:54:18 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1c49f6-0008u5-Ha for taps@ietf.org; Tue, 08 Nov 2016 17:54:16 +0100 Received: from [51.175.221.75] (helo=[10.0.1.14]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user steing (Exim 4.80) (envelope-from ) id 1c49f4-0005ZT-OQ; Tue, 08 Nov 2016 17:54:16 +0100 From: Stein Gjessing Content-Type: multipart/alternative; boundary="Apple-Mail=_9820BDEB-2B55-4A12-8432-42CB83F3DF38" Message-Id: <7ECA5C21-7D8A-4707-9D13-33D661EA6734@ifi.uio.no> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Tue, 8 Nov 2016 17:54:19 +0100 References: <147792488348.32368.2150582362057155074.idtracker@ietfa.amsl.com> To: taps@ietf.org X-Mailer: Apple Mail (2.3124) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 2 sum msgs/h 1 total rcpts 22272 max rcpts/h 46 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: 1CE8E05AB0A3ADACC91F6247F996909B4719EBAA X-UiO-SPAM-Test: remote_host: 51.175.221.75 spam_score: -49 maxlevel 99990 minaction 1 bait 0 mail/h: 1 total 106 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Stein Gjessing Subject: [Taps] Fwd: New Version Notification for draft-gjessing-taps-minset-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2016 16:54:21 -0000 --Apple-Mail=_9820BDEB-2B55-4A12-8432-42CB83F3DF38 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, We have submitted a new version of the =E2=80=9Csubset specification=E2=80= =9D draft (Taps work item 2). The main changes are caused by the updates in = draft-ietf-taps-transports-usage-02. Cheers, Stein > Begin forwarded message: >=20 > From: > Subject: New Version Notification for = draft-gjessing-taps-minset-03.txt > Date: 31 October 2016 at 15:41:23 GMT+1 > To: Stein Gjessing , Michael Welzl = > Resent-From: >=20 >=20 > A new version of I-D, draft-gjessing-taps-minset-03.txt > has been successfully submitted by Michael Welzl and posted to the > IETF repository. >=20 > Name: draft-gjessing-taps-minset > Revision: 03 > Title: A Minimal Set of Transport Services for TAPS = Systems > Document date: 2016-10-31 > Group: Individual Submission > Pages: 22 > URL: = https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset-03.txt > Status: = https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/ > Htmlized: = https://tools.ietf.org/html/draft-gjessing-taps-minset-03 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-gjessing-taps-minset-03 >=20 > Abstract: > This draft recommends a minimal set of IETF Transport Services > offered by end systems supporting TAPS, and gives guidance on > choosing among the available mechanisms and protocols. It is based > on the set of transport services given in the TAPS document draft- > ietf-taps-transports-usage-02. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_9820BDEB-2B55-4A12-8432-42CB83F3DF38 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

We = have submitted a new version of the =E2=80=9Csubset specification=E2=80=9D= draft  (Taps work item 2).
The main changes = are caused by the updates in = draft-ietf-taps-transports-usage-02.

Cheers,
Stein


Begin = forwarded message:

From: = <internet-drafts@ietf.org>
Subject: = New Version = Notification for draft-gjessing-taps-minset-03.txt
Date: = 31 October 2016 at 15:41:23 = GMT+1
To: = Stein Gjessing <steing@ifi.uio.no>, = Michael Welzl <michawe@ifi.uio.no>
Resent-From: = <steing@ifi.uio.no>

A new version of I-D, draft-gjessing-taps-minset-03.txt
has been successfully submitted by Michael Welzl and posted = to the
IETF repository.

Name: = = draft-gjessing-taps-minset
Revision: 03
Title:= = A Minimal Set of Transport Services for TAPS Systems
Document date: 2016-10-31
Group:= = Individual Submission
Pages: 22
URL: =            https://www.ietf.org/internet-drafts/draft-gjessing-taps-minset= -03.txt
Status: =         https://datatracker.ietf.org/doc/draft-gjessing-taps-minset/
Htmlized:       https://tools.ietf.org/html/draft-gjessing-taps-minset-03Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-gjessing-taps-minset-= 03

Abstract:
=   This draft recommends a minimal set of IETF Transport = Services
  offered by end systems supporting = TAPS, and gives guidance on
  choosing among = the available mechanisms and protocols.  It is based
=   on the set of transport services given in the TAPS document = draft-
  ietf-taps-transports-usage-02.




Please note that it may take a couple of minutes from the = time of submission
until the htmlized version and diff are = available at tools.ietf.org.

The IETF = Secretariat


= --Apple-Mail=_9820BDEB-2B55-4A12-8432-42CB83F3DF38-- From nobody Wed Nov 9 01:59:51 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D366E1298C3 for ; Wed, 9 Nov 2016 01:59:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJuRWvHU0r26 for ; Wed, 9 Nov 2016 01:59:47 -0800 (PST) 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 B3F7D1298B7 for ; Wed, 9 Nov 2016 01:59:46 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1c4PfU-0004Nd-QS for taps@ietf.org; Wed, 09 Nov 2016 10:59:44 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1c4PfU-0005B4-5f; Wed, 09 Nov 2016 10:59:44 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <61285C6A-6A02-4A45-9B00-F88ACF40F412@trammell.ch> Date: Wed, 9 Nov 2016 10:59:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <39A21561-156C-444C-830D-087D818B7441@ifi.uio.no> References: <147756225934.18900.10951893813111037167.idtracker@ietfa.amsl.com> <61285C6A-6A02-4A45-9B00-F88ACF40F412@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 2 sum rcpts/h 8 sum msgs/h 6 total rcpts 48503 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.553, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6A5BB96C1E4DE3A916A76A2746E03E4E71858136 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -65 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 11590 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] New Version Notification for draft-trammell-post-sockets-00.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 09:59:50 -0000 Hi, Thanks for posting a really interesting draft! Similar to the other (also interesting) draft that was just posted ( = draft-mcquistin-taps-low-latency-services-00.txt ), this reads quite a = bit like a "wish list". I'm not saying that's a bad thing, I think that both drafts contain an = interesting and very reasonable wish list (with quite some overlap, 1) = with each other, 2) with what current protocols provide, as we can see = from draft-gjessing-taps-minset-03). Both also identify at least one thing that seems missing in currently = standardized transports: being able to define dependencies between = messages. Interesting! However, given that current protocols don't do all these things, what's = the context here for TAPS? Should the charter be extended to allow for = such "wish lists" for future protocols? (Personally, I'd say yes) I mean, draft-mcquistin-taps-low-latency-services-00.txt even explicitly = says "The next phase, enabled both by the use of transport services and = their separation from transport protocols, is to define novel transport = services based on the needs of applications." I'd say this is clearly *not* what the charter says. When TAPS started, = lots of folks wanted this, but TAPS would have never seen the light of = day if we had put that in the charter. Now maybe it's time to be more = forward-looking? BTW, something that made me particularly curious is, in the draft = announced below, the following statement: "It must be possible to implement Post over vanilla TCP in the present = Internet architecture." - how? To start with, you require message delineation. What's the idea = here? Cheers, Michael > On 27 Oct 2016, at 14:52, Brian Trammell wrote: >=20 > Greetings, TAPS, >=20 > We've submitted an initial version of our Post Sockets abstract = interface draft, draft-trammell-post-sockets. It's not yet clear that = we'd want this to be adopted by the TAPS working group for a future = milestone in partial fulfillment of point 3 on the charter -- perhaps = the ideas here are merely an illustration of what is possible in the = space, that could point toward a more concrete definition of an abstract = interface for TAPS. We'd like to discuss this point in Seoul. >=20 > Thanks, cheers, >=20 > Brian >=20 >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for = draft-trammell-post-sockets-00.txt >> Date: 27 October 2016 at 11:57:39 GMT+2 >> To: "Mirja Kuehlewind" , "Tommy = Pauly" , "Brian Trammell" , "Colin = Perkins" >>=20 >>=20 >> A new version of I-D, draft-trammell-post-sockets-00.txt >> has been successfully submitted by Brian Trammell and posted to the >> IETF repository. >>=20 >> Name: draft-trammell-post-sockets >> Revision: 00 >> Title: Post Sockets, An Abstract Programming Interface = for the Transport Layer >> Document date: 2016-10-27 >> Group: Individual Submission >> Pages: 17 >> URL: = https://www.ietf.org/internet-drafts/draft-trammell-post-sockets-00.txt >> Status: = https://datatracker.ietf.org/doc/draft-trammell-post-sockets/ >> Htmlized: = https://tools.ietf.org/html/draft-trammell-post-sockets-00 >>=20 >>=20 >> Abstract: >> This document describes Post Sockets, an asynchronous abstract >> programming interface for the atomic transmission of objects in an >> explicitly multipath environment. Post replaces connections with >> long-lived associations between endpoints, with the possibility to >> cache cryptographic state in order to reduce amortized connection >> latency. We present this abstract interface as an illustration of >> what is possible with present developments in transport protocols >> when freed from the strictures of the current sockets API. >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed Nov 9 03:30:47 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF64F129A8C for ; Wed, 9 Nov 2016 03:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtkKHTu9zYeC for ; Wed, 9 Nov 2016 03:30:42 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 60E42129A8B for ; Wed, 9 Nov 2016 03:30:40 -0800 (PST) Received: from [IPv6:2001:67c:10ec:2a49:8000::10d6] (unknown [IPv6:2001:67c:10ec:2a49:8000::10d6]) by trammell.ch (Postfix) with ESMTPSA id 4328E1A108C; Wed, 9 Nov 2016 12:30:37 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_04462C83-006B-45DA-9582-29C1425A4572"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: <39A21561-156C-444C-830D-087D818B7441@ifi.uio.no> Date: Wed, 9 Nov 2016 12:30:36 +0100 Message-Id: <4CCC5329-A48B-46D5-8EB7-D53EC7E9265E@trammell.ch> References: <147756225934.18900.10951893813111037167.idtracker@ietfa.amsl.com> <61285C6A-6A02-4A45-9B00-F88ACF40F412@trammell.ch> <39A21561-156C-444C-830D-087D818B7441@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] New Version Notification for draft-trammell-post-sockets-00.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 11:30:45 -0000 --Apple-Mail=_04462C83-006B-45DA-9582-29C1425A4572 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Michael, > On 09 Nov 2016, at 10:59, Michael Welzl wrote: >=20 > Hi, >=20 > Thanks for posting a really interesting draft! >=20 > Similar to the other (also interesting) draft that was just posted ( = draft-mcquistin-taps-low-latency-services-00.txt ), this reads quite a = bit like a "wish list". To some extent, that's the point: if we started over, what would we want = the interface to look like. > I'm not saying that's a bad thing, I think that both drafts contain an = interesting and very reasonable wish list (with quite some overlap, 1) = with each other, 2) with what current protocols provide, as we can see = from draft-gjessing-taps-minset-03). > Both also identify at least one thing that seems missing in currently = standardized transports: being able to define dependencies between = messages. > Interesting! ...and shamelessly lifted from Minion. > However, given that current protocols don't do all these things, = what's the context here for TAPS? Should the charter be extended to = allow for such "wish lists" for future protocols? > (Personally, I'd say yes) So, there are two ways I see to do this: (1) Everything here except message delineation *works* without any = specific transport protocol support, it just works better if you have = transport protocols that support the contracts. Note that receive() = doesn't expose any of the object properties that send() takes, those = properties are only used for purposes of ordering, scheduling, and path = selection at the sender. So if you have a transport protocol that = doesn't support partial reliability, for instance, the lifetimes could = be silently ignored. The TAPS transport selection layer could give the = application access to information about which contracts of the API are = honored and which are not, but an application that didn't care could be = written once and still work on the worst fallback, if with less optimum = performance. (2) Alternately, a Post implementation more tightly integrated with a = TAPS one could raise errors on attempts to use contracts not supported = by the underlying transport. This requires more application logic = support, though, and negates one of the advantages we see of this = approach: write once, use any transport. > I mean, draft-mcquistin-taps-low-latency-services-00.txt even = explicitly says "The next phase, enabled both by the use of transport = services and their separation from transport protocols, is to define = novel transport services based on the needs of applications." > I'd say this is clearly *not* what the charter says. When TAPS = started, lots of folks wanted this, but TAPS would have never seen the = light of day if we had put that in the charter. Now maybe it's time to = be more forward-looking? Post doesn't say this *explicitly*, but I think you've noticed that it's = kind of assumed. Yes, I do think it's time to be forward-looking. Where = that looking forward happens is a different question: it could happen in = TAPS, or in its own WG or RG. In any case, it definitely needs to happen = hand in hand with TAPS, as it's an effort that can provide more = diversity in ways to implement services and features. (reading from my slides which I should send Aaron and Zahed shortly): At = least with respect to Post, we're just looking to start that = conversation now, to see how many people are interested in this next = step, and to get some feedback on what's good about what we're thinking, = and what's not so good. >=20 > BTW, something that made me particularly curious is, in the draft = announced below, the following statement: > "It must be possible to implement Post over vanilla TCP in the present = Internet architecture." > - how? To start with, you require message delineation. What's the idea = here? Ah, now you've found the older draft buried in the newer draft. :) That was an original hard requirement of the wishlist, but as we went = down the rabbithole of ordering our wishes the object framing (from = SEQPACKET) really stood out as a missing feature that makes sense to = have, and it's very hard to have a common API for a send() with = asynchronous recv() that doesn't just turn into a read/write loop unless = the message framing is there. Again, two approaches I can see to make this happen, neither of which is = very good IMO: (1) Define a framing layer (or choose an existing one; for maximum layer = confusion, how about websockets? ;) ) to run over vanilla TCP; in this = case, Post is less of an API than a flexible transport layer, since it = can't be used to connect to endpoints not running Post. (2) When running on vanilla TCP, only open_stream() works on an = association. Same drawbacks as in (2) above. Maybe try 1 with a fallback to 2, but then you'd need a negotiation = protocol running at both ends, rather than a sensing layer that can work = at each endpoint independently as in TAPS. Thanks, cheers, Brian > Cheers, > Michael >=20 >=20 >=20 >> On 27 Oct 2016, at 14:52, Brian Trammell wrote: >>=20 >> Greetings, TAPS, >>=20 >> We've submitted an initial version of our Post Sockets abstract = interface draft, draft-trammell-post-sockets. It's not yet clear that = we'd want this to be adopted by the TAPS working group for a future = milestone in partial fulfillment of point 3 on the charter -- perhaps = the ideas here are merely an illustration of what is possible in the = space, that could point toward a more concrete definition of an abstract = interface for TAPS. We'd like to discuss this point in Seoul. >>=20 >> Thanks, cheers, >>=20 >> Brian >>=20 >>> Begin forwarded message: >>>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for = draft-trammell-post-sockets-00.txt >>> Date: 27 October 2016 at 11:57:39 GMT+2 >>> To: "Mirja Kuehlewind" , "Tommy = Pauly" , "Brian Trammell" , "Colin = Perkins" >>>=20 >>>=20 >>> A new version of I-D, draft-trammell-post-sockets-00.txt >>> has been successfully submitted by Brian Trammell and posted to the >>> IETF repository. >>>=20 >>> Name: draft-trammell-post-sockets >>> Revision: 00 >>> Title: Post Sockets, An Abstract Programming Interface = for the Transport Layer >>> Document date: 2016-10-27 >>> Group: Individual Submission >>> Pages: 17 >>> URL: = https://www.ietf.org/internet-drafts/draft-trammell-post-sockets-00.txt >>> Status: = https://datatracker.ietf.org/doc/draft-trammell-post-sockets/ >>> Htmlized: = https://tools.ietf.org/html/draft-trammell-post-sockets-00 >>>=20 >>>=20 >>> Abstract: >>> This document describes Post Sockets, an asynchronous abstract >>> programming interface for the atomic transmission of objects in an >>> explicitly multipath environment. Post replaces connections with >>> long-lived associations between endpoints, with the possibility to >>> cache cryptographic state in order to reduce amortized connection >>> latency. We present this abstract interface as an illustration of >>> what is possible with present developments in transport protocols >>> when freed from the strictures of the current sockets API. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> The IETF Secretariat >>>=20 >>=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=_04462C83-006B-45DA-9582-29C1425A4572 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 iQIcBAEBCgAGBQJYIwjdAAoJEIoSt78L6kaj1mUQAIcPO8FY6ySV7PysPCK/Z6xZ OftGL3/GAstsfvkNvsyrNbaSaiO+nUwQZ93kc3oO/fEhnQJ6114rpZ5W2a38DuI7 ApYRIwJdCYB2syxhtrx1IrypPYby0ZS9xgaHUPJMQYB1iGGh3f0qi2p7RUUv6viE uugDQBynkV6iXuj5tweeP82xUM7mIMXQ1yuUJ+28uNqBe/A/WFfQ0Wfaf9rXI8CO fd+MchiXm17AiE8AAF9XFArwhivKRa5DVvhyH7+ij/tA0pKiGN1CKY3E56U/srs/ ZkV5pQ1Da9gsjO2zuehAD8CIYlvVKKN+LJ3Ujlk/YpieCW34V5VfcWnPa6j6poUf uq+etDaLqNnyzdeNDEo4WE5GOdNf19GmNOWfhx09bJOGTAoNx1q/+/UUwZfee8SL V3wxcr7+2JVZF/VucGdEhFOnE0axfl50OkBF7Mf0ZETLKQ8l49JyxSJXZp3VsxSS MMBYiKjTdS15Qo80i25HWwPVNGcXhBurs+dK+VRLKu3ybW17w6qQUPtXAxtjfT+e wpSRUsxwTBA9mmIn64uHndoJT+Eh1cU88XKSSSlDDJmWyap69uuygdl/TeKB4t0d i79c4ITacjDYdItgb/qdIp7gl2UUyMLE7mYvDVX/Nfi7Fa/OZRSmKqgPvMhXg/79 EwzJUv2M8h1B/sMg6QnN =feot -----END PGP SIGNATURE----- --Apple-Mail=_04462C83-006B-45DA-9582-29C1425A4572-- From nobody Wed Nov 9 04:19:43 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC3E01296F6 for ; Wed, 9 Nov 2016 04:19:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmbsUbybd8Ly for ; Wed, 9 Nov 2016 04:19:39 -0800 (PST) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27B041295CD for ; Wed, 9 Nov 2016 04:19:37 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out02.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1c4Rqp-0002PL-5w for taps@ietf.org; Wed, 09 Nov 2016 13:19:35 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1c4Rqo-00079p-BJ; Wed, 09 Nov 2016 13:19:35 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <4CCC5329-A48B-46D5-8EB7-D53EC7E9265E@trammell.ch> Date: Wed, 9 Nov 2016 13:19:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <99C4947A-1B5B-411F-841B-08D7CE63878B@ifi.uio.no> References: <147756225934.18900.10951893813111037167.idtracker@ietfa.amsl.com> <61285C6A-6A02-4A45-9B00-F88ACF40F412@trammell.ch> <39A21561-156C-444C-830D-087D818B7441@ifi.uio.no> <4CCC5329-A48B-46D5-8EB7-D53EC7E9265E@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 9 sum msgs/h 5 total rcpts 48517 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.6, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.553, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 313622D14E1D3044746348401C0822E987FC9A06 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -65 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 11597 max/h 21 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] New Version Notification for draft-trammell-post-sockets-00.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 12:19:42 -0000 > On 09 Nov 2016, at 12:30, Brian Trammell wrote: >=20 > hi Michael, >=20 >> On 09 Nov 2016, at 10:59, Michael Welzl wrote: >>=20 >> Hi, >>=20 >> Thanks for posting a really interesting draft! >>=20 >> Similar to the other (also interesting) draft that was just posted ( = draft-mcquistin-taps-low-latency-services-00.txt ), this reads quite a = bit like a "wish list". >=20 > To some extent, that's the point: if we started over, what would we = want the interface to look like. >=20 >> I'm not saying that's a bad thing, I think that both drafts contain = an interesting and very reasonable wish list (with quite some overlap, = 1) with each other, 2) with what current protocols provide, as we can = see from draft-gjessing-taps-minset-03). >> Both also identify at least one thing that seems missing in currently = standardized transports: being able to define dependencies between = messages. >> Interesting! >=20 > ...and shamelessly lifted from Minion. Well - this seems to be a pretty general requirement, coming from HTTP/2 = as well... >> However, given that current protocols don't do all these things, = what's the context here for TAPS? Should the charter be extended to = allow for such "wish lists" for future protocols? >> (Personally, I'd say yes) >=20 > So, there are two ways I see to do this: >=20 > (1) Everything here except message delineation *works* without any = specific transport protocol support, well and (as Minion identified) it all begins and ends with message = delineation really - you're not able to offer much of what this draft = describes unless you have message delineation. > it just works better if you have transport protocols that support the = contracts. Note that receive() doesn't expose any of the object = properties that send() takes, those properties are only used for = purposes of ordering, scheduling, and path selection at the sender. So = if you have a transport protocol that doesn't support partial = reliability, for instance, the lifetimes could be silently ignored. The = TAPS transport selection layer could give the application access to = information about which contracts of the API are honored and which are = not, but an application that didn't care could be written once and still = work on the worst fallback, if with less optimum performance. That seems good to me. > (2) Alternately, a Post implementation more tightly integrated with a = TAPS one could raise errors on attempts to use contracts not supported = by the underlying transport. This requires more application logic = support, though, and negates one of the advantages we see of this = approach: write once, use any transport. The approach we ended up taking in NEAT (to be presented) is to always = choose between "required" or "desired". "Required" means the API fails and gets back to you; "desired" means you = get a fall-back as you describe here. This yields the flexibility that = TAPS wants to achieve, yet allows applications to be in control of the = things they really must control. >> I mean, draft-mcquistin-taps-low-latency-services-00.txt even = explicitly says "The next phase, enabled both by the use of transport = services and their separation from transport protocols, is to define = novel transport services based on the needs of applications." >> I'd say this is clearly *not* what the charter says. When TAPS = started, lots of folks wanted this, but TAPS would have never seen the = light of day if we had put that in the charter. Now maybe it's time to = be more forward-looking? >=20 > Post doesn't say this *explicitly*, but I think you've noticed that = it's kind of assumed. Yes, I do think it's time to be forward-looking. = Where that looking forward happens is a different question: it could = happen in TAPS, or in its own WG or RG. In any case, it definitely needs = to happen hand in hand with TAPS, as it's an effort that can provide = more diversity in ways to implement services and features. So here's a question. To implement e.g. Post with TCP, one could also = provide a layer on top of TCP that offers the suggested API and at least = takes care of message delineation (and then that layer could use other = protocols instead of TCP too). This would need to be there on both ends = of a connection. I mean, AFAIK, as Minion developed, it was at some point suggested to = not insert a delimiter in TCP as part of TCP's functionality, but to = simply use delimiters coming from app-layer protocols. I.e., when that = protocol has a delimiter, why use another one? If that's what we need, then all of a sudden, we're not discussing a = forward-looking wish-list anymore, but a way to implement a TAPS system. = I'd think that would be a better direction than just creating a wish = list for new protocols... but both could be done, I guess. > (reading from my slides which I should send Aaron and Zahed shortly): = At least with respect to Post, we're just looking to start that = conversation now, to see how many people are interested in this next = step, and to get some feedback on what's good about what we're thinking, = and what's not so good. >=20 >>=20 >> BTW, something that made me particularly curious is, in the draft = announced below, the following statement: >> "It must be possible to implement Post over vanilla TCP in the = present Internet architecture." >> - how? To start with, you require message delineation. What's the = idea here? >=20 > Ah, now you've found the older draft buried in the newer draft. :) >=20 > That was an original hard requirement of the wishlist, but as we went = down the rabbithole of ordering our wishes the object framing (from = SEQPACKET) really stood out as a missing feature that makes sense to = have, and it's very hard to have a common API for a send() with = asynchronous recv() that doesn't just turn into a read/write loop unless = the message framing is there. Right. > Again, two approaches I can see to make this happen, neither of which = is very good IMO: >=20 > (1) Define a framing layer (or choose an existing one; for maximum = layer confusion, how about websockets? ;) ) to run over vanilla TCP; in = this case, Post is less of an API than a flexible transport layer, since = it can't be used to connect to endpoints not running Post. >=20 > (2) When running on vanilla TCP, only open_stream() works on an = association. Same drawbacks as in (2) above. >=20 > Maybe try 1 with a fallback to 2, but then you'd need a negotiation = protocol running at both ends, rather than a sensing layer that can work = at each endpoint independently as in TAPS. Sorry for inventing the same as you in my answer above :-) it seems = we completely agree here. I also agree that both (1) and (2) would be = possible solutions. Interesting idea about the fallback - indeed, wouldn't trying (1) with a = fallback to (2) be ideal?! Cheers, Michael From nobody Wed Nov 9 07:15:48 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F52129525 for ; Wed, 9 Nov 2016 07:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ASMZ4YXHkst for ; Wed, 9 Nov 2016 07:15:43 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id C14D812955D for ; Wed, 9 Nov 2016 07:15:41 -0800 (PST) Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id 014011A0106; Wed, 9 Nov 2016 16:15:09 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CA7E6F33-2B01-444F-9699-A6C57BC16AE7"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: <99C4947A-1B5B-411F-841B-08D7CE63878B@ifi.uio.no> Date: Wed, 9 Nov 2016 16:15:08 +0100 Message-Id: <94B1277E-1243-4804-81AD-02251518B8E0@trammell.ch> References: <147756225934.18900.10951893813111037167.idtracker@ietfa.amsl.com> <61285C6A-6A02-4A45-9B00-F88ACF40F412@trammell.ch> <39A21561-156C-444C-830D-087D818B7441@ifi.uio.no> <4CCC5329-A48B-46D5-8EB7-D53EC7E9265E@trammell.ch> <99C4947A-1B5B-411F-841B-08D7CE63878B@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] New Version Notification for draft-trammell-post-sockets-00.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 15:15:45 -0000 --Apple-Mail=_CA7E6F33-2B01-444F-9699-A6C57BC16AE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Michael, (snipping some history...) >> (2) Alternately, a Post implementation more tightly integrated with a = TAPS one could raise errors on attempts to use contracts not supported = by the underlying transport. This requires more application logic = support, though, and negates one of the advantages we see of this = approach: write once, use any transport. >=20 > The approach we ended up taking in NEAT (to be presented) is to always = choose between "required" or "desired". > "Required" means the API fails and gets back to you; "desired" means = you get a fall-back as you describe here. This yields the flexibility = that TAPS wants to achieve, yet allows applications to be in control of = the things they really must control. That's a good distinction to make. This, of course, doesn't solve the = problem of needing a framing to make this work, as noted below. >>> I mean, draft-mcquistin-taps-low-latency-services-00.txt even = explicitly says "The next phase, enabled both by the use of transport = services and their separation from transport protocols, is to define = novel transport services based on the needs of applications." >>> I'd say this is clearly *not* what the charter says. When TAPS = started, lots of folks wanted this, but TAPS would have never seen the = light of day if we had put that in the charter. Now maybe it's time to = be more forward-looking? >>=20 >> Post doesn't say this *explicitly*, but I think you've noticed that = it's kind of assumed. Yes, I do think it's time to be forward-looking. = Where that looking forward happens is a different question: it could = happen in TAPS, or in its own WG or RG. In any case, it definitely needs = to happen hand in hand with TAPS, as it's an effort that can provide = more diversity in ways to implement services and features. >=20 > So here's a question. To implement e.g. Post with TCP, one could also = provide a layer on top of TCP that offers the suggested API and at least = takes care of message delineation (and then that layer could use other = protocols instead of TCP too). This would need to be there on both ends = of a connection. > I mean, AFAIK, as Minion developed, it was at some point suggested to = not insert a delimiter in TCP as part of TCP's functionality, but to = simply use delimiters coming from app-layer protocols. I.e., when that = protocol has a delimiter, why use another one? >=20 > If that's what we need, then all of a sudden, we're not discussing a = forward-looking wish-list anymore, but a way to implement a TAPS system. = I'd think that would be a better direction than just creating a wish = list for new protocols... but both could be done, I guess. So I'm not sure I understand what you're suggesting here... are you = saying that there'd be some application-layer callback to determine = where the framing is on the receive side? Yeah, that might work. (If = that's not what you're saying... well, it might work anyway :) ) >> Again, two approaches I can see to make this happen, neither of which = is very good IMO: >>=20 >> (1) Define a framing layer (or choose an existing one; for maximum = layer confusion, how about websockets? ;) ) to run over vanilla TCP; in = this case, Post is less of an API than a flexible transport layer, since = it can't be used to connect to endpoints not running Post. >>=20 >> (2) When running on vanilla TCP, only open_stream() works on an = association. Same drawbacks as in (2) above. >>=20 >> Maybe try 1 with a fallback to 2, but then you'd need a negotiation = protocol running at both ends, rather than a sensing layer that can work = at each endpoint independently as in TAPS. >=20 > Sorry for inventing the same as you in my answer above :-) it seems = we completely agree here. I also agree that both (1) and (2) would be = possible solutions. > Interesting idea about the fallback - indeed, wouldn't trying (1) with = a fallback to (2) be ideal?! Yes, except that there the application has to know about the fallback, = and has to work with streams, which changes its logic. And it'd be nice = if we could avoid that. But if there were a way to piggyback on = application-layer framing, that might make this less awkward. I think we're on to something. In any case, it definitely answers the = first question we had (do we want to talk about this further in a TAPS = context?) Cheers, Brian --Apple-Mail=_CA7E6F33-2B01-444F-9699-A6C57BC16AE7 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 iQIcBAEBCgAGBQJYIz19AAoJEIoSt78L6kajmWAP/jt8Efr6S3bJeMQ9uKSgst3N 7VHRFCddSm1EsNXASZsUO0eGo77EUmYSqO8OQq9qrVZRwUP/EbeoTwc3rd4nKBi4 g+R54eVPwJA31lFOsAPT+qsPH6Uc4feFCFdHavGR8PUvBMPHEX9IFWL21sPUIwDF e/394y6D0jV+R7t8x2HLQLVQJ1w442yG+SmxpSqru8KIj5Y92HtKDj4B2AoltlMf Sv6PTeGosKlEWMN1lTBNyk56KS0uUCQL3NtCNMGHHU0BO8saKwWvdmLvMiwNB/03 jKUAP//7u31Vs1dIQHd7Emz/iAd4c/1vKkFrNd5iFKdiYuAs0vFN70nnoeGzxsjS amK6NRDGIe2LTXn7p/otPaw6bwavnb2HrV/l7zgRvOCjW+G7+tdxcn2p9YMZKG0g icLE9Dg/s3jorfDDQd53ZshkrKeRvO7imWJtknxDtYVr7ivAOFmVG48PCbgHjYJN EZ/b7lQnoecQhi/j7aJyNgfeOcYLJdzFqoLbUNQId9LHrGPq3Y+NcyY/VobnHHSF BZ3xISBgiTtcVF2xTA62B6dH2Ixp5/U0uevoaaJDvk+Ur8ks20pbd7UE8kFmbn3N jwCiyhEAF5rHV+EfbTIRO2ykfjt4ia4hdwiaILKN5ryywkZzJ32zs/afHwiwHGAb YfQkOe6SAXqw3CGzr9wO =M7Eh -----END PGP SIGNATURE----- --Apple-Mail=_CA7E6F33-2B01-444F-9699-A6C57BC16AE7-- From nobody Wed Nov 9 12:06:52 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2C6129580 for ; Wed, 9 Nov 2016 12:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.097 X-Spam-Level: X-Spam-Status: No, score=-4.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZOVAeW6MpAm for ; Wed, 9 Nov 2016 12:06:48 -0800 (PST) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB581293F9 for ; Wed, 9 Nov 2016 12:06:48 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1c4Z8v-0004xl-U5 for taps@ietf.org; Wed, 09 Nov 2016 21:06:45 +0100 Received: from 234.133.189.109.customer.cdi.no ([109.189.133.234] helo=[192.168.1.8]) by mail-mx4.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.80) (envelope-from ) id 1c4Z8v-0005ob-C7; Wed, 09 Nov 2016 21:06:45 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Michael Welzl In-Reply-To: <94B1277E-1243-4804-81AD-02251518B8E0@trammell.ch> Date: Wed, 9 Nov 2016 21:07:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147756225934.18900.10951893813111037167.idtracker@ietfa.amsl.com> <61285C6A-6A02-4A45-9B00-F88ACF40F412@trammell.ch> <39A21561-156C-444C-830D-087D818B7441@ifi.uio.no> <4CCC5329-A48B-46D5-8EB7-D53EC7E9265E@trammell.ch> <99C4947A-1B5B-411F-841B-08D7CE63878B@ifi.uio.no> <94B1277E-1243-4804-81AD-02251518B8E0@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.3251) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 9 sum msgs/h 4 total rcpts 48543 max rcpts/h 54 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: 15293A3C935AA2EB6594812AABD1EC5570B37298 X-UiO-SPAM-Test: remote_host: 109.189.133.234 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 429 max/h 12 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] New Version Notification for draft-trammell-post-sockets-00.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2016 20:06:50 -0000 Hi, Snipping too... > So I'm not sure I understand what you're suggesting here... are you = saying that there'd be some application-layer callback to determine = where the framing is on the receive side? Yeah, that might work. (If = that's not what you're saying... well, it might work anyway :) ) Yes that=E2=80=99s what I meant >>> Again, two approaches I can see to make this happen, neither of = which is very good IMO: >>>=20 >>> (1) Define a framing layer (or choose an existing one; for maximum = layer confusion, how about websockets? ;) ) to run over vanilla TCP; in = this case, Post is less of an API than a flexible transport layer, since = it can't be used to connect to endpoints not running Post. >>>=20 >>> (2) When running on vanilla TCP, only open_stream() works on an = association. Same drawbacks as in (2) above. >>>=20 >>> Maybe try 1 with a fallback to 2, but then you'd need a negotiation = protocol running at both ends, rather than a sensing layer that can work = at each endpoint independently as in TAPS. >>=20 >> Sorry for inventing the same as you in my answer above :-) it = seems we completely agree here. I also agree that both (1) and (2) would = be possible solutions. >> Interesting idea about the fallback - indeed, wouldn't trying (1) = with a fallback to (2) be ideal?! >=20 > Yes, except that there the application has to know about the fallback, = and has to work with streams, which changes its logic. Yes, but no way around that unless you know what=E2=80=99s going on on = the receiver side. > And it'd be nice if we could avoid that. But if there were a way to = piggyback on application-layer framing, that might make this less = awkward. I would have thought the opposite? I don=E2=80=99t know what an API that = uses app-layer framing looks like (I guess Jana worked on that while at = Apple?), but I suspect it=E2=80=99s more awkward than just having = delimiters available from below? Somehow the transport, or shim layer = above it, on both sides, needs to be able to identify the delimiter, and = so the format must be known to it. This means that the application would = have to tell that layer the format of its app-layer delimiter - rather = than just having a post-like interface that uses messages or objects, = and perhaps getting a failure / fallback, which - I think - is annoying = but inevitable. So, considering that delimiters are the key missing piece here, maybe = TAPS should define how such a shim over TCP should work, with delimiters = and signaling to be able to fall back if the other side doesn=E2=80=99t = have it? > I think we're on to something. In any case, it definitely answers the = first question we had (do we want to talk about this further in a TAPS = context?) Yes=E2=80=A6 I agree, I think we=E2=80=99re on to something here. Thanks again, actually to all authors of both these drafts, for helping = make TAPS more interesting! Cheers, Michael From nobody Fri Nov 11 02:01:46 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6D0129544; Fri, 11 Nov 2016 02:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xrO-_4ka5WE; Fri, 11 Nov 2016 02:01:44 -0800 (PST) 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 42A88129AA2; Fri, 11 Nov 2016 02:01:27 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUZ35118; Fri, 11 Nov 2016 10:01:24 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 11 Nov 2016 10:01:23 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0235.001; Fri, 11 Nov 2016 02:01:19 -0800 From: Linda Dunbar To: "draft-mcquistin-taps-low-latency-services@ietf.org" Thread-Topic: Which APIs are used by Applications that need low Latency? draft-mcquistin-taps-low-latency-services? Thread-Index: AdI7mmITtgwBluJVR9G2gyZVw8JAdA== Date: Fri, 11 Nov 2016 10:01:19 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657F6AC3A@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.130] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657F6AC3Adfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.582596F5.00B8, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c0a10ba3e679275348a74ed2b67e22ee Archived-At: Cc: "taps@ietf.org" Subject: [Taps] Which APIs are used by Applications that need low Latency? draft-mcquistin-taps-low-latency-services? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 10:01:45 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657F6AC3Adfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, Your draft listed down several APIs. But which one is used by Applications = that need low latency? Aren't the "Socket Setup & Tear down" described in Section 3.1 the original= Berkley sockets APIs? If not, what are the differences? How about the "getsocketopt" and "Setsockopt"? and the APIs listed in Sect= ion 3.3.? Which APIs are used by Applications that need low Latency? Are there any Applications today using the APIs proposed in draft-mcquistin= -taps-low-latency-services? Thank you very much, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657F6AC3Adfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Authors,

 

Your draft listed down several APIs. But which one i= s used by Applications that need low latency?

 

Aren’t the “Socket Setup & Tear down= ” described in Section 3.1 the original Berkley sockets APIs? If not,= what are the differences?

 

How about the “getsocketopt” and “= Setsockopt”?  and the APIs listed in Section 3.3.?

 

Which APIs are used by Applications that need low La= tency?

 

Are there any Applications today using the APIs prop= osed in draft-mcquistin-taps-low-latency-services?

 

Thank you very much,

 

Linda Dunbar

--_000_4A95BA014132FF49AE685FAB4B9F17F657F6AC3Adfweml501mbb_-- From nobody Fri Nov 11 03:32:28 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6551E129AFB; Fri, 11 Nov 2016 03:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22eyTFT0kXlt; Fri, 11 Nov 2016 03:32:24 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [93.93.131.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C683D129B01; Fri, 11 Nov 2016 03:31:04 -0800 (PST) Received: from [2001:630:40:70e0::107] (port=58196) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1c5A2w-0001vd-7p; Fri, 11 Nov 2016 11:31:02 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Colin Perkins In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657F6AC3A@dfweml501-mbb> Date: Fri, 11 Nov 2016 11:30:54 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3BB18894-22E6-4B03-AA6D-EC2CB274B674@csperkins.org> References: <4A95BA014132FF49AE685FAB4B9F17F657F6AC3A@dfweml501-mbb> To: Linda Dunbar X-Mailer: Apple Mail (2.3124) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: Threshold = On = Archived-At: Cc: "draft-mcquistin-taps-low-latency-services@ietf.org" , "taps@ietf.org" Subject: Re: [Taps] Which APIs are used by Applications that need low Latency? draft-mcquistin-taps-low-latency-services? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2016 11:32:27 -0000 Hi Linda, The key goal of the draft is to do a requirements analysis on the = transport services needed for low-latency and real-time applications. = The proposed abstract API is the minimal API to achieve this. The new = API features, compared to the Sockets API, are those in Sections = 3.4-3.6. We have an experimental implementation of an API much like this, written = as part of our TCP Hollywood work = (https://csperkins.org/research/tcp-hollywood/). This is a research = prototype, so there are no deployed applications using it.=20 If you=E2=80=99re interested in the API work, the proposal in = draft-trammell-post-sockets-00 is a more interesting, and radical, = approach, and should also meet the requirements we outline. Colin > On 11 Nov 2016, at 10:01, Linda Dunbar = wrote: >=20 > Dear Authors,=20 > =20 > Your draft listed down several APIs. But which one is used by = Applications that need low latency? > =20 > Aren=E2=80=99t the =E2=80=9CSocket Setup & Tear down=E2=80=9D = described in Section 3.1 the original Berkley sockets APIs? If not, what = are the differences? > =20 > How about the =E2=80=9Cgetsocketopt=E2=80=9D and =E2=80=9CSetsockopt=E2=80= =9D? and the APIs listed in Section 3.3.? > =20 > Which APIs are used by Applications that need low Latency?=20 > =20 > Are there any Applications today using the APIs proposed in = draft-mcquistin-taps-low-latency-services? > =20 > Thank you very much,=20 > =20 > Linda Dunbar --=20 Colin Perkins https://csperkins.org/ From nobody Sun Nov 13 13:42:17 2016 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 603401293D6; Sun, 13 Nov 2016 13:42:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147907333236.5643.8006645735737995596.idtracker@ietfa.amsl.com> Date: Sun, 13 Nov 2016 13:42:12 -0800 Archived-At: Cc: taps@ietf.org Subject: [Taps] I-D Action: draft-ietf-taps-transports-usage-udp-00.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Nov 2016 21:42:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services of the IETF. Title : Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- Lite) Transport Protocols Authors : Godred Fairhurst Tom Jones Filename : draft-ietf-taps-transports-usage-udp-00.txt Pages : 18 Date : 2016-11-13 Abstract: This document describes how the User Datagram Protocol (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport protocols expose services to applications and how an application can configure and use the features offered by the transport service. The document is intended as a contribution to the Transport Services (TAPS) working group to assist in analysis of the UDP and UDP-Lite transport interface. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transports-usage-udp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-taps-transports-usage-udp-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 15 17:48:45 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95578129405 for ; Tue, 15 Nov 2016 17:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Im8WeFbiKxQZ for ; Tue, 15 Nov 2016 17:48:43 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 07301129411 for ; Tue, 15 Nov 2016 17:48:43 -0800 (PST) Received: from dhcp-8920.meeting.ietf.org (unknown [31.133.138.32]) by trammell.ch (Postfix) with ESMTPSA id D38101A0509 for ; Wed, 16 Nov 2016 02:48:11 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_47FA84D6-21A1-4517-B2BE-61D679182B8C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: <4985BCB5-45E5-496C-BCDD-6C6DE62C0712@trammell.ch> Date: Wed, 16 Nov 2016 10:48:08 +0900 Message-Id: References: <4985BCB5-45E5-496C-BCDD-6C6DE62C0712@trammell.ch> To: taps WG X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Taps] draft-trammell-post-sockets X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 01:48:44 -0000 --Apple-Mail=_47FA84D6-21A1-4517-B2BE-61D679182B8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, all, Looking at where we are in the agenda, we're not going to get to talk = about Post Sockets in the meeting in Seoul today. As most of the = properties of the API are already being discussed during Colin's = presentation, this isn't that big a deal. However, if anyone who has = read draft-trammell-post-sockets would like to talk to us about it here = in Seoul, please drop me a line. To answer Zahed's question at the beginning of the meeting: we didn't = call this draft-trammell-taps-post-sockets because it's not clear that = it's really in scope for TAPS. It presents a radically changed = replacement in the abstract for the sockets API. However, if the working = group is interested in continuing to discuss it, we're happy to resubmit = as draft-trammell-taps-post-sockets if it makes things easier to follow. = :) Cheers, Brian --Apple-Mail=_47FA84D6-21A1-4517-B2BE-61D679182B8C 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 iQIcBAEBCgAGBQJYK7rYAAoJEIoSt78L6kaj6X0P/3hSZDSRkge3VHGenSBbsZDc hbCMnSUMPievftsMar2bU7kQAY8zPrQ4GKR+o7cGooj8rBFWZ6OB9wAb110fG7aM 4jEUwUj92CafIrphjjBbktrAK6rLWhOaJtguGwYov1q8s1+DVojezzKA6hwzX8GH 27cW5LZ7wZ6bUwtO+rcrMoEjj9Mna90NxvxDygajH3Z7s0aLSd9C//IZqxhFsDlf yEuFp7C/r7SQDxp0rVO56tSXcLeIZEjQ6EYXcvOqwj4JWP41t9vOICH7ON40WwdP plrgGJ3l11Fv8O3f0pMUnlvxZCoWDs1n4dsSfF4lkniffmm78dfw4EZYrRjdKVCP RMhcYg0Ddch+fl1kZaQILmQ6JbcNHgTfcJ0Gady14A0FvLsqLV+0dlRUc2+of+z+ r81HRtSUKktDG/Kfo0pA3zVkGznuWNUDkM2A1DDlXJwgPZRUY9KQjXAWr6C9qkat GzLEzXZuFnqQBQyGJglXmuIR57M882nHEmy63ESwJONwRTnldithPbAZYj8C3KZs RRRA7FH9Mnng5gyk27aXgHPQvH70Mjiri/3NMY7TlxTpqKA00wsAIt1n/4f73a26 0X9Vm6foYXxd36QdwYqP0FUQFstmgDvYHOr+52PCVUYKS2/tz88vsW5Sbrued0GG ZGsH7/kZ68qghq1RYFMR =JbbE -----END PGP SIGNATURE----- --Apple-Mail=_47FA84D6-21A1-4517-B2BE-61D679182B8C-- From nobody Tue Nov 15 18:04:14 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52260128874 for ; Tue, 15 Nov 2016 18:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMlOWQSCfZ_z for ; Tue, 15 Nov 2016 18:04:11 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id DD132129411 for ; Tue, 15 Nov 2016 18:04:10 -0800 (PST) Received: from dhcp-8920.meeting.ietf.org (unknown [31.133.138.32]) by trammell.ch (Postfix) with ESMTPSA id 6E9C51A05C6; Wed, 16 Nov 2016 03:04:08 +0100 (CET) From: Brian Trammell X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_F08693D3-86AD-4A13-B6C0-41479D93A5FE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Wed, 16 Nov 2016 11:04:04 +0900 Message-Id: <3FA7BF3A-B337-4809-A148-41C8BFBCD1FB@trammell.ch> To: Michael Welzl Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Cc: taps WG Subject: [Taps] paragraph on why taps-transports-usage doesn't mention security X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 02:04:12 -0000 --Apple-Mail=_F08693D3-86AD-4A13-B6C0-41479D93A5FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Michael, As promised in the WG meeting just now, here's a first pass on a = paragraph on the missing security transport service features. It = probably goes in the Security Considerations section. Authentication, confidentiality protection, and integrity protection are = identified as transport service features by [I-D.ietf-taps-transports]. = As currently deployed in the Internet, these features are generally = provided by a protocol or layer on top of the transport protocol; no = current full-featured standards-track transport protocol provides these = features on its own. Therefore, these features are not considered in = this document. Cheers, Brian --Apple-Mail=_F08693D3-86AD-4A13-B6C0-41479D93A5FE 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 iQIcBAEBCgAGBQJYK76VAAoJEIoSt78L6kaj2tcQALt1eQ6UJTtlQzlFRxuxPH6a qKd1EICXI447ei3AFjRlQ2oCUbcU6Q6qj8S2GgjDeK4nCCuoqaOjlyN5bjuDJth8 7Om5ESIlbbB9WCcIgRjQ1knSjxCaKwwsA5M5zqhIYRb0Gs9SxyRE2u+7yHqVI/KN eeEAY1QclHX24rYBQWaIJSFpzrk6WgiArIIenCd9SCvBJqyb5/jh04YFkQZ+Ha4h i8TaQ42D5H9ywhuM7Q5uvtBVdlW/WVEaA09PzNIdACbFtvXuSS5DV4d0Sy3DGs5D YAdJjHN/m2i38kYitNuVvZjc8qJtD98vHXbLNWjAI3wOGDzmbVJDl6ech9kbEVd4 KABzrdYTFhkV7tp1rRCjd2se9MrDnmdxRtnQDR2dYxUXmbvFWbawQgGyMsMEuCPh 7ctH1mDoeYo0+5wqAf1vqIibgtWuxJ0qKta2NP7VULSQuYg0wsEUS2rM4DZ3rRWd opZX6oj6dF4aR7+6RqCV9ujYNWNCscwmg1S48cGnrhMJKaZtiJ2WK6o6H7PM5kTw Y5NzgzB1lP2xYduZVBBzsOxYiTEepIWhSSaNE5Oez8l8B1kyqMGVPQhww3RmGBwe k+645TCzQdPu+DdA1w0u4xCL/YkzTzG5lN8bbqaYRMp3fFv4GEadzfetEz18BsYm Ht2kB+NlshFOaxPZCU1p =D7DG -----END PGP SIGNATURE----- --Apple-Mail=_F08693D3-86AD-4A13-B6C0-41479D93A5FE-- From nobody Tue Nov 15 18:06:28 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7661295FC for ; Tue, 15 Nov 2016 18:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xru2ubghHd2e for ; Tue, 15 Nov 2016 18:06:25 -0800 (PST) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7A881295A6 for ; Tue, 15 Nov 2016 18:06:24 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1c6pcE-00046S-KY for taps@ietf.org; Wed, 16 Nov 2016 03:06:22 +0100 Received: from dhcp-8409.meeting.ietf.org ([31.133.132.9]) by mail-mx1.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.80) (envelope-from ) id 1c6pb4-0000ck-Lq; Wed, 16 Nov 2016 03:06:20 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Michael Welzl In-Reply-To: <3FA7BF3A-B337-4809-A148-41C8BFBCD1FB@trammell.ch> Date: Wed, 16 Nov 2016 11:05:05 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <83251B5F-8939-42BB-8B35-90621824E212@ifi.uio.no> References: <3FA7BF3A-B337-4809-A148-41C8BFBCD1FB@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.3251) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 4 sum msgs/h 2 total rcpts 48814 max rcpts/h 54 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: 0F4E338EC2D39834B379B3E0A3C1AD9DDFA9917C X-UiO-SPAM-Test: remote_host: 31.133.132.9 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 20 max/h 6 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] paragraph on why taps-transports-usage doesn't mention security X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 02:06:27 -0000 Great, thanks - both for the text and the amazing delivery speed! :) Cheers, Michael > On Nov 16, 2016, at 11:04 AM, Brian Trammell wrote: >=20 > hi Michael, >=20 > As promised in the WG meeting just now, here's a first pass on a = paragraph on the missing security transport service features. It = probably goes in the Security Considerations section. >=20 > Authentication, confidentiality protection, and integrity protection = are identified as transport service features by = [I-D.ietf-taps-transports]. As currently deployed in the Internet, these = features are generally provided by a protocol or layer on top of the = transport protocol; no current full-featured standards-track transport = protocol provides these features on its own. Therefore, these features = are not considered in this document. >=20 >=20 > Cheers, >=20 > Brian From nobody Tue Nov 15 23:12:58 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D73129452 for ; Tue, 15 Nov 2016 23:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-uoBcyJZlU1 for ; Tue, 15 Nov 2016 23:12:55 -0800 (PST) Received: from mail-in2.asia.apple.com (mail-out.asia.apple.com [17.82.254.64]) (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 F3256129421 for ; Tue, 15 Nov 2016 23:12:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1479280325; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IvnzlSQeH4xhqJsBX/YLYaTXhi6SnVVg2JvozaI10Gs=; b=r3ypV19g9flLm25qLLxyOkRqjw7maOmmPUVdxyi1im31g2LE2brjTfD70qvTYA18 m+XQUOpM84NJEfbOTJrMbiXt7RVcI2UjO2TRh/DpS1PbDOMo+m2q4aRLXP9Ix9pm el0MhrdkGLiGJKqDPPoIpJ7D7ev1bPT5F5Fhc3dNG6jVCY86TUkXhxXj6bXrAIJD MUnDG9xuFYaQNdpOxzzC2CeZjSWd7UJS5bsvqWeAQ9yJudxpixfvU6Mmu5QydDVZ 0F/vMuc9SjNZWtRbAP8T0vaT8QTkVkB7sQ8Gvip/cd5mWe7eE0FUDLpDr23Z67qA b/Ybu4OblTTbGEFXITe/4g==; Received: from relay1.asia.apple.com ( [17.82.200.18]) by mail-in2.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 95.51.24048.5C60C285; Wed, 16 Nov 2016 15:12:05 +0800 (MYT) X-AuditID: 1152fe06-ac30b9a000005df0-83-582c06c5dab5 Received: from sng-mmpp-sz01.asia.apple.com ( [17.84.80.62]) by relay1.asia.apple.com (Apple Singapore relay) with SMTP id 29.9E.08629.4F60C285; Wed, 16 Nov 2016 15:12:52 +0800 (MYT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.83.168.3] (unknown [17.83.168.3]) by sng-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OGQ00FCD41ACY90@sng-mmpp-sz01.asia.apple.com>; Wed, 16 Nov 2016 15:12:52 +0800 (SGT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: Date: Wed, 16 Nov 2016 16:12:46 +0900 Message-id: References: <4985BCB5-45E5-496C-BCDD-6C6DE62C0712@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.3252) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUiGHRCSPcom06EwcffyhYbW96xWdyJcWDy WLLkJ5PHk/0zWQKYorhsUlJzMstSi/TtErgyLj3bylywXqli37IO9gbGVTJdjJwcEgImEtd+ 7GPuYuTiEBLYzShxe94V9i5GDrBE/28fiPgORon5X36xgjTwCghK/Jh8jwWkhllAXuLgeVmQ MLOAlsT3R60sEPUTmCRWdb8DqxEWkJDYvCcRpEZYQF9i5ZlOdhCbTUBF4vi3DcwgNqeAvcSr /8vBxrMIqEp03lvEAjFTWmLpt8mMEGttJB6euc8GYgsJFEs8OzETLC4CVN/deIkd4hdZiZVP N7JC2D1sEvNma09gFJ6F5OpZCFfPQnL1AkbmVYziuYmZObqZeUZ6icWZiXqJBQU5qXrJ+bmb GMGh/Y9tB+OC14aHGAU4GJV4eNX+aUcIsSaWFVfmHmKU4GBWEuFdwqwTIcSbklhZlVqUH19U mpNafIhRmoNFSZxXI2t7uJBAemJJanZqakFqEUyWiYNTqoExxemHrgSr3eO+w+s0uDcVy0/l exWiazS3vCvlWL777E1ON1e8/+K8OOBszcx/AnUfmadIr9X6svJN+87rN3PtbH+cf/HFXb15 zXmbnN6/z27++ahat9hg7oa7iXM0LU883vjozPqzGntyPv9L6fH59Mv0w8f/8UcLGCy3ynEs P+v1f/rRpPpHiUosxRmJhlrMRcWJALcuyzBpAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUiGBJgp/uFTSfC4PE2XYuNLe/YLO7EODB5 LFnyk8njyf6ZLAFMUVw2Kak5mWWpRfp2CVwZl55tZS5Yr1Sxb1kHewPjKpkuRg4OCQETif7f Pl2MXBxCAjsYJeZ/+cXaxcjJwSsgKPFj8j0WkBpmAXmJg+dlQcLMAloS3x+1skDUT2CSWNX9 DqxGWEBCYvOeRJAaYQF9iZVnOtlBbDYBFYnj3zYwg9icAvYSr/4vBxvPIqAq0XlvEQvETGmJ pd8mM0KstZF4eOY+G4gtJFAs8ezETLC4CFB9d+MlsJkSArISK59uZJ3AKDALyaWzEC6dheTS BYzMqxhFi1JzEisN9RKLMxP1EgsKclL1kvNzNzGCgjHohNAOxo/7DQ4xCnAwKvHwdv3TjhBi TSwrrsw9xCjBwawkwruEWSdCiDclsbIqtSg/vqg0J7X4EKM0B4uSOG/O44/hQgLpiSWp2amp BalFMFkmDk6pBkZ5rSlNjxb+EOafzWjUveaTaNvywhMOp56oBVUcVNv+/rNN+6vGpxHiBX+W r136+vEUJzddtceLj0u/ehv0MI/3131jiTk6FiINple8+/X9l0Q5mOw18Hb4lsqxdh73vC85 HSKv7Dc9PKcmfbZ67ymtKZcEcmdsuVT27CSbYOt1h8mPvLITTkQqsRRnJBpqMRcVJwIA2oRl bEICAAA= Archived-At: Cc: taps WG Subject: Re: [Taps] draft-trammell-post-sockets X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 07:12:57 -0000 Based on the discussions we had with several folks after the meeting, the feeling was that the some of the Post Sockets API approach probably was in scope for the third item of the TAPS charter. Here's that item for reference: "3) Specify experimental support mechanisms to provide the Transport Services identified in work item 2. This document will explain how to select and engage an appropriate protocol and how to discover which protocols are available for the selected service between a given pair of end points. Further, it will provide a basis for incremental deployment. Work on this document will begin when the TAPS Transport Services have been specified." Here's my take for why the post-sockets effort is in scope: 1. I believe that choosing the correct path/protocol stack for a connection, taking into account both client preferences and system policy, requires some API support beyond a socket. We need several things beyond traditional sockets. One is to allow for multipath and fast-open semantics, which can be shimmed onto sockets, but require significant changes that make them incompatible with traditional adopters. Another aspect is the point I brought up in my presentation today: we need support for multiple options that may be attempted and selected (between protocols, interfaces, and endpoints), and this more complex setup is not compatible with a single-five-tuple single-interface socket abstraction. These requirements seem important for "how to select and engage an appropriate protocol", which is in the charter. 2. The charter mentions that the third phase "will provide a basis for incremental deployment". If I try to imagine how we can allow new protocol development to provide functionality in a non-disruptive manner, it seems most tractable to (a) define an API layer that provides the minimal subset in a way that is compatible both with existing deployments and future goals; (b) move clients to adopt said API layer as a common abstraction; and (c) incrementally add more logic for protocol selection and modifications underneath this stable level. This is the approach we've taken in our deployments, and it has worked well for enabling new features. If Post Sockets is the correct expression of the minimal subset that can lift up the API and allow TAPS to add more smarts to the stack, it would seem we would have addressed the work item. The work TAPS has done so far to catalog the protocol options we see in existing transports is (while tedious) very important, and I think leads to the conclusion that a carefully considered API is required to go forward. I am concerned that if we do not aggressively and creatively try to minimize and unify the interfaces applications use for networking, we will end up with still more ossification of the stack. Today, things are ossified around TCP when applications use sockets. If we simply add options for the features we think should be added for TAPS, we still end in ossification if it boils down to "all apps that use the API in a certain manner always get protocol A". I hope that with an architecture like Post Sockets, we can distill the essential patterns of communication between endpoints so far that they can indeed grow along with future network protocol innovations. Thanks, Tommy > On Nov 16, 2016, at 10:48 AM, Brian Trammell wrote: > > Hi, all, > > Looking at where we are in the agenda, we're not going to get to talk about Post Sockets in the meeting in Seoul today. As most of the properties of the API are already being discussed during Colin's presentation, this isn't that big a deal. However, if anyone who has read draft-trammell-post-sockets would like to talk to us about it here in Seoul, please drop me a line. > > To answer Zahed's question at the beginning of the meeting: we didn't call this draft-trammell-taps-post-sockets because it's not clear that it's really in scope for TAPS. It presents a radically changed replacement in the abstract for the sockets API. However, if the working group is interested in continuing to discuss it, we're happy to resubmit as draft-trammell-taps-post-sockets if it makes things easier to follow. :) > > Cheers, > > Brian > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed Nov 16 00:25:56 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5F512969D for ; Wed, 16 Nov 2016 00:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHsZl06yLu9W for ; Wed, 16 Nov 2016 00:25:51 -0800 (PST) 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 87D74129684 for ; Wed, 16 Nov 2016 00:25:51 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1c6vXR-0003hx-KO; Wed, 16 Nov 2016 09:25:49 +0100 Received: from dhcp-8409.meeting.ietf.org ([31.133.132.9]) by mail-mx1.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.80) (envelope-from ) id 1c6vXQ-0003PT-2q; Wed, 16 Nov 2016 09:25:49 +0100 From: Michael Welzl Message-Id: <7C786242-DCAF-4E5D-B554-646DB3218972@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_C1DDADE1-1913-4110-BDD7-D299F7A11C80" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Wed, 16 Nov 2016 17:25:42 +0900 In-Reply-To: To: Dave Dolson References: X-Mailer: Apple Mail (2.3251) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 12 msgs/h 6 sum rcpts/h 13 sum msgs/h 6 total rcpts 48831 max rcpts/h 54 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: 1EFE4D9007ADB130263B8D2163AADF6817367149 X-UiO-SPAM-Test: UIO-GREYLIST remote_host: 31.133.132.9 spam_score: -49 maxlevel 80 minaction 1 bait 0 mail/h: 4 total 27 max/h 6 blacklist 0 greylist 1 ratelimit 0 Archived-At: Cc: "tuexen@fh-muenster.de" , " Khademi" , "taps@ietf.org" Subject: Re: [Taps] on draft-ietf-taps-transports-usage-02 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 08:25:54 -0000 --Apple-Mail=_C1DDADE1-1913-4110-BDD7-D299F7A11C80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Including the TAPS list by permission of Dave: > On Nov 16, 2016, at 10:18 AM, Dave Dolson = wrote: >=20 > Michael, > I=E2=80=99m not sure you understood my question from the mic. > I was trying to ask about the facility provided by IP_BINDANY option. > (e.g., described here: http://www.unix.com/man-page/freebsd/4/ip/ = ) Thanks! I wasn=E2=80=99t aware about this functionality - indeed when = you talked about =E2=80=9Cbinding to any=E2=80=9D I assumed you mean = opening a connection to listen on all interfaces. (there are some subtle differences there - TCP, SCTP and UDP(-Lite) = allow to listen on 1 or all interfaces, but TCP doesn=E2=80=99t allow to = listen on a specific subset ( > 1) of interfaces, at least according to = the spec). =20 > I=E2=80=99m guessing you would not include it because it isn=E2=80=99t = implemented on all systems, but I wanted to clarify. No, we wouldn=E2=80=99t include this, but not because it=E2=80=99s not = available everywhere but because it=E2=80=99s not a part of the TCP RFCs = (unless I missed it! I=E2=80=99d love to be pointed at it in this = case!). As I said, I think this is the right time to start collecting things to = discuss in an appendix: cool functions that people like but are not a = part of the TCPs. This one could go in there - if you could offer me a = very short description (approx 2-3 sentences is enough), that would be = perfect. = =20 > Also, I=E2=80=99m wondering about whether supporting IPv4 and IPv6 = should be mentioned? > I=E2=80=99m particularly fond of support for the IPv4-mapped-IPv6 = address described here: = https://tools.ietf.org/html/rfc4291#section-2.5.5.2 = We base this off current protocols, which all talk about addresses and = not about v4 vs. v6. On a related note, in TAPS BOFs, several persons expressed their wish to = =E2=80=9Cgo all the way=E2=80=9D and abstract away IP addresses just as = well. I like this idea very much, but we didn=E2=80=99t do this back = then as we were trying to keep things narrow enough to get the group off = the ground. So now it=E2=80=99s not a part of the charter, and not a = part of the documents=E2=80=A6 but, e.g., our implementation in the NEAT = project lets you connect to a name, not an address. Maybe a hint in this direction could be included in one of the docs = about the third item. Cheers, Michael --Apple-Mail=_C1DDADE1-1913-4110-BDD7-D299F7A11C80 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Including the TAPS list by permission of Dave:


On = Nov 16, 2016, at 10:18 AM, Dave Dolson <ddolson@sandvine.com> wrote:

Michael,

I=E2=80=99m not sure you = understood my question from the mic.

I was trying to ask about the facility provided by = IP_BINDANY option.

(e.g., = described here: = http://www.unix.com/man-page/freebsd/4/ip/)


Thanks!  I wasn=E2=80=99t aware = about this functionality - indeed when you talked about =E2=80=9Cbinding = to any=E2=80=9D I assumed you mean opening a connection to listen on all = interfaces.
(there are some subtle differences there - TCP, = SCTP and UDP(-Lite) allow to listen on 1 or all interfaces, but TCP = doesn=E2=80=99t allow to listen on a specific subset ( > 1) of = interfaces, at least according to the spec).

 

I=E2=80=99m guessing you would not include it = because it isn=E2=80=99t implemented on all systems, but I wanted to = clarify.


No, we = wouldn=E2=80=99t include this, but not because it=E2=80=99s not = available everywhere but because it=E2=80=99s not a part of the TCP RFCs =  (unless I missed it!  I=E2=80=99d love to be pointed at it in = this case!).

As I said, I think this = is the right time to start collecting things to discuss in an appendix: = cool functions that people like but are not a part of the TCPs. This one = could go in there - if you could offer me a very short description = (approx 2-3 sentences is enough), that would be perfect.

      =                     =                     =                     =                     =            

Also,= I=E2=80=99m wondering about whether supporting IPv4 and IPv6 should be = mentioned?

I=E2=80=99m = particularly fond of support for the IPv4-mapped-IPv6 address described = here: https://tools.ietf.org/html/rfc4291#section-2.5.5.2


We base = this off current protocols, which all talk about addresses and not about = v4 vs. v6.

On = a related note, in TAPS BOFs, several persons expressed their wish to = =E2=80=9Cgo all the way=E2=80=9D and abstract away IP addresses just as = well. I like this idea very much, but we didn=E2=80=99t do this back = then as we were trying to keep things narrow enough to get the group off = the ground. So now it=E2=80=99s not a part of the charter, and not a = part of the documents=E2=80=A6 but, e.g., our implementation in the NEAT = project lets you connect to a name, not an address.

Maybe a hint in this = direction could be included in one of the docs about the third = item.

Cheers,
Michael

= --Apple-Mail=_C1DDADE1-1913-4110-BDD7-D299F7A11C80-- From nobody Wed Nov 16 01:25:51 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4225A129472 for ; Wed, 16 Nov 2016 01:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.686 X-Spam-Level: X-Spam-Status: No, score=-5.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYW1es5Tdt7W for ; Wed, 16 Nov 2016 01:25:46 -0800 (PST) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B65E12954A for ; Wed, 16 Nov 2016 01:25:46 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1c6wTQ-0005OZ-H1 for taps@ietf.org; Wed, 16 Nov 2016 10:25:44 +0100 Received: from dhcp-8409.meeting.ietf.org ([31.133.132.9]) by mail-mx4.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.80) (envelope-from ) id 1c6wTO-0004H0-9W; Wed, 16 Nov 2016 10:25:44 +0100 From: Michael Welzl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E842DA82-BF8E-4453-A522-EA388BB09AD9" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Wed, 16 Nov 2016 18:25:35 +0900 In-Reply-To: To: Tommy Pauly References: <4985BCB5-45E5-496C-BCDD-6C6DE62C0712@trammell.ch> X-Mailer: Apple Mail (2.3251) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 5 msgs/h 3 sum rcpts/h 18 sum msgs/h 9 total rcpts 48851 max rcpts/h 54 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: 70EE78BFEF8C32EC25FAB9F17AF07F6B4F007E44 X-UiO-SPAM-Test: remote_host: 31.133.132.9 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 36 max/h 10 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Brian Trammell , "taps@ietf.org" Subject: Re: [Taps] draft-trammell-post-sockets X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 09:25:49 -0000 --Apple-Mail=_E842DA82-BF8E-4453-A522-EA388BB09AD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tommy, Being part of the discussions after the meeting, I completely agree. = However, to me, saying X matches charter item Y is rather premature at = this stage. This draft presents a few services, which, as was discussed during the = meeting, 1) overlap quite a lot with draft-mcquistin-taps-low-latency-services = (good!). 2) match very nicely to the services we already have in e.g. the minset = draft (good!). (with some small differences that we also discussed - one being message = dependencies). I see this draft as very good input but I=E2=80=99d like to do things = one by one. As you know I also agree with this statement of yours: "I am concerned that if we do not aggressively and creatively try to = minimize and unify the interfaces applications use for networking, we = will end up with still more ossification of the stack=E2=80=9D so yes, this will definitely happen, but it=E2=80=99s clearly part of = charter item 2, and here this (and the other) draft are great input! However, while an API can be part of item 3, the relationship to item 3 = all in all isn=E2=80=99t so clear: the draft does not really address = much of what item 3 says. It doesn't explain much along the lines of = selecting and engaging a protocol; it doesn=E2=80=99t explain how = incremental deployment will work; it doesn=E2=80=99t explain how to = discover which protocols are available for the selected service. Again, I=E2=80=99m not saying an API (which is part of what this draft = provides) is out of scope of item 3, but then item 3 should probably be = approximately 3 drafts (I also have nothing against that :) but this = is not my decision). It=E2=80=99s just that there=E2=80=99s a LOT still = missing here, so let=E2=80=99s not jump the gun and do things step by = step, as the charter also prescribes: "Work on this document will begin = when the TAPS Transport Services have been specified." Let me be clear, with =E2=80=9Cstep by step=E2=80=9D I=E2=80=99m by no = means saying we should slow things down - and as I said before I see a = lot of value in this draft! My concern is just about mapping drafts to charter items. Very useful input, yes; in scope of charter item 3: maybe, to some = degree, but at this point more useful as input to item 2 IMO. Cheers, Michael > On Nov 16, 2016, at 4:12 PM, Tommy Pauly wrote: >=20 > Based on the discussions we had with several folks after the meeting, = the feeling was that the some of the Post Sockets API approach probably = was in scope for the third item of the TAPS charter. >=20 > Here's that item for reference: >=20 > "3) Specify experimental support mechanisms to provide the Transport=20= > Services identified in work item 2. This document will explain=20 > how to select and engage an appropriate protocol and how to=20 > discover which protocols are available for the selected service=20 > between a given pair of end points. Further, it will provide a=20 > basis for incremental deployment. Work on this document will=20 > begin when the TAPS Transport Services have been specified." >=20 > Here's my take for why the post-sockets effort is in scope: >=20 > 1. I believe that choosing the correct path/protocol stack for a = connection, taking into account both client preferences and system = policy, requires some API support beyond a socket. We need several = things beyond traditional sockets. One is to allow for multipath and = fast-open semantics, which can be shimmed onto sockets, but require = significant changes that make them incompatible with traditional = adopters. Another aspect is the point I brought up in my presentation = today: we need support for multiple options that may be attempted and = selected (between protocols, interfaces, and endpoints), and this more = complex setup is not compatible with a single-five-tuple = single-interface socket abstraction. These requirements seem important = for "how to select and engage an appropriate protocol", which is in the = charter. >=20 > 2. The charter mentions that the third phase "will provide a basis for = incremental deployment". If I try to imagine how we can allow new = protocol development to provide functionality in a non-disruptive = manner, it seems most tractable to (a) define an API layer that provides = the minimal subset in a way that is compatible both with existing = deployments and future goals; (b) move clients to adopt said API layer = as a common abstraction; and (c) incrementally add more logic for = protocol selection and modifications underneath this stable level. This = is the approach we've taken in our deployments, and it has worked well = for enabling new features. If Post Sockets is the correct expression of = the minimal subset that can lift up the API and allow TAPS to add more = smarts to the stack, it would seem we would have addressed the work = item. >=20 > The work TAPS has done so far to catalog the protocol options we see = in existing transports is (while tedious) very important, and I think = leads to the conclusion that a carefully considered API is required to = go forward. I am concerned that if we do not aggressively and creatively = try to minimize and unify the interfaces applications use for = networking, we will end up with still more ossification of the stack. = Today, things are ossified around TCP when applications use sockets. If = we simply add options for the features we think should be added for = TAPS, we still end in ossification if it boils down to "all apps that = use the API in a certain manner always get protocol A". I hope that with = an architecture like Post Sockets, we can distill the essential patterns = of communication between endpoints so far that they can indeed grow = along with future network protocol innovations. >=20 > Thanks, > Tommy >=20 >> On Nov 16, 2016, at 10:48 AM, Brian Trammell = wrote: >>=20 >> Hi, all, >>=20 >> Looking at where we are in the agenda, we're not going to get to talk = about Post Sockets in the meeting in Seoul today. As most of the = properties of the API are already being discussed during Colin's = presentation, this isn't that big a deal. However, if anyone who has = read draft-trammell-post-sockets would like to talk to us about it here = in Seoul, please drop me a line. >>=20 >> To answer Zahed's question at the beginning of the meeting: we didn't = call this draft-trammell-taps-post-sockets because it's not clear that = it's really in scope for TAPS. It presents a radically changed = replacement in the abstract for the sockets API. However, if the working = group is interested in continuing to discuss it, we're happy to resubmit = as draft-trammell-taps-post-sockets if it makes things easier to follow. = :) >>=20 >> Cheers, >>=20 >> Brian >>=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=_E842DA82-BF8E-4453-A522-EA388BB09AD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Tommy,

Being part of the discussions after the meeting, I completely = agree. However, to me, saying X matches charter item Y is rather = premature at this stage.

This draft presents a few services, which, as was discussed = during the meeting,
1) overlap quite a lot = with draft-mcquistin-taps-low-latency-services =  (good!).
2) match very = nicely to the services we already have in e.g. the minset draft =  (good!).
(with some = small differences that we also discussed - one being message = dependencies).


I see this draft as very = good input but I=E2=80=99d like to do things one by = one.
As you know I also agree with this = statement of yours:

"I am concerned that = if we do not aggressively and creatively try to minimize and unify the = interfaces applications use for networking, we will end up with still = more ossification of the stack=E2=80=9D

so yes, this will definitely happen, = but it=E2=80=99s clearly part of charter item 2, and here this (and the = other) draft are great input!

However, while an API can be part of = item 3, the relationship to item 3 all in all isn=E2=80=99t so clear: = the draft does not really address much of what item 3 says. It doesn't = explain much along the lines of selecting and engaging a protocol; it = doesn=E2=80=99t explain how incremental deployment will work; it = doesn=E2=80=99t explain how to discover which protocols are available = for the selected service.

Again, I=E2=80=99m not saying an API (which is part of what = this draft provides) is out of scope of item 3, but then item 3 should = probably be approximately 3 drafts (I also have nothing against that =  :)  but this is not my decision). It=E2=80=99s just that = there=E2=80=99s a LOT still missing here, so let=E2=80=99s not jump the = gun and do things step by step, as the charter also prescribes: "Work on = this document will begin when the TAPS Transport Services have been = specified."

Let = me be clear, with =E2=80=9Cstep by step=E2=80=9D I=E2=80=99m by no means = saying we should slow things down - and as I said before I see a lot of = value in this draft!
My concern is just about = mapping drafts to charter items.

Very useful input, yes; in scope of = charter item 3: maybe, to some degree, but at this point more useful as = input to item 2 IMO.

Cheers,
Michael


On Nov 16, 2016, at 4:12 PM, = Tommy Pauly <tpauly@apple.com> wrote:

Based = on the discussions we had with several folks after the meeting, the = feeling was that the some of the Post Sockets API approach probably was = in scope for the third item of the TAPS charter.

Here's that item for reference:

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

Here's my take for why the post-sockets effort is in = scope:

1. I believe that choosing the = correct path/protocol stack for a connection, taking into account both = client preferences and system policy, requires some API support beyond a = socket. We need several things beyond traditional sockets. One is to = allow for multipath and fast-open semantics, which can be shimmed onto = sockets, but require significant changes that make them incompatible = with traditional adopters. Another aspect is the point I brought up in = my presentation today: we need support for multiple options that may be = attempted and selected (between protocols, interfaces, and endpoints), = and this more complex setup is not compatible with a single-five-tuple = single-interface socket abstraction. These requirements seem important = for "how to select and engage an appropriate protocol", which is in the = charter.

2. The charter mentions that the = third phase "will provide a basis for incremental deployment". If I try = to imagine how we can allow new protocol development to provide = functionality in a non-disruptive manner, it seems most tractable to (a) = define an API layer that provides the minimal subset in a way that is = compatible both with existing deployments and future goals; (b) move = clients to adopt said API layer as a common abstraction; and (c) = incrementally add more logic for protocol selection and modifications = underneath this stable level. This is the approach we've taken in our = deployments, and it has worked well for enabling new features. If Post = Sockets is the correct expression of the minimal subset that can lift up = the API and allow TAPS to add more smarts to the stack, it would seem we = would have addressed the work item.

The = work TAPS has done so far to catalog the protocol options we see in = existing transports is (while tedious) very important, and I think leads = to the conclusion that a carefully considered API is required to go = forward. I am concerned that if we do not aggressively and creatively = try to minimize and unify the interfaces applications use for = networking, we will end up with still more ossification of the stack. = Today, things are ossified around TCP when applications use sockets. If = we simply add options for the features we think should be added for = TAPS, we still end in ossification if it boils down to "all apps that = use the API in a certain manner always get protocol A". I hope that with = an architecture like Post Sockets, we can distill the essential patterns = of communication between endpoints so far that they can indeed grow = along with future network protocol innovations.

Thanks,
Tommy

On Nov 16, 2016, at = 10:48 AM, Brian Trammell <ietf@trammell.ch> wrote:

Hi, all,

Looking at where we are = in the agenda, we're not going to get to talk about Post Sockets in the = meeting in Seoul today. As most of the properties of the API are already = being discussed during Colin's presentation, this isn't that big a deal. = However, if anyone who has read draft-trammell-post-sockets would like = to talk to us about it here in Seoul, please drop me a line.

To answer Zahed's question at the beginning of = the meeting: we didn't call this draft-trammell-taps-post-sockets = because it's not clear that it's really in scope for TAPS. It presents a = radically changed replacement in the abstract for the sockets API. = However, if the working group is interested in continuing to discuss it, = we're happy to resubmit as draft-trammell-taps-post-sockets if it makes = things easier to follow. :)

Cheers,

Brian

_______________________________________________
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=_E842DA82-BF8E-4453-A522-EA388BB09AD9-- From nobody Wed Nov 16 02:07:20 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB9A1296D2 for ; Wed, 16 Nov 2016 02:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.787 X-Spam-Level: X-Spam-Status: No, score=-5.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvYUhxGtSPTQ for ; Wed, 16 Nov 2016 02:07:17 -0800 (PST) Received: from mail-in2.asia.apple.com (mail-out.asia.apple.com [17.82.254.64]) (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 87457129664 for ; Wed, 16 Nov 2016 02:07:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1479290786; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=uc+4l9x9HN0XDbYoyiDC91+HaATILF1OypFGbqs4mJU=; b=DEso+SCkI5fO1LPjVmUbotKsmGz+KfLSb9YXtO0mq/eOM35YKloh7xEiWbE52FVy 1wOza31UtUjVieoWasccoIBK6W8S+Jp5ASYA+v7EL7sXWbsXbyGbox3ERkDNnH6j h88UK/fIHHqFLIDvCrKL55oBFbfBP4v9kBL6HrUD8LJPBr2o8z1p+EkkWo7Nht5N fSb36l5eH5UPZ7t77v+PA9H/1Ls7shQJHenCY36TCTAlczPs5eOcm8v9zl2daXUf qF2NCXoGDTbWOrXLDYG58D8sIYmuF/ZAidoC6HNrNtWX+DLFJ5OjFYxav7BHxbt6 q4kRRD34dh0H10GzR/1n2A==; Received: from relay3.asia.apple.com ( [17.82.200.17]) by mail-in2.asia.apple.com (Apple Singapore Mail Gateway) with SMTP id 84.17.24048.2AF2C285; Wed, 16 Nov 2016 18:06:26 +0800 (MYT) X-AuditID: 1152fe06-ac30b9a000005df0-19-582c2fa2feb4 Received: from sng-mmpp-sz01.asia.apple.com ( [17.84.80.62]) by relay3.asia.apple.com (Apple Singapore relay) with SMTP id 47.1E.16365.0DF2C285; Wed, 16 Nov 2016 18:07:12 +0800 (MYT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_IDMDMJrrzXLzc6VxNc9eIA)" Received: from [17.83.168.3] (unknown [17.83.168.3]) by sng-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OGQ00F8JC3RGE70@sng-mmpp-sz01.asia.apple.com>; Wed, 16 Nov 2016 18:07:09 +0800 (SGT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Wed, 16 Nov 2016 19:07:01 +0900 In-reply-to: To: Michael Welzl References: <4985BCB5-45E5-496C-BCDD-6C6DE62C0712@trammell.ch> X-Mailer: Apple Mail (2.3252) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUiGHRCUHeRvk6Ewb0F5hYbW96xWfw4u5PV 4k6MA7PHkiU/mTxWr37I7PFk/0yWAOYoLpuU1JzMstQifbsEroy2VS+YC14uZKzoaOlgamD8 1sbYxcjJISFgIjGv5yVbFyMXh5DAbkaJVxuOwCVuLL3MApHYwSix7M0qFpAEr4CgxI/J98Bs ZoEwiW+LfjJDFE1gktjwZhprFyMHh7CAhMTmPYkgNWwCKhLHv21gBgnzCthInJvkDhIWFtCX WHmmkx3EZhFQlXjcMANsL6eAncSN9R3sIOXMAm4SV1+AhUUE1CROLF8NdectRokv+88zQ9wp K7Hy6UZWkISEwAY2iXeHDzJNYBSaheTUWUhOnQU2V11iypRciLC2xJN3F1ghbDWJhb8XMSGL L2BkW8UonpuYmaObmWekl1icmaiXWFCQk6qXnJ+7iREcJ//YdjAueG14iFGAg1GJh/eBqE6E EGtiWXFl7iFGCQ5mJRFeTj2gEG9KYmVValF+fFFpTmrxIUZpDhYlcV6NrO3hQgLpiSWp2amp BalFMFkmDk6pBkYLLslX+fWskj1Ry925a/LCP00JdcgtqdBYeqP6Qcmjc8uMzqWuyG3daral u+2kq+TLVdfOtu9OriwJZE3YIrWTQbOfiUPER+b+s22BPDbuCqJKiTd0U4OEk5WuCYT78Ty/ +S5ObuP5KeXftQuz31wIFm7UX6wXop1vJ2zTyLs8YZ23vkOdEktxRqKhFnNRcSIA37Z+jY8C AAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUiGBJgp3tBXyfCYNkJZYuNLe/YLH6c3clq cSfGgdljyZKfTB6rVz9k9niyfyZLAHMUl01Kak5mWWqRvl0CV0bbqhfMBS8XMlZ0tHQwNTB+ a2PsYuTkkBAwkbix9DJLFyMXh5DADkaJZW9WsYAkeAUEJX5MvgdmMwuESXxb9JMZomgCk8SG N9NYuxg5OIQFJCQ270kEqWETUJE4/m0DM0iYV8BG4twkd5CwsIC+xMoznewgNouAqsTjhhlg ezkF7CRurO9gBylnFnCTuPoCLCwioCZxYvlqNohNtxglvuw/zwxxp6zEyqcbWScw8s9Cct0s JNfNAhulLjFlSi5EWFviybsLrBC2msTC34uYkMUXMLKtYhQtSs1JrDTWSyzOTNRLLCjISdVL zs/dxAgK66ATgjsYP0w1PMQowMGoxMPLL6YTIcSaWFZcmXuIUYKDWUmEl1MPKMSbklhZlVqU H19UmpNafIhRmoNFSZw35/HHcCGB9MSS1OzU1ILUIpgsEwenVAPjUibVuffqQ49GrfCyXn8k t27bwnDeJe6vIgW/NHXEd37vneO6QGk6y54tC9eZnNm4KERq61tF+6IDzGkvEua1+U/cHfbJ /Oo2kfj+OasPnj78aF6n3xvNttWylR2qNvN89KsXHOBK2s937MmB1BrHRXnre+ZeYTO5ZXJy gZ/mxkPGu3O27XhxQImlOCPRUIu5qDgRAHU7lERnAgAA Archived-At: Cc: Brian Trammell , "taps@ietf.org" Subject: Re: [Taps] draft-trammell-post-sockets X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 10:07:19 -0000 --Boundary_(ID_IDMDMJrrzXLzc6VxNc9eIA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Michael, I definitely agree that the current Post draft is not the fulfillment of = the charter item 3. My point was that it is not necessarily out of = scope, and the work it is looking into may very well be a necessary part = of satisfying the charter. I had read the second charter item as listing out the pieces of = functionality that are required for TAPS to provide, rather than how = these pieces should be exposed. Perhaps the API work is somewhere split = between 2 and 3? I can certainly see it either way. Another point is that the Post draft is still in quite early stages. As = discussed today, I'd like to write up the approach I presented today as = a draft, and that could get folded into Post, since I think it requires = a Post-style API in order to be used. I think there is a lot of detail = yet to add about how to select and use protocols and paths and options = internally to the connection implementation. Thanks! Tommy > On Nov 16, 2016, at 6:25 PM, Michael Welzl wrote: >=20 > Hi Tommy, >=20 > Being part of the discussions after the meeting, I completely agree. = However, to me, saying X matches charter item Y is rather premature at = this stage. >=20 > This draft presents a few services, which, as was discussed during the = meeting, > 1) overlap quite a lot with draft-mcquistin-taps-low-latency-services = (good!). > 2) match very nicely to the services we already have in e.g. the = minset draft (good!). > (with some small differences that we also discussed - one being = message dependencies). >=20 >=20 > I see this draft as very good input but I=E2=80=99d like to do things = one by one. > As you know I also agree with this statement of yours: >=20 > "I am concerned that if we do not aggressively and creatively try to = minimize and unify the interfaces applications use for networking, we = will end up with still more ossification of the stack=E2=80=9D >=20 > so yes, this will definitely happen, but it=E2=80=99s clearly part of = charter item 2, and here this (and the other) draft are great input! >=20 > However, while an API can be part of item 3, the relationship to item = 3 all in all isn=E2=80=99t so clear: the draft does not really address = much of what item 3 says. It doesn't explain much along the lines of = selecting and engaging a protocol; it doesn=E2=80=99t explain how = incremental deployment will work; it doesn=E2=80=99t explain how to = discover which protocols are available for the selected service. >=20 > Again, I=E2=80=99m not saying an API (which is part of what this draft = provides) is out of scope of item 3, but then item 3 should probably be = approximately 3 drafts (I also have nothing against that :) but this = is not my decision). It=E2=80=99s just that there=E2=80=99s a LOT still = missing here, so let=E2=80=99s not jump the gun and do things step by = step, as the charter also prescribes: "Work on this document will begin = when the TAPS Transport Services have been specified." >=20 > Let me be clear, with =E2=80=9Cstep by step=E2=80=9D I=E2=80=99m by no = means saying we should slow things down - and as I said before I see a = lot of value in this draft! > My concern is just about mapping drafts to charter items. >=20 > Very useful input, yes; in scope of charter item 3: maybe, to some = degree, but at this point more useful as input to item 2 IMO. >=20 > Cheers, > Michael >=20 >=20 >> On Nov 16, 2016, at 4:12 PM, Tommy Pauly > wrote: >>=20 >> Based on the discussions we had with several folks after the meeting, = the feeling was that the some of the Post Sockets API approach probably = was in scope for the third item of the TAPS charter. >>=20 >> Here's that item for reference: >>=20 >> "3) Specify experimental support mechanisms to provide the Transport=20= >> Services identified in work item 2. This document will explain=20 >> how to select and engage an appropriate protocol and how to=20 >> discover which protocols are available for the selected service=20 >> between a given pair of end points. Further, it will provide a=20 >> basis for incremental deployment. Work on this document will=20 >> begin when the TAPS Transport Services have been specified." >>=20 >> Here's my take for why the post-sockets effort is in scope: >>=20 >> 1. I believe that choosing the correct path/protocol stack for a = connection, taking into account both client preferences and system = policy, requires some API support beyond a socket. We need several = things beyond traditional sockets. One is to allow for multipath and = fast-open semantics, which can be shimmed onto sockets, but require = significant changes that make them incompatible with traditional = adopters. Another aspect is the point I brought up in my presentation = today: we need support for multiple options that may be attempted and = selected (between protocols, interfaces, and endpoints), and this more = complex setup is not compatible with a single-five-tuple = single-interface socket abstraction. These requirements seem important = for "how to select and engage an appropriate protocol", which is in the = charter. >>=20 >> 2. The charter mentions that the third phase "will provide a basis = for incremental deployment". If I try to imagine how we can allow new = protocol development to provide functionality in a non-disruptive = manner, it seems most tractable to (a) define an API layer that provides = the minimal subset in a way that is compatible both with existing = deployments and future goals; (b) move clients to adopt said API layer = as a common abstraction; and (c) incrementally add more logic for = protocol selection and modifications underneath this stable level. This = is the approach we've taken in our deployments, and it has worked well = for enabling new features. If Post Sockets is the correct expression of = the minimal subset that can lift up the API and allow TAPS to add more = smarts to the stack, it would seem we would have addressed the work = item. >>=20 >> The work TAPS has done so far to catalog the protocol options we see = in existing transports is (while tedious) very important, and I think = leads to the conclusion that a carefully considered API is required to = go forward. I am concerned that if we do not aggressively and creatively = try to minimize and unify the interfaces applications use for = networking, we will end up with still more ossification of the stack. = Today, things are ossified around TCP when applications use sockets. If = we simply add options for the features we think should be added for = TAPS, we still end in ossification if it boils down to "all apps that = use the API in a certain manner always get protocol A". I hope that with = an architecture like Post Sockets, we can distill the essential patterns = of communication between endpoints so far that they can indeed grow = along with future network protocol innovations. >>=20 >> Thanks, >> Tommy >>=20 >>> On Nov 16, 2016, at 10:48 AM, Brian Trammell > wrote: >>>=20 >>> Hi, all, >>>=20 >>> Looking at where we are in the agenda, we're not going to get to = talk about Post Sockets in the meeting in Seoul today. As most of the = properties of the API are already being discussed during Colin's = presentation, this isn't that big a deal. However, if anyone who has = read draft-trammell-post-sockets would like to talk to us about it here = in Seoul, please drop me a line. >>>=20 >>> To answer Zahed's question at the beginning of the meeting: we = didn't call this draft-trammell-taps-post-sockets because it's not clear = that it's really in scope for TAPS. It presents a radically changed = replacement in the abstract for the sockets API. However, if the working = group is interested in continuing to discuss it, we're happy to resubmit = as draft-trammell-taps-post-sockets if it makes things easier to follow. = :) >>>=20 >>> Cheers, >>>=20 >>> Brian >>>=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 --Boundary_(ID_IDMDMJrrzXLzc6VxNc9eIA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
Hi Michael,

I definitely agree that the current = Post draft is not the fulfillment of the charter item 3. My point was = that it is not necessarily out of scope, and the work it is looking into = may very well be a necessary part of satisfying the charter.

I had read the second = charter item as listing out the pieces of functionality that are = required for TAPS to provide, rather than how these pieces should be = exposed. Perhaps the API work is somewhere split between 2 and 3? I can = certainly see it either way.

Another point is that the Post draft is = still in quite early stages. As discussed today, I'd like to write up = the approach I presented today as a draft, and that could get folded = into Post, since I think it requires a Post-style API in order to be = used. I think there is a lot of detail yet to add about how to select = and use protocols and paths and options internally to the connection = implementation.

Thanks!
Tommy

On = Nov 16, 2016, at 6:25 PM, Michael Welzl <michawe@ifi.uio.no> = wrote:

Hi Tommy,

Being part of the = discussions after the meeting, I completely agree. However, to me, = saying X matches charter item Y is rather premature at this = stage.

This = draft presents a few services, which, as was discussed during the = meeting,
1) overlap quite a lot with draft-mcquistin-taps-low-latency-services =  (good!).
2) match very nicely to the services we = already have in e.g. the minset draft  (good!).
(with= some small differences that we also discussed - one being message = dependencies).


I see this draft as very = good input but I=E2=80=99d like to do things one by = one.
As you know I also agree with this = statement of yours:

"I am concerned that = if we do not aggressively and creatively try to minimize and unify the = interfaces applications use for networking, we will end up with still = more ossification of the stack=E2=80=9D

so yes, this will definitely happen, = but it=E2=80=99s clearly part of charter item 2, and here this (and the = other) draft are great input!

However, while an API can be part of = item 3, the relationship to item 3 all in all isn=E2=80=99t so clear: = the draft does not really address much of what item 3 says. It doesn't = explain much along the lines of selecting and engaging a protocol; it = doesn=E2=80=99t explain how incremental deployment will work; it = doesn=E2=80=99t explain how to discover which protocols are available = for the selected service.

Again, I=E2=80=99m not saying an API (which is part of what = this draft provides) is out of scope of item 3, but then item 3 should = probably be approximately 3 drafts (I also have nothing against that =  :)  but this is not my decision). It=E2=80=99s just that = there=E2=80=99s a LOT still missing here, so let=E2=80=99s not jump the = gun and do things step by step, as the charter also prescribes: "Work on = this document will begin when the TAPS Transport Services have been = specified."

Let = me be clear, with =E2=80=9Cstep by step=E2=80=9D I=E2=80=99m by no means = saying we should slow things down - and as I said before I see a lot of = value in this draft!
My concern is just about = mapping drafts to charter items.

Very useful input, yes; in scope of = charter item 3: maybe, to some degree, but at this point more useful as = input to item 2 IMO.

Cheers,
Michael


On Nov = 16, 2016, at 4:12 PM, Tommy Pauly <tpauly@apple.com> wrote:

Based = on the discussions we had with several folks after the meeting, the = feeling was that the some of the Post Sockets API approach probably was = in scope for the third item of the TAPS charter.

Here's that item for reference:

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

Here's my take for why the post-sockets effort is in = scope:

1. I believe that choosing the = correct path/protocol stack for a connection, taking into account both = client preferences and system policy, requires some API support beyond a = socket. We need several things beyond traditional sockets. One is to = allow for multipath and fast-open semantics, which can be shimmed onto = sockets, but require significant changes that make them incompatible = with traditional adopters. Another aspect is the point I brought up in = my presentation today: we need support for multiple options that may be = attempted and selected (between protocols, interfaces, and endpoints), = and this more complex setup is not compatible with a single-five-tuple = single-interface socket abstraction. These requirements seem important = for "how to select and engage an appropriate protocol", which is in the = charter.

2. The charter mentions that the = third phase "will provide a basis for incremental deployment". If I try = to imagine how we can allow new protocol development to provide = functionality in a non-disruptive manner, it seems most tractable to (a) = define an API layer that provides the minimal subset in a way that is = compatible both with existing deployments and future goals; (b) move = clients to adopt said API layer as a common abstraction; and (c) = incrementally add more logic for protocol selection and modifications = underneath this stable level. This is the approach we've taken in our = deployments, and it has worked well for enabling new features. If Post = Sockets is the correct expression of the minimal subset that can lift up = the API and allow TAPS to add more smarts to the stack, it would seem we = would have addressed the work item.

The = work TAPS has done so far to catalog the protocol options we see in = existing transports is (while tedious) very important, and I think leads = to the conclusion that a carefully considered API is required to go = forward. I am concerned that if we do not aggressively and creatively = try to minimize and unify the interfaces applications use for = networking, we will end up with still more ossification of the stack. = Today, things are ossified around TCP when applications use sockets. If = we simply add options for the features we think should be added for = TAPS, we still end in ossification if it boils down to "all apps that = use the API in a certain manner always get protocol A". I hope that with = an architecture like Post Sockets, we can distill the essential patterns = of communication between endpoints so far that they can indeed grow = along with future network protocol innovations.

Thanks,
Tommy

On Nov 16, 2016, at = 10:48 AM, Brian Trammell <ietf@trammell.ch> wrote:

Hi, all,

Looking at where we are = in the agenda, we're not going to get to talk about Post Sockets in the = meeting in Seoul today. As most of the properties of the API are already = being discussed during Colin's presentation, this isn't that big a deal. = However, if anyone who has read draft-trammell-post-sockets would like = to talk to us about it here in Seoul, please drop me a line.

To answer Zahed's question at the beginning of = the meeting: we didn't call this draft-trammell-taps-post-sockets = because it's not clear that it's really in scope for TAPS. It presents a = radically changed replacement in the abstract for the sockets API. = However, if the working group is interested in continuing to discuss it, = we're happy to resubmit as draft-trammell-taps-post-sockets if it makes = things easier to follow. :)

Cheers,

Brian

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

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


= --Boundary_(ID_IDMDMJrrzXLzc6VxNc9eIA)-- From nobody Wed Nov 16 02:10:52 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6171296F3 for ; Wed, 16 Nov 2016 02:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.685 X-Spam-Level: X-Spam-Status: No, score=-5.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xgL-p9hxoVI for ; Wed, 16 Nov 2016 02:10:47 -0800 (PST) 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 42A821296BE for ; Wed, 16 Nov 2016 02:10:47 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1c6xAz-00008M-Mn for taps@ietf.org; Wed, 16 Nov 2016 11:10:45 +0100 Received: from dhcp-8183.meeting.ietf.org ([31.133.129.131]) by mail-mx1.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.80) (envelope-from ) id 1c6xAr-0007Ox-P4; Wed, 16 Nov 2016 11:10:45 +0100 Content-Type: multipart/alternative; boundary=Apple-Mail-DB68DEB3-4F13-4BDD-89EB-AA7C68A63290 Mime-Version: 1.0 (1.0) From: Michael Welzl X-Mailer: iPhone Mail (14B100) In-Reply-To: Date: Wed, 16 Nov 2016 19:10:26 +0900 Content-Transfer-Encoding: 7bit Message-Id: <8D1687FC-71CE-4D3A-92C5-2108A4C52BC8@ifi.uio.no> References: <4985BCB5-45E5-496C-BCDD-6C6DE62C0712@trammell.ch> To: Tommy Pauly X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 4 sum rcpts/h 17 sum msgs/h 11 total rcpts 48863 max rcpts/h 54 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: 846558A8EA541DDC0DD77DC53A068DE799F5712E X-UiO-SPAM-Test: remote_host: 31.133.129.131 spam_score: -49 maxlevel 80 minaction 2 bait 0 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: Brian Trammell , "taps@ietf.org" Subject: Re: [Taps] draft-trammell-post-sockets X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 10:10:50 -0000 --Apple-Mail-DB68DEB3-4F13-4BDD-89EB-AA7C68A63290 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable in line: Sent from my iPhone > On 16 Nov 2016, at 19:07, Tommy Pauly wrote: >=20 > Hi Michael, >=20 > I definitely agree that the current Post draft is not the fulfillment of t= he charter item 3. My point was that it is not necessarily out of scope, and= the work it is looking into may very well be a necessary part of satisfying= the charter. agree, >=20 > I had read the second charter item as listing out the pieces of functional= ity that are required for TAPS to provide, rather than how these pieces shou= ld be exposed. Perhaps the API work is somewhere split between 2 and 3? I ca= n certainly see it either way. yes that's what i mean - it offers good inout to both in fact > Another point is that the Post draft is still in quite early stages. As di= scussed today, I'd like to write up the approach I presented today as a draf= t, and that could get folded into Post, since I think it requires a Post-sty= le API in order to be used. I think there is a lot of detail yet to add abou= t how to select and use protocols and paths and options internally to the co= nnection implementation. sounds good to me! - note that there's also a draft on happy-eyeballing, no= t presented this time but still active cheers michael >=20 > Thanks! > Tommy >=20 >> On Nov 16, 2016, at 6:25 PM, Michael Welzl wrote: >>=20 >> Hi Tommy, >>=20 >> Being part of the discussions after the meeting, I completely agree. Howe= ver, to me, saying X matches charter item Y is rather premature at this stag= e. >>=20 >> This draft presents a few services, which, as was discussed during the me= eting, >> 1) overlap quite a lot with draft-mcquistin-taps-low-latency-services (g= ood!). >> 2) match very nicely to the services we already have in e.g. the minset d= raft (good!). >> (with some small differences that we also discussed - one being message d= ependencies). >>=20 >>=20 >> I see this draft as very good input but I=E2=80=99d like to do things one= by one. >> As you know I also agree with this statement of yours: >>=20 >> "I am concerned that if we do not aggressively and creatively try to mini= mize and unify the interfaces applications use for networking, we will end u= p with still more ossification of the stack=E2=80=9D >>=20 >> so yes, this will definitely happen, but it=E2=80=99s clearly part of cha= rter item 2, and here this (and the other) draft are great input! >>=20 >> However, while an API can be part of item 3, the relationship to item 3 a= ll in all isn=E2=80=99t so clear: the draft does not really address much of w= hat item 3 says. It doesn't explain much along the lines of selecting and en= gaging a protocol; it doesn=E2=80=99t explain how incremental deployment wil= l work; it doesn=E2=80=99t explain how to discover which protocols are avail= able for the selected service. >>=20 >> Again, I=E2=80=99m not saying an API (which is part of what this draft pr= ovides) is out of scope of item 3, but then item 3 should probably be approx= imately 3 drafts (I also have nothing against that :) but this is not my d= ecision). It=E2=80=99s just that there=E2=80=99s a LOT still missing here, s= o let=E2=80=99s not jump the gun and do things step by step, as the charter a= lso prescribes: "Work on this document will begin when the TAPS Transport Se= rvices have been specified." >>=20 >> Let me be clear, with =E2=80=9Cstep by step=E2=80=9D I=E2=80=99m by no me= ans saying we should slow things down - and as I said before I see a lot of v= alue in this draft! >> My concern is just about mapping drafts to charter items. >>=20 >> Very useful input, yes; in scope of charter item 3: maybe, to some degree= , but at this point more useful as input to item 2 IMO. >>=20 >> Cheers, >> Michael >>=20 >>=20 >>> On Nov 16, 2016, at 4:12 PM, Tommy Pauly wrote: >>>=20 >>> Based on the discussions we had with several folks after the meeting, th= e feeling was that the some of the Post Sockets API approach probably was in= scope for the third item of the TAPS charter. >>>=20 >>> Here's that item for reference: >>>=20 >>> "3) Specify experimental support mechanisms to provide the Transport=20 >>> Services identified in work item 2. This document will explain=20 >>> how to select and engage an appropriate protocol and how to=20 >>> discover which protocols are available for the selected service=20 >>> between a given pair of end points. Further, it will provide a=20 >>> basis for incremental deployment. Work on this document will=20 >>> begin when the TAPS Transport Services have been specified." >>>=20 >>> Here's my take for why the post-sockets effort is in scope: >>>=20 >>> 1. I believe that choosing the correct path/protocol stack for a connect= ion, taking into account both client preferences and system policy, requires= some API support beyond a socket. We need several things beyond traditional= sockets. One is to allow for multipath and fast-open semantics, which can b= e shimmed onto sockets, but require significant changes that make them incom= patible with traditional adopters. Another aspect is the point I brought up i= n my presentation today: we need support for multiple options that may be at= tempted and selected (between protocols, interfaces, and endpoints), and thi= s more complex setup is not compatible with a single-five-tuple single-inter= face socket abstraction. These requirements seem important for "how to selec= t and engage an appropriate protocol", which is in the charter. >>>=20 >>> 2. The charter mentions that the third phase "will provide a basis for i= ncremental deployment". If I try to imagine how we can allow new protocol de= velopment to provide functionality in a non-disruptive manner, it seems most= tractable to (a) define an API layer that provides the minimal subset in a w= ay that is compatible both with existing deployments and future goals; (b) m= ove clients to adopt said API layer as a common abstraction; and (c) increme= ntally add more logic for protocol selection and modifications underneath th= is stable level. This is the approach we've taken in our deployments, and it= has worked well for enabling new features. If Post Sockets is the correct e= xpression of the minimal subset that can lift up the API and allow TAPS to a= dd more smarts to the stack, it would seem we would have addressed the work i= tem. >>>=20 >>> The work TAPS has done so far to catalog the protocol options we see in e= xisting transports is (while tedious) very important, and I think leads to t= he conclusion that a carefully considered API is required to go forward. I a= m concerned that if we do not aggressively and creatively try to minimize an= d unify the interfaces applications use for networking, we will end up with s= till more ossification of the stack. Today, things are ossified around TCP w= hen applications use sockets. If we simply add options for the features we t= hink should be added for TAPS, we still end in ossification if it boils down= to "all apps that use the API in a certain manner always get protocol A". I= hope that with an architecture like Post Sockets, we can distill the essent= ial patterns of communication between endpoints so far that they can indeed g= row along with future network protocol innovations. >>>=20 >>> Thanks, >>> Tommy >>>=20 >>>> On Nov 16, 2016, at 10:48 AM, Brian Trammell wrote: >>>>=20 >>>> Hi, all, >>>>=20 >>>> Looking at where we are in the agenda, we're not going to get to talk a= bout Post Sockets in the meeting in Seoul today. As most of the properties o= f the API are already being discussed during Colin's presentation, this isn'= t that big a deal. However, if anyone who has read draft-trammell-post-socke= ts would like to talk to us about it here in Seoul, please drop me a line. >>>>=20 >>>> To answer Zahed's question at the beginning of the meeting: we didn't c= all this draft-trammell-taps-post-sockets because it's not clear that it's r= eally in scope for TAPS. It presents a radically changed replacement in the a= bstract for the sockets API. However, if the working group is interested in c= ontinuing to discuss it, we're happy to resubmit as draft-trammell-taps-post= -sockets if it makes things easier to follow. :) >>>>=20 >>>> Cheers, >>>>=20 >>>> Brian >>>>=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 --Apple-Mail-DB68DEB3-4F13-4BDD-89EB-AA7C68A63290 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
in line:

Sent from my iPhone

On 16 Nov 2016, at 19:07, Tommy Pauly <tpauly@apple.com> wrote:

Hi Michael,

I definitely agree that the current Post draft is not the f= ulfillment of the charter item 3. My point was that it is not necessarily ou= t of scope, and the work it is looking into may very well be a necessary par= t of satisfying the charter.

agree,


I had read the second charter item as listing o= ut the pieces of functionality that are required for TAPS to provide, rather= than how these pieces should be exposed. Perhaps the API work is somewhere s= plit between 2 and 3? I can certainly see it either way.

yes that's what i mean - it offers good inout to both in= fact


Another point is that the Post draft is still in quite early stages. A= s discussed today, I'd like to write up the approach I presented today as a d= raft, and that could get folded into Post, since I think it requires a Post-= style API in order to be used. I think there is a lot of detail yet to add a= bout how to select and use protocols and paths and options internally to the= connection implementation.

sounds go= od to me!  - note that there's also a draft on happy-eyeballing, not pr= esented this time but still active

cheers
michael



Thanks!
T= ommy

On Nov 16, 2016, at 6:25 PM, Michael Welzl <michawe@ifi.uio.no> wrote:

Hi Tommy,

Be= ing part of the discussions after the meeting, I completely agree. However, t= o me, saying X matches charter item Y is rather premature at this stage.

This draft presents a= few services, which, as was discussed during the meeting,
1) overlap quite a lot with draft-mcquistin-taps-low-latency-services  (good!).
2) match very nicely to the services we already have in e.g. the mi= nset draft  (good!).
(with some small differences that we als= o discussed - one being message dependencies).
<= span style=3D"font-family: 'Helvetica Neue';" class=3D"">

I see this draft as very go= od input but I=E2=80=99d like to do things one by one.
As you know I also agree with this statement of yours:

"I am concerned tha= t if we do not aggressively and creatively try to minimize and unify the int= erfaces applications use for networking, we will end up with still more ossi= fication of the stack=E2=80=9D

so yes, this will definitely happen, but it=E2=80=99s clearly p= art of charter item 2, and here this (and the other) draft are great input!<= /div>

However, while an A= PI can be part of item 3, the relationship to item 3 all in all isn=E2=80=99= t so clear: the draft does not really address much of what item 3 says. It d= oesn't explain much along the lines of selecting and engaging a protocol; it= doesn=E2=80=99t explain how incremental deployment will work; it doesn=E2=80= =99t explain how to discover which protocols are available for the selected s= ervice.

Again, I=E2= =80=99m not saying an API (which is part of what this draft provides) is out= of scope of item 3, but then item 3 should probably be approximately 3 draf= ts (I also have nothing against that  :)  but this is not my decis= ion). It=E2=80=99s just that there=E2=80=99s a LOT still missing here, so le= t=E2=80=99s not jump the gun and do things step by step, as the charter also= prescribes: "Work on this document will begin when the TAPS Transport Servi= ces have been specified."

Let me be clear, with =E2=80=9Cstep by step=E2=80=9D I=E2=80=99m by n= o means saying we should slow things down - and as I said before I see a lot= of value in this draft!
My concern is just about mappi= ng drafts to charter items.

Very useful input, yes; in scope of charter item 3: maybe, to some= degree, but at this point more useful as input to item 2 IMO.

Cheers,
Mi= chael


On N= ov 16, 2016, at 4:12 PM, Tommy Pauly <tpauly@apple.com> wrote:

Based on the discussions we had= with several folks after the meeting, the feeling was that the some of the P= ost Sockets API approach probably was in scope for the third item of the TAP= S charter.

Here's that item for reference:

"3) Specify experimental support mechanisms to prov= ide the Transport
Services identified in work item 2. This do= cument will explain
how to select and engage an appropriate p= rotocol and how to
discover which protocols are available for= the selected service
between a given pair of end points. Fur= ther, it will provide a
basis for incremental deployment. Wor= k on this document will
begin when the TAPS Transport Service= s have been specified."

Here's my take for why t= he post-sockets effort is in scope:

1. I believ= e that choosing the correct path/protocol stack for a connection, taking int= o account both client preferences and system policy, requires some API suppo= rt beyond a socket. We need several things beyond traditional sockets. One i= s to allow for multipath and fast-open semantics, which can be shimmed onto s= ockets, but require significant changes that make them incompatible with tra= ditional adopters. Another aspect is the point I brought up in my presentati= on today: we need support for multiple options that may be attempted and sel= ected (between protocols, interfaces, and endpoints), and this more complex s= etup is not compatible with a single-five-tuple single-interface socket abst= raction. These requirements seem important for "how to select and engage an a= ppropriate protocol", which is in the charter.

= 2. The charter mentions that the third phase "will provide a basis for incre= mental deployment". If I try to imagine how we can allow new protocol develo= pment to provide functionality in a non-disruptive manner, it seems most tra= ctable to (a) define an API layer that provides the minimal subset in a way t= hat is compatible both with existing deployments and future goals; (b) move c= lients to adopt said API layer as a common abstraction; and (c) incrementall= y add more logic for protocol selection and modifications underneath this st= able level. This is the approach we've taken in our deployments, and it has w= orked well for enabling new features. If Post Sockets is the correct express= ion of the minimal subset that can lift up the API and allow TAPS to add mor= e smarts to the stack, it would seem we would have addressed the work item.<= br class=3D"">
The work TAPS has done so far to catalog the pr= otocol options we see in existing transports is (while tedious) very importa= nt, and I think leads to the conclusion that a carefully considered API is r= equired to go forward. I am concerned that if we do not aggressively and cre= atively try to minimize and unify the interfaces applications use for networ= king, we will end up with still more ossification of the stack. Today, thing= s are ossified around TCP when applications use sockets. If we simply add op= tions for the features we think should be added for TAPS, we still end in os= sification if it boils down to "all apps that use the API in a certain manne= r always get protocol A". I hope that with an architecture like Post Sockets= , we can distill the essential patterns of communication between endpoints s= o far that they can indeed grow along with future network protocol innovatio= ns.

Thanks,
Tommy
<= br class=3D"">
On Nov 16, 2016, at 10:48= AM, Brian Trammell <ietf@= trammell.ch> wrote:

Hi, all,

Looking at where we are in the agenda, we're not going to g= et to talk about Post Sockets in the meeting in Seoul today. As most of the p= roperties of the API are already being discussed during Colin's presentation= , this isn't that big a deal. However, if anyone who has read draft-trammell= -post-sockets would like to talk to us about it here in Seoul, please drop m= e a line.

To answer Zahed's question at the beg= inning of the meeting: we didn't call this draft-trammell-taps-post-sockets b= ecause it's not clear that it's really in scope for TAPS. It presents a radi= cally changed replacement in the abstract for the sockets API. However, if t= he working group is interested in continuing to discuss it, we're happy to r= esubmit as draft-trammell-taps-post-sockets if it makes things easier to fol= low. :)

Cheers,

Br= ian

___________________________________________= ____
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listin= fo/taps

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


<= /blockquote>
= --Apple-Mail-DB68DEB3-4F13-4BDD-89EB-AA7C68A63290-- From nobody Wed Nov 16 02:12:00 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1229D1296C3 for ; Wed, 16 Nov 2016 02:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.685 X-Spam-Level: X-Spam-Status: No, score=-5.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vtu_mbOjD5sd for ; Wed, 16 Nov 2016 02:11:52 -0800 (PST) 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 1B8251296F3 for ; Wed, 16 Nov 2016 02:11:52 -0800 (PST) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1c6xC2-0000G0-Hp for taps@ietf.org; Wed, 16 Nov 2016 11:11:50 +0100 Received: from dhcp-8183.meeting.ietf.org ([31.133.129.131]) by mail-mx1.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.80) (envelope-from ) id 1c6xBy-0007Ox-Sl; Wed, 16 Nov 2016 11:11:50 +0100 Content-Type: multipart/alternative; boundary=Apple-Mail-911F344D-03FA-46F9-A56F-A450D5C3B102 Mime-Version: 1.0 (1.0) From: Michael Welzl X-Mailer: iPhone Mail (14B100) In-Reply-To: <8D1687FC-71CE-4D3A-92C5-2108A4C52BC8@ifi.uio.no> Date: Wed, 16 Nov 2016 19:11:44 +0900 Content-Transfer-Encoding: 7bit Message-Id: References: <4985BCB5-45E5-496C-BCDD-6C6DE62C0712@trammell.ch> <8D1687FC-71CE-4D3A-92C5-2108A4C52BC8@ifi.uio.no> To: Tommy Pauly X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 5 sum rcpts/h 20 sum msgs/h 12 total rcpts 48866 max rcpts/h 54 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: 81B3FF25ACD596B160BCB77B4A9FFACFEE860E53 X-UiO-SPAM-Test: remote_host: 31.133.129.131 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: Cc: Brian Trammell , "taps@ietf.org" Subject: Re: [Taps] draft-trammell-post-sockets X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 10:11:59 -0000 --Apple-Mail-911F344D-03FA-46F9-A56F-A450D5C3B102 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable s/inout/input :-) Sent from my iPhone > On 16 Nov 2016, at 19:10, Michael Welzl wrote: >=20 > in line: >=20 > Sent from my iPhone >=20 >> On 16 Nov 2016, at 19:07, Tommy Pauly wrote: >>=20 >> Hi Michael, >>=20 >> I definitely agree that the current Post draft is not the fulfillment of t= he charter item 3. My point was that it is not necessarily out of scope, and= the work it is looking into may very well be a necessary part of satisfying= the charter. >=20 > agree, >=20 >=20 >>=20 >> I had read the second charter item as listing out the pieces of functiona= lity that are required for TAPS to provide, rather than how these pieces sho= uld be exposed. Perhaps the API work is somewhere split between 2 and 3? I c= an certainly see it either way. >=20 > yes that's what i mean - it offers good inout to both in fact >=20 >=20 >> Another point is that the Post draft is still in quite early stages. As d= iscussed today, I'd like to write up the approach I presented today as a dra= ft, and that could get folded into Post, since I think it requires a Post-st= yle API in order to be used. I think there is a lot of detail yet to add abo= ut how to select and use protocols and paths and options internally to the c= onnection implementation. >=20 > sounds good to me! - note that there's also a draft on happy-eyeballing, n= ot presented this time but still active >=20 > cheers > michael >=20 >=20 >>=20 >> Thanks! >> Tommy >>=20 >>> On Nov 16, 2016, at 6:25 PM, Michael Welzl wrote: >>>=20 >>> Hi Tommy, >>>=20 >>> Being part of the discussions after the meeting, I completely agree. How= ever, to me, saying X matches charter item Y is rather premature at this sta= ge. >>>=20 >>> This draft presents a few services, which, as was discussed during the m= eeting, >>> 1) overlap quite a lot with draft-mcquistin-taps-low-latency-services (= good!). >>> 2) match very nicely to the services we already have in e.g. the minset d= raft (good!). >>> (with some small differences that we also discussed - one being message d= ependencies). >>>=20 >>>=20 >>> I see this draft as very good input but I=E2=80=99d like to do things on= e by one. >>> As you know I also agree with this statement of yours: >>>=20 >>> "I am concerned that if we do not aggressively and creatively try to min= imize and unify the interfaces applications use for networking, we will end u= p with still more ossification of the stack=E2=80=9D >>>=20 >>> so yes, this will definitely happen, but it=E2=80=99s clearly part of ch= arter item 2, and here this (and the other) draft are great input! >>>=20 >>> However, while an API can be part of item 3, the relationship to item 3 a= ll in all isn=E2=80=99t so clear: the draft does not really address much of w= hat item 3 says. It doesn't explain much along the lines of selecting and en= gaging a protocol; it doesn=E2=80=99t explain how incremental deployment wil= l work; it doesn=E2=80=99t explain how to discover which protocols are avail= able for the selected service. >>>=20 >>> Again, I=E2=80=99m not saying an API (which is part of what this draft p= rovides) is out of scope of item 3, but then item 3 should probably be appro= ximately 3 drafts (I also have nothing against that :) but this is not my d= ecision). It=E2=80=99s just that there=E2=80=99s a LOT still missing here, s= o let=E2=80=99s not jump the gun and do things step by step, as the charter a= lso prescribes: "Work on this document will begin when the TAPS Transport Se= rvices have been specified." >>>=20 >>> Let me be clear, with =E2=80=9Cstep by step=E2=80=9D I=E2=80=99m by no m= eans saying we should slow things down - and as I said before I see a lot of= value in this draft! >>> My concern is just about mapping drafts to charter items. >>>=20 >>> Very useful input, yes; in scope of charter item 3: maybe, to some degre= e, but at this point more useful as input to item 2 IMO. >>>=20 >>> Cheers, >>> Michael >>>=20 >>>=20 >>>> On Nov 16, 2016, at 4:12 PM, Tommy Pauly wrote: >>>>=20 >>>> Based on the discussions we had with several folks after the meeting, t= he feeling was that the some of the Post Sockets API approach probably was i= n scope for the third item of the TAPS charter. >>>>=20 >>>> Here's that item for reference: >>>>=20 >>>> "3) Specify experimental support mechanisms to provide the Transport=20= >>>> Services identified in work item 2. This document will explain=20 >>>> how to select and engage an appropriate protocol and how to=20 >>>> discover which protocols are available for the selected service=20 >>>> between a given pair of end points. Further, it will provide a=20 >>>> basis for incremental deployment. Work on this document will=20 >>>> begin when the TAPS Transport Services have been specified." >>>>=20 >>>> Here's my take for why the post-sockets effort is in scope: >>>>=20 >>>> 1. I believe that choosing the correct path/protocol stack for a connec= tion, taking into account both client preferences and system policy, require= s some API support beyond a socket. We need several things beyond traditiona= l sockets. One is to allow for multipath and fast-open semantics, which can b= e shimmed onto sockets, but require significant changes that make them incom= patible with traditional adopters. Another aspect is the point I brought up i= n my presentation today: we need support for multiple options that may be at= tempted and selected (between protocols, interfaces, and endpoints), and thi= s more complex setup is not compatible with a single-five-tuple single-inter= face socket abstraction. These requirements seem important for "how to selec= t and engage an appropriate protocol", which is in the charter. >>>>=20 >>>> 2. The charter mentions that the third phase "will provide a basis for i= ncremental deployment". If I try to imagine how we can allow new protocol de= velopment to provide functionality in a non-disruptive manner, it seems most= tractable to (a) define an API layer that provides the minimal subset in a w= ay that is compatible both with existing deployments and future goals; (b) m= ove clients to adopt said API layer as a common abstraction; and (c) increme= ntally add more logic for protocol selection and modifications underneath th= is stable level. This is the approach we've taken in our deployments, and it= has worked well for enabling new features. If Post Sockets is the correct e= xpression of the minimal subset that can lift up the API and allow TAPS to a= dd more smarts to the stack, it would seem we would have addressed the work i= tem. >>>>=20 >>>> The work TAPS has done so far to catalog the protocol options we see in= existing transports is (while tedious) very important, and I think leads to= the conclusion that a carefully considered API is required to go forward. I= am concerned that if we do not aggressively and creatively try to minimize a= nd unify the interfaces applications use for networking, we will end up with= still more ossification of the stack. Today, things are ossified around TCP= when applications use sockets. If we simply add options for the features we= think should be added for TAPS, we still end in ossification if it boils do= wn to "all apps that use the API in a certain manner always get protocol A".= I hope that with an architecture like Post Sockets, we can distill the esse= ntial patterns of communication between endpoints so far that they can indee= d grow along with future network protocol innovations. >>>>=20 >>>> Thanks, >>>> Tommy >>>>=20 >>>>> On Nov 16, 2016, at 10:48 AM, Brian Trammell wrote:= >>>>>=20 >>>>> Hi, all, >>>>>=20 >>>>> Looking at where we are in the agenda, we're not going to get to talk a= bout Post Sockets in the meeting in Seoul today. As most of the properties o= f the API are already being discussed during Colin's presentation, this isn'= t that big a deal. However, if anyone who has read draft-trammell-post-socke= ts would like to talk to us about it here in Seoul, please drop me a line. >>>>>=20 >>>>> To answer Zahed's question at the beginning of the meeting: we didn't c= all this draft-trammell-taps-post-sockets because it's not clear that it's r= eally in scope for TAPS. It presents a radically changed replacement in the a= bstract for the sockets API. However, if the working group is interested in c= ontinuing to discuss it, we're happy to resubmit as draft-trammell-taps-post= -sockets if it makes things easier to follow. :) >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Brian >>>>>=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-911F344D-03FA-46F9-A56F-A450D5C3B102 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
s/inout/input  :-)


Sent from my iPhone

On 16 Nov 201= 6, at 19:10, Michael Welzl <michawe= @ifi.uio.no> wrote:

in l= ine:

Sent from my iPhone

On 16 Nov 2016, at 19:07, Tomm= y Pauly <tpauly@apple.com> wro= te:

Hi Michael,

I definitely agree tha= t the current Post draft is not the fulfillment of the charter item 3. My po= int was that it is not necessarily out of scope, and the work it is looking i= nto may very well be a necessary part of satisfying the charter.
=

agree,



I had read t= he second charter item as listing out the pieces of functionality that are r= equired for TAPS to provide, rather than how these pieces should be exposed.= Perhaps the API work is somewhere split between 2 and 3? I can certainly se= e it either way.

yes that's what i me= an - it offers good inout to both in fact


Another point is that the Post dra= ft is still in quite early stages. As discussed today, I'd like to write up t= he approach I presented today as a draft, and that could get folded into Pos= t, since I think it requires a Post-style API in order to be used. I think t= here is a lot of detail yet to add about how to select and use protocols and= paths and options internally to the connection implementation.
<= /blockquote>

sounds good to me!  - note that there's also= a draft on happy-eyeballing, not presented this time but still active
=

cheers
michael



Thanks!
Tommy

On Nov 16, 2016, at 6:25 PM, Mich= ael Welzl <michawe@ifi.u= io.no> wrote:

Hi Tommy,
<= br class=3D"">
Being part of the discussions after the m= eeting, I completely agree. However, to me, saying X matches charter item Y i= s rather premature at this stage.

=
This draft presents a few services, which, as was discussed d= uring the meeting,
1) overlap quite a lot with draft-mcquistin-taps-= low-latency-services  (good!).
2) match very nicely to the serv= ices we already have in e.g. the minset draft  (good!).
(with= some small differences that we also discussed - one being message dependenc= ies).


I see this draft as very good input but I=E2=80=99d like to do thing= s one by one.
As you know I also agree with this s= tatement of yours:

"I am concerned that if we do not aggressively and creative= ly try to minimize and unify the interfaces applications use for networking,= we will end up with still more ossification of the stack=E2=80=9D

so yes, this will definitel= y happen, but it=E2=80=99s clearly part of charter item 2, and here this (an= d the other) draft are great input!

However, while an API can be part of item 3, the relations= hip to item 3 all in all isn=E2=80=99t so clear: the draft does not really a= ddress much of what item 3 says. It doesn't explain much along the lines of s= electing and engaging a protocol; it doesn=E2=80=99t explain how incremental= deployment will work; it doesn=E2=80=99t explain how to discover which prot= ocols are available for the selected service.

Again, I=E2=80=99m not saying an API (which is p= art of what this draft provides) is out of scope of item 3, but then item 3 s= hould probably be approximately 3 drafts (I also have nothing against that &= nbsp;:)  but this is not my decision). It=E2=80=99s just that there=E2=80= =99s a LOT still missing here, so let=E2=80=99s not jump the gun and do thin= gs step by step, as the charter also prescribes: "Work on this document will= begin when the TAPS Transport Services have been specified."

Let me be clear, with =E2=80=9Cs= tep by step=E2=80=9D I=E2=80=99m by no means saying we should slow things do= wn - and as I said before I see a lot of value in this draft!
My concern is just about mapping drafts to charter items.

Very useful input, yes; in sc= ope of charter item 3: maybe, to some degree, but at this point more useful a= s input to item 2 IMO.

Cheers,
Michael

=

On Nov 16, 2016, at 4:12 PM, Tommy Pauly <<= a href=3D"mailto:tpauly@apple.com" class=3D"">tpauly@apple.com> wrote= :

Based on the discussions we had with several folks after the meeting, the= feeling was that the some of the Post Sockets API approach probably was in s= cope for the third item of the TAPS charter.

He= re's that item for reference:

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

Here's my take for why the post-sockets effort is in scope:

1. I believe that choosing the correct path/protocol s= tack for a connection, taking into account both client preferences and syste= m policy, requires some API support beyond a socket. We need several things b= eyond traditional sockets. One is to allow for multipath and fast-open seman= tics, which can be shimmed onto sockets, but require significant changes tha= t make them incompatible with traditional adopters. Another aspect is the po= int I brought up in my presentation today: we need support for multiple opti= ons that may be attempted and selected (between protocols, interfaces, and e= ndpoints), and this more complex setup is not compatible with a single-five-= tuple single-interface socket abstraction. These requirements seem important= for "how to select and engage an appropriate protocol", which is in the cha= rter.

2. The charter mentions that the third ph= ase "will provide a basis for incremental deployment". If I try to imagine h= ow we can allow new protocol development to provide functionality in a non-d= isruptive manner, it seems most tractable to (a) define an API layer that pr= ovides the minimal subset in a way that is compatible both with existing dep= loyments and future goals; (b) move clients to adopt said API layer as a com= mon abstraction; and (c) incrementally add more logic for protocol selection= and modifications underneath this stable level. This is the approach we've t= aken in our deployments, and it has worked well for enabling new features. I= f Post Sockets is the correct expression of the minimal subset that can lift= up the API and allow TAPS to add more smarts to the stack, it would seem we= would have addressed the work item.

The work T= APS has done so far to catalog the protocol options we see in existing trans= ports is (while tedious) very important, and I think leads to the conclusion= that a carefully considered API is required to go forward. I am concerned t= hat if we do not aggressively and creatively try to minimize and unify the i= nterfaces applications use for networking, we will end up with still more os= sification of the stack. Today, things are ossified around TCP when applicat= ions use sockets. If we simply add options for the features we think should b= e added for TAPS, we still end in ossification if it boils down to "all apps= that use the API in a certain manner always get protocol A". I hope that wi= th an architecture like Post Sockets, we can distill the essential patterns o= f communication between endpoints so far that they can indeed grow along wit= h future network protocol innovations.

Thanks,<= br class=3D"">Tommy

On Nov 16, 2016, at 10:48 AM, Brian Trammell <ietf@trammell.ch> wrote:
=
Hi, all,

Looking at where we are= in the agenda, we're not going to get to talk about Post Sockets in the mee= ting in Seoul today. As most of the properties of the API are already being d= iscussed during Colin's presentation, this isn't that big a deal. However, i= f anyone who has read draft-trammell-post-sockets would like to talk to us a= bout it here in Seoul, please drop me a line.

T= o answer Zahed's question at the beginning of the meeting: we didn't call th= is draft-trammell-taps-post-sockets because it's not clear that it's really i= n scope for TAPS. It presents a radically changed replacement in the abstrac= t for the sockets API. However, if the working group is interested in contin= uing to discuss it, we're happy to resubmit as draft-trammell-taps-post-sock= ets if it makes things easier to follow. :)

Che= ers,

Brian

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


___________________________________________= ____
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
= --Apple-Mail-911F344D-03FA-46F9-A56F-A450D5C3B102-- From nobody Wed Nov 16 23:13:02 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648BD129467 for ; Wed, 16 Nov 2016 23:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xb0s54JbeXN9 for ; Wed, 16 Nov 2016 23:12:37 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95AD1127A90 for ; Wed, 16 Nov 2016 23:12:36 -0800 (PST) X-AuditID: c1b4fb25-ec9d598000007ee2-da-582d5862a2b6 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id 95.63.32482.2685D285; Thu, 17 Nov 2016 08:12:35 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.75) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 17 Nov 2016 08:11:57 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=syJe6fRWGET+CTEXGcUC9xA+AV1RM4QfuBcQyNxQ3Ek=; b=Eqm7sEZk4KxMaSnoRn9OzBbnqZsmGe9KoqqGxuezc5HpyG30QXdu3EAvOFgauxECougktLoYU3rAGnEuhuEOltvfpz7p/0YvxZzjaq++mSaGeI29utk+AODg3n1IjwM6hj/77eOkeir9cE4KfqkpGG9PRsQ+s1SLTtcR6EsDPfU= Received: from AM3PR07MB292.eurprd07.prod.outlook.com (10.242.108.153) by AM3PR07MB290.eurprd07.prod.outlook.com (10.242.108.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.2; Thu, 17 Nov 2016 07:11:54 +0000 Received: from AM3PR07MB292.eurprd07.prod.outlook.com ([fe80::fc06:ad76:7345:cc1e]) by AM3PR07MB292.eurprd07.prod.outlook.com ([fe80::fc06:ad76:7345:cc1e%16]) with mapi id 15.01.0734.007; Thu, 17 Nov 2016 07:11:54 +0000 From: Zaheduzzaman Sarker To: Michael Welzl , Tommy Pauly Thread-Topic: [Taps] draft-trammell-post-sockets Thread-Index: AQHSP6udKJ3r/muO0USPAlSmlHB4F6DbMlIAgAAlG4CAAAuUgIAAAPQAgAFdGLA= Date: Thu, 17 Nov 2016 07:11:54 +0000 Message-ID: References: <4985BCB5-45E5-496C-BCDD-6C6DE62C0712@trammell.ch> <8D1687FC-71CE-4D3A-92C5-2108A4C52BC8@ifi.uio.no> In-Reply-To: <8D1687FC-71CE-4D3A-92C5-2108A4C52BC8@ifi.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zaheduzzaman.sarker@ericsson.com; x-originating-ip: [31.133.142.15] x-microsoft-exchange-diagnostics: 1; AM3PR07MB290; 7:CFeY9BWljnSAcXJfA5Sgch4Dw1VI3c0oF2672MB3+3FxKps0BMlDmZtztdtRpO9Vj6ehMROUdZs5y/GrB4X6TzOt7OAGN0+uHefzlhmzeES6RJ9kPrcRmw6e9e4tEcA48oPAQ+udYHH3ZvODzsos4ovamgs1d0Gd6Jk3SwfsTMNAtE2wUCOeBOM1iNUlDm4Q7tnfVDgn1l96fB065k4iHDMUcDkFJ2p46vL5u6u0cjTf/WQX5GICgUbtfNHcKIX8JaHboRn0dvImzJ2157lPGLdA7MUmkFxCfguLGEUUMiCnlBJUArov/2g7btgUgT/JEMyKCAaV7P1+Mjk7JSBif9UJXR9g8dsua0bxr7ixArM= x-ms-office365-filtering-correlation-id: 86627a98-c19d-4dd1-e1e0-08d40eb902f6 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM3PR07MB290; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(21748063052155)(31960201722614); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6040281)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041223)(6061324)(6072148); SRVR:AM3PR07MB290; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB290; x-forefront-prvs: 01294F875B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(199003)(377454003)(24454002)(189002)(76576001)(101416001)(87936001)(8936002)(9326002)(5003630100001)(3280700002)(68736007)(19609705001)(9686002)(5001770100001)(97736004)(81166006)(81156014)(2906002)(105586002)(606004)(5250100002)(106356001)(106116001)(229853002)(7696004)(5660300001)(2950100002)(93886004)(790700001)(3846002)(92566002)(2900100001)(6116002)(8676002)(3660700001)(8666005)(66066001)(102836003)(189998001)(54356999)(7906003)(76176999)(86362001)(50986999)(33656002)(7736002)(6506003)(230783001)(4326007)(7846002)(74316002)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB290; H:AM3PR07MB292.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM3PR07MB292691BF665C189964158279FB10AM3PR07MB292eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2016 07:11:54.5523 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB290 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURzGO7v3btfh4Dbf/mglLsUs30qRJSIVJYKpUZFDA1t6U0mn7U7L PpSQ+5AhWKk0XSg5FJ1a+ZJvicwwN00Ky8zXnDNLlNIktYzRtrvAb7/znOc5zzl/DokJewh3 MkOmoOUyaaaIy8dVko6YgBRJgCS4L1b8vPA7V7w10kWIpy+K7+t1xDE8ut2wxY3WaH5zorVa Ixa90KfCz+CJ/IhUOjMjj5YHRV7ip2t77xA5ozWcG3XfPvEKUIGaU4QcSKBCYfBVm42FVDOC EXV8EeJbWI+guUGDWRc4VYyBydSEWFcZBwY3YliXEcFQ7TRRhEiSS0WAqSbO6nGmomDp5zrP ypiFBzpnbVknKgjGy1cQ6wmGB8NfcZbjoLX1CWFlnPKB+U2tTRdQiWDu+YGxXToONP/V20wO VCSsqjttjChX2Bxq5LBlbjC5UGV/GgWal28xll1gyWS2+1Og7JeSy+peMFuvRdYCoKowKJlv sYdjYWv5Bc7yaWj6s0ywnAHF5Wv2cBLMrlpfaQ1PItgumbG37YGupTH7qUYCRl+XctnZ0VDX pLTPwh1mPtxFJcivYsfNWc4GwxclXmEbwW4wqBYsTFp0P3jaHcRavKD0npHH8gFQqh/zdurV iNeAXBiauZyVdiQkkJZnpDBMtixQRitakOVL6dq2fTrR+5Xj/YgikchR8KzRXyIkpHlMflY/ AhITOQuczwZIhIJUaf5NWp6dLM/NpJl+5EHiIjdBWP3nBCGVJlXQV2k6h5b/3+WQDu4FKKx7 rsmkDvarvRA14RuD+Z9TbEytydqvjOjHF9/Q6yRXN1zokRTKJHM8Og6Fh+uTZuJNIZVQJK72 HBco1gYCXCtbzLJlc/b1KG/V0c69t1wm5k7t997VoDFMrfsaV853PGpWDTsFJpzw8nR9l6tc LD95e98114eODuu9Y2bmowhn0qWHD2JyRvoPmBl+PE4DAAA= Archived-At: Cc: Brian Trammell , "taps@ietf.org" Subject: Re: [Taps] draft-trammell-post-sockets X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2016 07:12:59 -0000 --_000_AM3PR07MB292691BF665C189964158279FB10AM3PR07MB292eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClNlZW1zIGxpa2Ugd2UgaGF2ZSBpbnRlcmVzdHMgaW4gcG9zdCBzb2NrZXQgZGlzY3Vz c2lvbi4gSXQgZG9lcyBub3QgcmVhbGx5IG1hdHRlciBpZiBwb3N0IHNvY2tldCBkaXNjdXNzaW9u IGhlbHBzIG1pbGVzdG9uZSAyIG9yIDMgb3IgYm90aC4gSXQgaXMgYSBnb29kIGlucHV0IGZvciBU QVNQcyAoIHNwZWNpYWxseSBmb3IgYW4gdXNhYmxlIGNvbXBsZXRpb24gb2YgbWlsZXN0b25lIDMp Lg0KDQpIZW5jZSB3ZSBhcmUgcmVxdWVzdGluZyBCcmlhbiB0byByZXN1Ym1pdCB0aGUgcG9zdCBz b2NrZXQgZHJhZnQgYWRkcmVzc2luZyBUQVBTIHdnLg0KDQpCUg0KDQpaYWhlZA0KDQoNCg0KRnJv bTogVGFwcyBbbWFpbHRvOnRhcHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pY2hh ZWwgV2VsemwNClNlbnQ6IGRlbiAxNiBub3ZlbWJlciAyMDE2IDExOjEwDQpUbzogVG9tbXkgUGF1 bHkgPHRwYXVseUBhcHBsZS5jb20+DQpDYzogQnJpYW4gVHJhbW1lbGwgPGlldGZAdHJhbW1lbGwu Y2g+OyB0YXBzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1RhcHNdIGRyYWZ0LXRyYW1tZWxsLXBv c3Qtc29ja2V0cw0KDQppbiBsaW5lOg0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIDE2IE5v diAyMDE2LCBhdCAxOTowNywgVG9tbXkgUGF1bHkgPHRwYXVseUBhcHBsZS5jb208bWFpbHRvOnRw YXVseUBhcHBsZS5jb20+PiB3cm90ZToNCkhpIE1pY2hhZWwsDQoNCkkgZGVmaW5pdGVseSBhZ3Jl ZSB0aGF0IHRoZSBjdXJyZW50IFBvc3QgZHJhZnQgaXMgbm90IHRoZSBmdWxmaWxsbWVudCBvZiB0 aGUgY2hhcnRlciBpdGVtIDMuIE15IHBvaW50IHdhcyB0aGF0IGl0IGlzIG5vdCBuZWNlc3Nhcmls eSBvdXQgb2Ygc2NvcGUsIGFuZCB0aGUgd29yayBpdCBpcyBsb29raW5nIGludG8gbWF5IHZlcnkg d2VsbCBiZSBhIG5lY2Vzc2FyeSBwYXJ0IG9mIHNhdGlzZnlpbmcgdGhlIGNoYXJ0ZXIuDQoNCmFn cmVlLA0KDQoNCg0KDQpJIGhhZCByZWFkIHRoZSBzZWNvbmQgY2hhcnRlciBpdGVtIGFzIGxpc3Rp bmcgb3V0IHRoZSBwaWVjZXMgb2YgZnVuY3Rpb25hbGl0eSB0aGF0IGFyZSByZXF1aXJlZCBmb3Ig VEFQUyB0byBwcm92aWRlLCByYXRoZXIgdGhhbiBob3cgdGhlc2UgcGllY2VzIHNob3VsZCBiZSBl eHBvc2VkLiBQZXJoYXBzIHRoZSBBUEkgd29yayBpcyBzb21ld2hlcmUgc3BsaXQgYmV0d2VlbiAy IGFuZCAzPyBJIGNhbiBjZXJ0YWlubHkgc2VlIGl0IGVpdGhlciB3YXkuDQoNCnllcyB0aGF0J3Mg d2hhdCBpIG1lYW4gLSBpdCBvZmZlcnMgZ29vZCBpbm91dCB0byBib3RoIGluIGZhY3QNCg0KDQoN CkFub3RoZXIgcG9pbnQgaXMgdGhhdCB0aGUgUG9zdCBkcmFmdCBpcyBzdGlsbCBpbiBxdWl0ZSBl YXJseSBzdGFnZXMuIEFzIGRpc2N1c3NlZCB0b2RheSwgSSdkIGxpa2UgdG8gd3JpdGUgdXAgdGhl IGFwcHJvYWNoIEkgcHJlc2VudGVkIHRvZGF5IGFzIGEgZHJhZnQsIGFuZCB0aGF0IGNvdWxkIGdl dCBmb2xkZWQgaW50byBQb3N0LCBzaW5jZSBJIHRoaW5rIGl0IHJlcXVpcmVzIGEgUG9zdC1zdHls ZSBBUEkgaW4gb3JkZXIgdG8gYmUgdXNlZC4gSSB0aGluayB0aGVyZSBpcyBhIGxvdCBvZiBkZXRh aWwgeWV0IHRvIGFkZCBhYm91dCBob3cgdG8gc2VsZWN0IGFuZCB1c2UgcHJvdG9jb2xzIGFuZCBw YXRocyBhbmQgb3B0aW9ucyBpbnRlcm5hbGx5IHRvIHRoZSBjb25uZWN0aW9uIGltcGxlbWVudGF0 aW9uLg0KDQpzb3VuZHMgZ29vZCB0byBtZSEgIC0gbm90ZSB0aGF0IHRoZXJlJ3MgYWxzbyBhIGRy YWZ0IG9uIGhhcHB5LWV5ZWJhbGxpbmcsIG5vdCBwcmVzZW50ZWQgdGhpcyB0aW1lIGJ1dCBzdGls bCBhY3RpdmUNCg0KY2hlZXJzDQptaWNoYWVsDQoNCg0KDQoNClRoYW5rcyENClRvbW15DQoNCk9u IE5vdiAxNiwgMjAxNiwgYXQgNjoyNSBQTSwgTWljaGFlbCBXZWx6bCA8bWljaGF3ZUBpZmkudWlv Lm5vPG1haWx0bzptaWNoYXdlQGlmaS51aW8ubm8+PiB3cm90ZToNCg0KSGkgVG9tbXksDQoNCkJl aW5nIHBhcnQgb2YgdGhlIGRpc2N1c3Npb25zIGFmdGVyIHRoZSBtZWV0aW5nLCBJIGNvbXBsZXRl bHkgYWdyZWUuIEhvd2V2ZXIsIHRvIG1lLCBzYXlpbmcgWCBtYXRjaGVzIGNoYXJ0ZXIgaXRlbSBZ IGlzIHJhdGhlciBwcmVtYXR1cmUgYXQgdGhpcyBzdGFnZS4NCg0KVGhpcyBkcmFmdCBwcmVzZW50 cyBhIGZldyBzZXJ2aWNlcywgd2hpY2gsIGFzIHdhcyBkaXNjdXNzZWQgZHVyaW5nIHRoZSBtZWV0 aW5nLA0KMSkgb3ZlcmxhcCBxdWl0ZSBhIGxvdCB3aXRoIGRyYWZ0LW1jcXVpc3Rpbi10YXBzLWxv dy1sYXRlbmN5LXNlcnZpY2VzICAoZ29vZCEpLg0KMikgbWF0Y2ggdmVyeSBuaWNlbHkgdG8gdGhl IHNlcnZpY2VzIHdlIGFscmVhZHkgaGF2ZSBpbiBlLmcuIHRoZSBtaW5zZXQgZHJhZnQgIChnb29k ISkuDQood2l0aCBzb21lIHNtYWxsIGRpZmZlcmVuY2VzIHRoYXQgd2UgYWxzbyBkaXNjdXNzZWQg LSBvbmUgYmVpbmcgbWVzc2FnZSBkZXBlbmRlbmNpZXMpLg0KDQoNCkkgc2VlIHRoaXMgZHJhZnQg YXMgdmVyeSBnb29kIGlucHV0IGJ1dCBJ4oCZZCBsaWtlIHRvIGRvIHRoaW5ncyBvbmUgYnkgb25l Lg0KQXMgeW91IGtub3cgSSBhbHNvIGFncmVlIHdpdGggdGhpcyBzdGF0ZW1lbnQgb2YgeW91cnM6 DQoNCiJJIGFtIGNvbmNlcm5lZCB0aGF0IGlmIHdlIGRvIG5vdCBhZ2dyZXNzaXZlbHkgYW5kIGNy ZWF0aXZlbHkgdHJ5IHRvIG1pbmltaXplIGFuZCB1bmlmeSB0aGUgaW50ZXJmYWNlcyBhcHBsaWNh dGlvbnMgdXNlIGZvciBuZXR3b3JraW5nLCB3ZSB3aWxsIGVuZCB1cCB3aXRoIHN0aWxsIG1vcmUg b3NzaWZpY2F0aW9uIG9mIHRoZSBzdGFja+KAnQ0KDQpzbyB5ZXMsIHRoaXMgd2lsbCBkZWZpbml0 ZWx5IGhhcHBlbiwgYnV0IGl04oCZcyBjbGVhcmx5IHBhcnQgb2YgY2hhcnRlciBpdGVtIDIsIGFu ZCBoZXJlIHRoaXMgKGFuZCB0aGUgb3RoZXIpIGRyYWZ0IGFyZSBncmVhdCBpbnB1dCENCg0KSG93 ZXZlciwgd2hpbGUgYW4gQVBJIGNhbiBiZSBwYXJ0IG9mIGl0ZW0gMywgdGhlIHJlbGF0aW9uc2hp cCB0byBpdGVtIDMgYWxsIGluIGFsbCBpc27igJl0IHNvIGNsZWFyOiB0aGUgZHJhZnQgZG9lcyBu b3QgcmVhbGx5IGFkZHJlc3MgbXVjaCBvZiB3aGF0IGl0ZW0gMyBzYXlzLiBJdCBkb2Vzbid0IGV4 cGxhaW4gbXVjaCBhbG9uZyB0aGUgbGluZXMgb2Ygc2VsZWN0aW5nIGFuZCBlbmdhZ2luZyBhIHBy b3RvY29sOyBpdCBkb2VzbuKAmXQgZXhwbGFpbiBob3cgaW5jcmVtZW50YWwgZGVwbG95bWVudCB3 aWxsIHdvcms7IGl0IGRvZXNu4oCZdCBleHBsYWluIGhvdyB0byBkaXNjb3ZlciB3aGljaCBwcm90 b2NvbHMgYXJlIGF2YWlsYWJsZSBmb3IgdGhlIHNlbGVjdGVkIHNlcnZpY2UuDQoNCkFnYWluLCBJ 4oCZbSBub3Qgc2F5aW5nIGFuIEFQSSAod2hpY2ggaXMgcGFydCBvZiB3aGF0IHRoaXMgZHJhZnQg cHJvdmlkZXMpIGlzIG91dCBvZiBzY29wZSBvZiBpdGVtIDMsIGJ1dCB0aGVuIGl0ZW0gMyBzaG91 bGQgcHJvYmFibHkgYmUgYXBwcm94aW1hdGVseSAzIGRyYWZ0cyAoSSBhbHNvIGhhdmUgbm90aGlu ZyBhZ2FpbnN0IHRoYXQgIDopICBidXQgdGhpcyBpcyBub3QgbXkgZGVjaXNpb24pLiBJdOKAmXMg anVzdCB0aGF0IHRoZXJl4oCZcyBhIExPVCBzdGlsbCBtaXNzaW5nIGhlcmUsIHNvIGxldOKAmXMg bm90IGp1bXAgdGhlIGd1biBhbmQgZG8gdGhpbmdzIHN0ZXAgYnkgc3RlcCwgYXMgdGhlIGNoYXJ0 ZXIgYWxzbyBwcmVzY3JpYmVzOiAiV29yayBvbiB0aGlzIGRvY3VtZW50IHdpbGwgYmVnaW4gd2hl biB0aGUgVEFQUyBUcmFuc3BvcnQgU2VydmljZXMgaGF2ZSBiZWVuIHNwZWNpZmllZC4iDQoNCkxl dCBtZSBiZSBjbGVhciwgd2l0aCDigJxzdGVwIGJ5IHN0ZXDigJ0gSeKAmW0gYnkgbm8gbWVhbnMg c2F5aW5nIHdlIHNob3VsZCBzbG93IHRoaW5ncyBkb3duIC0gYW5kIGFzIEkgc2FpZCBiZWZvcmUg SSBzZWUgYSBsb3Qgb2YgdmFsdWUgaW4gdGhpcyBkcmFmdCENCk15IGNvbmNlcm4gaXMganVzdCBh Ym91dCBtYXBwaW5nIGRyYWZ0cyB0byBjaGFydGVyIGl0ZW1zLg0KDQpWZXJ5IHVzZWZ1bCBpbnB1 dCwgeWVzOyBpbiBzY29wZSBvZiBjaGFydGVyIGl0ZW0gMzogbWF5YmUsIHRvIHNvbWUgZGVncmVl LCBidXQgYXQgdGhpcyBwb2ludCBtb3JlIHVzZWZ1bCBhcyBpbnB1dCB0byBpdGVtIDIgSU1PLg0K DQpDaGVlcnMsDQpNaWNoYWVsDQoNCg0KT24gTm92IDE2LCAyMDE2LCBhdCA0OjEyIFBNLCBUb21t eSBQYXVseSA8dHBhdWx5QGFwcGxlLmNvbTxtYWlsdG86dHBhdWx5QGFwcGxlLmNvbT4+IHdyb3Rl Og0KDQpCYXNlZCBvbiB0aGUgZGlzY3Vzc2lvbnMgd2UgaGFkIHdpdGggc2V2ZXJhbCBmb2xrcyBh ZnRlciB0aGUgbWVldGluZywgdGhlIGZlZWxpbmcgd2FzIHRoYXQgdGhlIHNvbWUgb2YgdGhlIFBv c3QgU29ja2V0cyBBUEkgYXBwcm9hY2ggcHJvYmFibHkgd2FzIGluIHNjb3BlIGZvciB0aGUgdGhp cmQgaXRlbSBvZiB0aGUgVEFQUyBjaGFydGVyLg0KDQpIZXJlJ3MgdGhhdCBpdGVtIGZvciByZWZl cmVuY2U6DQoNCiIzKSBTcGVjaWZ5IGV4cGVyaW1lbnRhbCBzdXBwb3J0IG1lY2hhbmlzbXMgdG8g cHJvdmlkZSB0aGUgVHJhbnNwb3J0DQpTZXJ2aWNlcyBpZGVudGlmaWVkIGluIHdvcmsgaXRlbSAy LiBUaGlzIGRvY3VtZW50IHdpbGwgZXhwbGFpbg0KaG93IHRvIHNlbGVjdCBhbmQgZW5nYWdlIGFu IGFwcHJvcHJpYXRlIHByb3RvY29sIGFuZCBob3cgdG8NCmRpc2NvdmVyIHdoaWNoIHByb3RvY29s cyBhcmUgYXZhaWxhYmxlIGZvciB0aGUgc2VsZWN0ZWQgc2VydmljZQ0KYmV0d2VlbiBhIGdpdmVu IHBhaXIgb2YgZW5kIHBvaW50cy4gRnVydGhlciwgaXQgd2lsbCBwcm92aWRlIGENCmJhc2lzIGZv ciBpbmNyZW1lbnRhbCBkZXBsb3ltZW50LiBXb3JrIG9uIHRoaXMgZG9jdW1lbnQgd2lsbA0KYmVn aW4gd2hlbiB0aGUgVEFQUyBUcmFuc3BvcnQgU2VydmljZXMgaGF2ZSBiZWVuIHNwZWNpZmllZC4i DQoNCkhlcmUncyBteSB0YWtlIGZvciB3aHkgdGhlIHBvc3Qtc29ja2V0cyBlZmZvcnQgaXMgaW4g c2NvcGU6DQoNCjEuIEkgYmVsaWV2ZSB0aGF0IGNob29zaW5nIHRoZSBjb3JyZWN0IHBhdGgvcHJv dG9jb2wgc3RhY2sgZm9yIGEgY29ubmVjdGlvbiwgdGFraW5nIGludG8gYWNjb3VudCBib3RoIGNs aWVudCBwcmVmZXJlbmNlcyBhbmQgc3lzdGVtIHBvbGljeSwgcmVxdWlyZXMgc29tZSBBUEkgc3Vw cG9ydCBiZXlvbmQgYSBzb2NrZXQuIFdlIG5lZWQgc2V2ZXJhbCB0aGluZ3MgYmV5b25kIHRyYWRp dGlvbmFsIHNvY2tldHMuIE9uZSBpcyB0byBhbGxvdyBmb3IgbXVsdGlwYXRoIGFuZCBmYXN0LW9w ZW4gc2VtYW50aWNzLCB3aGljaCBjYW4gYmUgc2hpbW1lZCBvbnRvIHNvY2tldHMsIGJ1dCByZXF1 aXJlIHNpZ25pZmljYW50IGNoYW5nZXMgdGhhdCBtYWtlIHRoZW0gaW5jb21wYXRpYmxlIHdpdGgg dHJhZGl0aW9uYWwgYWRvcHRlcnMuIEFub3RoZXIgYXNwZWN0IGlzIHRoZSBwb2ludCBJIGJyb3Vn aHQgdXAgaW4gbXkgcHJlc2VudGF0aW9uIHRvZGF5OiB3ZSBuZWVkIHN1cHBvcnQgZm9yIG11bHRp cGxlIG9wdGlvbnMgdGhhdCBtYXkgYmUgYXR0ZW1wdGVkIGFuZCBzZWxlY3RlZCAoYmV0d2VlbiBw cm90b2NvbHMsIGludGVyZmFjZXMsIGFuZCBlbmRwb2ludHMpLCBhbmQgdGhpcyBtb3JlIGNvbXBs ZXggc2V0dXAgaXMgbm90IGNvbXBhdGlibGUgd2l0aCBhIHNpbmdsZS1maXZlLXR1cGxlIHNpbmds ZS1pbnRlcmZhY2Ugc29ja2V0IGFic3RyYWN0aW9uLiBUaGVzZSByZXF1aXJlbWVudHMgc2VlbSBp bXBvcnRhbnQgZm9yICJob3cgdG8gc2VsZWN0IGFuZCBlbmdhZ2UgYW4gYXBwcm9wcmlhdGUgcHJv dG9jb2wiLCB3aGljaCBpcyBpbiB0aGUgY2hhcnRlci4NCg0KMi4gVGhlIGNoYXJ0ZXIgbWVudGlv bnMgdGhhdCB0aGUgdGhpcmQgcGhhc2UgIndpbGwgcHJvdmlkZSBhIGJhc2lzIGZvciBpbmNyZW1l bnRhbCBkZXBsb3ltZW50Ii4gSWYgSSB0cnkgdG8gaW1hZ2luZSBob3cgd2UgY2FuIGFsbG93IG5l dyBwcm90b2NvbCBkZXZlbG9wbWVudCB0byBwcm92aWRlIGZ1bmN0aW9uYWxpdHkgaW4gYSBub24t ZGlzcnVwdGl2ZSBtYW5uZXIsIGl0IHNlZW1zIG1vc3QgdHJhY3RhYmxlIHRvIChhKSBkZWZpbmUg YW4gQVBJIGxheWVyIHRoYXQgcHJvdmlkZXMgdGhlIG1pbmltYWwgc3Vic2V0IGluIGEgd2F5IHRo YXQgaXMgY29tcGF0aWJsZSBib3RoIHdpdGggZXhpc3RpbmcgZGVwbG95bWVudHMgYW5kIGZ1dHVy ZSBnb2FsczsgKGIpIG1vdmUgY2xpZW50cyB0byBhZG9wdCBzYWlkIEFQSSBsYXllciBhcyBhIGNv bW1vbiBhYnN0cmFjdGlvbjsgYW5kIChjKSBpbmNyZW1lbnRhbGx5IGFkZCBtb3JlIGxvZ2ljIGZv ciBwcm90b2NvbCBzZWxlY3Rpb24gYW5kIG1vZGlmaWNhdGlvbnMgdW5kZXJuZWF0aCB0aGlzIHN0 YWJsZSBsZXZlbC4gVGhpcyBpcyB0aGUgYXBwcm9hY2ggd2UndmUgdGFrZW4gaW4gb3VyIGRlcGxv eW1lbnRzLCBhbmQgaXQgaGFzIHdvcmtlZCB3ZWxsIGZvciBlbmFibGluZyBuZXcgZmVhdHVyZXMu IElmIFBvc3QgU29ja2V0cyBpcyB0aGUgY29ycmVjdCBleHByZXNzaW9uIG9mIHRoZSBtaW5pbWFs IHN1YnNldCB0aGF0IGNhbiBsaWZ0IHVwIHRoZSBBUEkgYW5kIGFsbG93IFRBUFMgdG8gYWRkIG1v cmUgc21hcnRzIHRvIHRoZSBzdGFjaywgaXQgd291bGQgc2VlbSB3ZSB3b3VsZCBoYXZlIGFkZHJl c3NlZCB0aGUgd29yayBpdGVtLg0KDQpUaGUgd29yayBUQVBTIGhhcyBkb25lIHNvIGZhciB0byBj YXRhbG9nIHRoZSBwcm90b2NvbCBvcHRpb25zIHdlIHNlZSBpbiBleGlzdGluZyB0cmFuc3BvcnRz IGlzICh3aGlsZSB0ZWRpb3VzKSB2ZXJ5IGltcG9ydGFudCwgYW5kIEkgdGhpbmsgbGVhZHMgdG8g dGhlIGNvbmNsdXNpb24gdGhhdCBhIGNhcmVmdWxseSBjb25zaWRlcmVkIEFQSSBpcyByZXF1aXJl ZCB0byBnbyBmb3J3YXJkLiBJIGFtIGNvbmNlcm5lZCB0aGF0IGlmIHdlIGRvIG5vdCBhZ2dyZXNz aXZlbHkgYW5kIGNyZWF0aXZlbHkgdHJ5IHRvIG1pbmltaXplIGFuZCB1bmlmeSB0aGUgaW50ZXJm YWNlcyBhcHBsaWNhdGlvbnMgdXNlIGZvciBuZXR3b3JraW5nLCB3ZSB3aWxsIGVuZCB1cCB3aXRo IHN0aWxsIG1vcmUgb3NzaWZpY2F0aW9uIG9mIHRoZSBzdGFjay4gVG9kYXksIHRoaW5ncyBhcmUg b3NzaWZpZWQgYXJvdW5kIFRDUCB3aGVuIGFwcGxpY2F0aW9ucyB1c2Ugc29ja2V0cy4gSWYgd2Ug c2ltcGx5IGFkZCBvcHRpb25zIGZvciB0aGUgZmVhdHVyZXMgd2UgdGhpbmsgc2hvdWxkIGJlIGFk ZGVkIGZvciBUQVBTLCB3ZSBzdGlsbCBlbmQgaW4gb3NzaWZpY2F0aW9uIGlmIGl0IGJvaWxzIGRv d24gdG8gImFsbCBhcHBzIHRoYXQgdXNlIHRoZSBBUEkgaW4gYSBjZXJ0YWluIG1hbm5lciBhbHdh eXMgZ2V0IHByb3RvY29sIEEiLiBJIGhvcGUgdGhhdCB3aXRoIGFuIGFyY2hpdGVjdHVyZSBsaWtl IFBvc3QgU29ja2V0cywgd2UgY2FuIGRpc3RpbGwgdGhlIGVzc2VudGlhbCBwYXR0ZXJucyBvZiBj b21tdW5pY2F0aW9uIGJldHdlZW4gZW5kcG9pbnRzIHNvIGZhciB0aGF0IHRoZXkgY2FuIGluZGVl ZCBncm93IGFsb25nIHdpdGggZnV0dXJlIG5ldHdvcmsgcHJvdG9jb2wgaW5ub3ZhdGlvbnMuDQoN ClRoYW5rcywNClRvbW15DQoNCg0KT24gTm92IDE2LCAyMDE2LCBhdCAxMDo0OCBBTSwgQnJpYW4g VHJhbW1lbGwgPGlldGZAdHJhbW1lbGwuY2g8bWFpbHRvOmlldGZAdHJhbW1lbGwuY2g+PiB3cm90 ZToNCg0KSGksIGFsbCwNCg0KTG9va2luZyBhdCB3aGVyZSB3ZSBhcmUgaW4gdGhlIGFnZW5kYSwg d2UncmUgbm90IGdvaW5nIHRvIGdldCB0byB0YWxrIGFib3V0IFBvc3QgU29ja2V0cyBpbiB0aGUg bWVldGluZyBpbiBTZW91bCB0b2RheS4gQXMgbW9zdCBvZiB0aGUgcHJvcGVydGllcyBvZiB0aGUg QVBJIGFyZSBhbHJlYWR5IGJlaW5nIGRpc2N1c3NlZCBkdXJpbmcgQ29saW4ncyBwcmVzZW50YXRp b24sIHRoaXMgaXNuJ3QgdGhhdCBiaWcgYSBkZWFsLiBIb3dldmVyLCBpZiBhbnlvbmUgd2hvIGhh cyByZWFkIGRyYWZ0LXRyYW1tZWxsLXBvc3Qtc29ja2V0cyB3b3VsZCBsaWtlIHRvIHRhbGsgdG8g dXMgYWJvdXQgaXQgaGVyZSBpbiBTZW91bCwgcGxlYXNlIGRyb3AgbWUgYSBsaW5lLg0KDQpUbyBh bnN3ZXIgWmFoZWQncyBxdWVzdGlvbiBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBtZWV0aW5nOiB3 ZSBkaWRuJ3QgY2FsbCB0aGlzIGRyYWZ0LXRyYW1tZWxsLXRhcHMtcG9zdC1zb2NrZXRzIGJlY2F1 c2UgaXQncyBub3QgY2xlYXIgdGhhdCBpdCdzIHJlYWxseSBpbiBzY29wZSBmb3IgVEFQUy4gSXQg cHJlc2VudHMgYSByYWRpY2FsbHkgY2hhbmdlZCByZXBsYWNlbWVudCBpbiB0aGUgYWJzdHJhY3Qg Zm9yIHRoZSBzb2NrZXRzIEFQSS4gSG93ZXZlciwgaWYgdGhlIHdvcmtpbmcgZ3JvdXAgaXMgaW50 ZXJlc3RlZCBpbiBjb250aW51aW5nIHRvIGRpc2N1c3MgaXQsIHdlJ3JlIGhhcHB5IHRvIHJlc3Vi bWl0IGFzIGRyYWZ0LXRyYW1tZWxsLXRhcHMtcG9zdC1zb2NrZXRzIGlmIGl0IG1ha2VzIHRoaW5n cyBlYXNpZXIgdG8gZm9sbG93LiA6KQ0KDQpDaGVlcnMsDQoNCkJyaWFuDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUYXBzIG1haWxpbmcgbGlzdA0K VGFwc0BpZXRmLm9yZzxtYWlsdG86VGFwc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdGFwcw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KVGFwcyBtYWlsaW5nIGxpc3QNClRhcHNAaWV0Zi5vcmc8bWFpbHRv OlRhcHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rh cHMNCg0KDQo= --_000_AM3PR07MB292691BF665C189964158279FB10AM3PR07MB292eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VnJpbmRhOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiSGVsdmV0aWNhIE5l dWUiOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0Kc3Bhbi5nbWFpbG1zZw0KCXttc28tc3R5bGUtbmFtZTpnbWFpbF9tc2c7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ bWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TZWVt cyBsaWtlIHdlIGhhdmUgaW50ZXJlc3RzIGluIHBvc3Qgc29ja2V0IGRpc2N1c3Npb24uIEl0IGRv ZXMgbm90IHJlYWxseSBtYXR0ZXIgaWY8L3NwYW4+PHNwYW4gY2xhc3M9ImdtYWlsbXNnIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gcG9z dCBzb2NrZXQNCiBkaXNjdXNzaW9uIGhlbHBzIG1pbGVzdG9uZSAyIG9yIDMgb3IgYm90aC4gSXQg aXMgYSBnb29kIGlucHV0IGZvciBUQVNQcyAoIHNwZWNpYWxseSBmb3IgYW4gdXNhYmxlIGNvbXBs ZXRpb24gb2YgbWlsZXN0b25lIDMpLg0KPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJnbWFpbG1zZyI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJn bWFpbG1zZyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+SGVuY2Ugd2UgYXJlIHJlcXVlc3RpbmcNCjwvc3Bhbj48L3NwYW4+QnJpYW48c3Bh biBjbGFzcz0iZ21haWxtc2ciPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiB0byByZXN1Ym1pdCB0aGUgcG9zdCBzb2NrZXQgZHJhZnQgYWRk cmVzc2luZyBUQVBTIHdnLjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iZ21haWxtc2ciPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iZ21haWxtc2ci PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkJSPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGNsYXNzPSJnbWFpbG1zZyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJnbWFpbG1zZyI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+WmFoZWQNCjwvc3Bh bj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFRhcHMgW21haWx0 bzp0YXBzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1pY2hhZWwgV2Vs emw8YnI+DQo8Yj5TZW50OjwvYj4gZGVuIDE2IG5vdmVtYmVyIDIwMTYgMTE6MTA8YnI+DQo8Yj5U bzo8L2I+IFRvbW15IFBhdWx5ICZsdDt0cGF1bHlAYXBwbGUuY29tJmd0Ozxicj4NCjxiPkNjOjwv Yj4gQnJpYW4gVHJhbW1lbGwgJmx0O2lldGZAdHJhbW1lbGwuY2gmZ3Q7OyB0YXBzQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVGFwc10gZHJhZnQtdHJhbW1lbGwtcG9zdC1zb2Nr ZXRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmluIGxpbmU6PGJyPg0KPGJyPg0KU2VudCBmcm9tIG15IGlQaG9uZTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48YnI+DQpPbiAxNiBOb3YgMjAxNiwgYXQgMTk6MDcsIFRvbW15IFBhdWx5ICZsdDs8 YSBocmVmPSJtYWlsdG86dHBhdWx5QGFwcGxlLmNvbSI+dHBhdWx5QGFwcGxlLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGkgTWljaGFlbCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkZWZpbml0ZWx5IGFncmVlIHRoYXQgdGhlIGN1cnJlbnQg UG9zdCBkcmFmdCBpcyBub3QgdGhlIGZ1bGZpbGxtZW50IG9mIHRoZSBjaGFydGVyIGl0ZW0gMy4g TXkgcG9pbnQgd2FzIHRoYXQgaXQgaXMgbm90IG5lY2Vzc2FyaWx5IG91dCBvZiBzY29wZSwgYW5k IHRoZSB3b3JrIGl0IGlzIGxvb2tpbmcgaW50byBtYXkgdmVyeSB3ZWxsIGJlIGEgbmVjZXNzYXJ5 IHBhcnQgb2Ygc2F0aXNmeWluZyB0aGUgY2hhcnRlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFncmVlLDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhh ZCByZWFkIHRoZSBzZWNvbmQgY2hhcnRlciBpdGVtIGFzIGxpc3Rpbmcgb3V0IHRoZSBwaWVjZXMg b2YgZnVuY3Rpb25hbGl0eSB0aGF0IGFyZSByZXF1aXJlZCBmb3IgVEFQUyB0byBwcm92aWRlLCBy YXRoZXIgdGhhbiBob3cgdGhlc2UgcGllY2VzIHNob3VsZCBiZSBleHBvc2VkLiBQZXJoYXBzIHRo ZSBBUEkgd29yayBpcyBzb21ld2hlcmUgc3BsaXQgYmV0d2VlbiAyIGFuZCAzPyBJIGNhbiBjZXJ0 YWlubHkNCiBzZWUgaXQgZWl0aGVyIHdheS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnllcyB0aGF0J3Mgd2hhdCBp IG1lYW4gLSBpdCBvZmZlcnMgZ29vZCBpbm91dCB0byBib3RoIGluIGZhY3Q8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5vdGhl ciBwb2ludCBpcyB0aGF0IHRoZSBQb3N0IGRyYWZ0IGlzIHN0aWxsIGluIHF1aXRlIGVhcmx5IHN0 YWdlcy4gQXMgZGlzY3Vzc2VkIHRvZGF5LCBJJ2QgbGlrZSB0byB3cml0ZSB1cCB0aGUgYXBwcm9h Y2ggSSBwcmVzZW50ZWQgdG9kYXkgYXMgYSBkcmFmdCwgYW5kIHRoYXQgY291bGQgZ2V0IGZvbGRl ZCBpbnRvIFBvc3QsIHNpbmNlIEkgdGhpbmsgaXQgcmVxdWlyZXMgYSBQb3N0LXN0eWxlIEFQSSBp bg0KIG9yZGVyIHRvIGJlIHVzZWQuIEkgdGhpbmsgdGhlcmUgaXMgYSBsb3Qgb2YgZGV0YWlsIHll dCB0byBhZGQgYWJvdXQgaG93IHRvIHNlbGVjdCBhbmQgdXNlIHByb3RvY29scyBhbmQgcGF0aHMg YW5kIG9wdGlvbnMgaW50ZXJuYWxseSB0byB0aGUgY29ubmVjdGlvbiBpbXBsZW1lbnRhdGlvbi48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPnNvdW5kcyBnb29kIHRvIG1lISAmbmJzcDstIG5vdGUgdGhhdCB0aGVyZSdz IGFsc28gYSBkcmFmdCBvbiBoYXBweS1leWViYWxsaW5nLCBub3QgcHJlc2VudGVkIHRoaXMgdGlt ZSBidXQgc3RpbGwgYWN0aXZlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPmNoZWVyczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+bWljaGFlbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyE8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvbW15PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE5vdiAxNiwgMjAxNiwgYXQgNjoy NSBQTSwgTWljaGFlbCBXZWx6bCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pY2hhd2VAaWZpLnVpby5u byI+bWljaGF3ZUBpZmkudWlvLm5vPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBUb21teSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlaW5nIHBhcnQgb2YgdGhlIGRpc2N1c3Npb25zIGFm dGVyIHRoZSBtZWV0aW5nLCBJIGNvbXBsZXRlbHkgYWdyZWUuIEhvd2V2ZXIsIHRvIG1lLCBzYXlp bmcgWCBtYXRjaGVzIGNoYXJ0ZXIgaXRlbSBZIGlzIHJhdGhlciBwcmVtYXR1cmUgYXQgdGhpcyBz dGFnZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhpcyBkcmFmdCBwcmVzZW50cyBhIGZldyBzZXJ2aWNlcywgd2hpY2gsIGFzIHdhcyBkaXNj dXNzZWQgZHVyaW5nIHRoZSBtZWV0aW5nLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+MSkgb3ZlcmxhcCBxdWl0ZSBhIGxvdCB3aXRoJm5ic3A7PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7LHNlcmlmIj5k cmFmdC1tY3F1aXN0aW4tdGFwcy1sb3ctbGF0ZW5jeS1zZXJ2aWNlcyAmbmJzcDsoZ29vZCEpLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyxzZXJp ZiI+MikgbWF0Y2ggdmVyeSBuaWNlbHkgdG8gdGhlIHNlcnZpY2VzIHdlIGFscmVhZHkgaGF2ZSBp biBlLmcuIHRoZSBtaW5zZXQgZHJhZnQgJm5ic3A7KGdvb2QhKS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDssc2VyaWYiPih3aXRoIHNvbWUgc21h bGwgZGlmZmVyZW5jZXMgdGhhdCB3ZSBhbHNvIGRpc2N1c3NlZCAtIG9uZSBiZWluZyBtZXNzYWdl IGRlcGVuZGVuY2llcykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EgTmV1ZSZxdW90OyxzZXJpZiI+SSBzZWUgdGhpcyBkcmFmdCBhcyB2ZXJ5IGdvb2QgaW5w dXQgYnV0IEnigJlkIGxpa2UgdG8gZG8gdGhpbmdzIG9uZSBieSBvbmUuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7LHNlcmlmIj5BcyB5b3Uga25v dyBJIGFsc28gYWdyZWUgd2l0aCB0aGlzIHN0YXRlbWVudCBvZiB5b3Vyczo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyxzZXJpZiI+JnF1b3Q7 PC9zcGFuPkkgYW0gY29uY2VybmVkIHRoYXQgaWYgd2UgZG8gbm90IGFnZ3Jlc3NpdmVseSBhbmQg Y3JlYXRpdmVseSB0cnkgdG8gbWluaW1pemUgYW5kIHVuaWZ5IHRoZSBpbnRlcmZhY2VzIGFwcGxp Y2F0aW9ucyB1c2UgZm9yIG5ldHdvcmtpbmcsIHdlIHdpbGwgZW5kIHVwIHdpdGggc3RpbGwgbW9y ZSBvc3NpZmljYXRpb24NCiBvZiB0aGUgc3RhY2vigJ08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c28geWVzLCB0aGlzIHdpbGwgZGVmaW5pdGVs eSBoYXBwZW4sIGJ1dCBpdOKAmXMgY2xlYXJseSBwYXJ0IG9mIGNoYXJ0ZXIgaXRlbSAyLCBhbmQg aGVyZSB0aGlzIChhbmQgdGhlIG90aGVyKSBkcmFmdCBhcmUgZ3JlYXQgaW5wdXQhPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIHdo aWxlIGFuIEFQSSBjYW4gYmUgcGFydCBvZiBpdGVtIDMsIHRoZSByZWxhdGlvbnNoaXAgdG8gaXRl bSAzIGFsbCBpbiBhbGwgaXNu4oCZdCBzbyBjbGVhcjogdGhlIGRyYWZ0IGRvZXMgbm90IHJlYWxs eSBhZGRyZXNzIG11Y2ggb2Ygd2hhdCBpdGVtIDMgc2F5cy4gSXQgZG9lc24ndCBleHBsYWluIG11 Y2ggYWxvbmcgdGhlIGxpbmVzIG9mIHNlbGVjdGluZyBhbmQgZW5nYWdpbmcgYSBwcm90b2NvbDsN CiBpdCBkb2VzbuKAmXQgZXhwbGFpbiBob3cgaW5jcmVtZW50YWwgZGVwbG95bWVudCB3aWxsIHdv cms7IGl0IGRvZXNu4oCZdCBleHBsYWluIGhvdyB0byBkaXNjb3ZlciB3aGljaCBwcm90b2NvbHMg YXJlIGF2YWlsYWJsZSBmb3IgdGhlIHNlbGVjdGVkIHNlcnZpY2UuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFnYWluLCBJ4oCZbSBub3Qgc2F5 aW5nIGFuIEFQSSAod2hpY2ggaXMgcGFydCBvZiB3aGF0IHRoaXMgZHJhZnQgcHJvdmlkZXMpIGlz IG91dCBvZiBzY29wZSBvZiBpdGVtIDMsIGJ1dCB0aGVuIGl0ZW0gMyBzaG91bGQgcHJvYmFibHkg YmUgYXBwcm94aW1hdGVseSAzIGRyYWZ0cyAoSSBhbHNvIGhhdmUgbm90aGluZyBhZ2FpbnN0IHRo YXQgJm5ic3A7OikgJm5ic3A7YnV0IHRoaXMgaXMgbm90IG15IGRlY2lzaW9uKS4gSXTigJlzIGp1 c3QNCiB0aGF0IHRoZXJl4oCZcyBhIExPVCBzdGlsbCBtaXNzaW5nIGhlcmUsIHNvIGxldOKAmXMg bm90IGp1bXAgdGhlIGd1biBhbmQgZG8gdGhpbmdzIHN0ZXAgYnkgc3RlcCwgYXMgdGhlIGNoYXJ0 ZXIgYWxzbyBwcmVzY3JpYmVzOiAmcXVvdDtXb3JrIG9uIHRoaXMgZG9jdW1lbnQgd2lsbCBiZWdp biB3aGVuIHRoZSBUQVBTIFRyYW5zcG9ydCBTZXJ2aWNlcyBoYXZlIGJlZW4gc3BlY2lmaWVkLiZx dW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5MZXQgbWUgYmUgY2xlYXIsIHdpdGgg4oCcc3RlcCBieSBzdGVw4oCdIEnigJltIGJ5IG5vIG1l YW5zIHNheWluZyB3ZSBzaG91bGQgc2xvdyB0aGluZ3MgZG93biAtIGFuZCBhcyBJIHNhaWQgYmVm b3JlIEkgc2VlIGEgbG90IG9mIHZhbHVlIGluIHRoaXMgZHJhZnQhPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBjb25jZXJuIGlzIGp1c3QgYWJv dXQgbWFwcGluZyBkcmFmdHMgdG8gY2hhcnRlciBpdGVtcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VmVyeSB1c2VmdWwgaW5wdXQsIHllczsg aW4gc2NvcGUgb2YgY2hhcnRlciBpdGVtIDM6IG1heWJlLCB0byBzb21lIGRlZ3JlZSwgYnV0IGF0 IHRoaXMgcG9pbnQgbW9yZSB1c2VmdWwgYXMgaW5wdXQgdG8gaXRlbSAyIElNTy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWljaGFlbDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBOb3YgMTYsIDIwMTYsIGF0IDQ6MTIgUE0sIFRvbW15IFBhdWx5ICZsdDs8YSBocmVmPSJtYWls dG86dHBhdWx5QGFwcGxlLmNvbSI+dHBhdWx5QGFwcGxlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFzZWQgb24gdGhlIGRp c2N1c3Npb25zIHdlIGhhZCB3aXRoIHNldmVyYWwgZm9sa3MgYWZ0ZXIgdGhlIG1lZXRpbmcsIHRo ZSBmZWVsaW5nIHdhcyB0aGF0IHRoZSBzb21lIG9mIHRoZSBQb3N0IFNvY2tldHMgQVBJIGFwcHJv YWNoIHByb2JhYmx5IHdhcyBpbiBzY29wZSBmb3IgdGhlIHRoaXJkIGl0ZW0gb2YgdGhlIFRBUFMg Y2hhcnRlci48YnI+DQo8YnI+DQpIZXJlJ3MgdGhhdCBpdGVtIGZvciByZWZlcmVuY2U6PGJyPg0K PGJyPg0KJnF1b3Q7MykgU3BlY2lmeSBleHBlcmltZW50YWwgc3VwcG9ydCBtZWNoYW5pc21zIHRv IHByb3ZpZGUgdGhlIFRyYW5zcG9ydCA8YnI+DQpTZXJ2aWNlcyBpZGVudGlmaWVkIGluIHdvcmsg aXRlbSAyLiBUaGlzIGRvY3VtZW50IHdpbGwgZXhwbGFpbiA8YnI+DQpob3cgdG8gc2VsZWN0IGFu ZCBlbmdhZ2UgYW4gYXBwcm9wcmlhdGUgcHJvdG9jb2wgYW5kIGhvdyB0byA8YnI+DQpkaXNjb3Zl ciB3aGljaCBwcm90b2NvbHMgYXJlIGF2YWlsYWJsZSBmb3IgdGhlIHNlbGVjdGVkIHNlcnZpY2Ug PGJyPg0KYmV0d2VlbiBhIGdpdmVuIHBhaXIgb2YgZW5kIHBvaW50cy4gRnVydGhlciwgaXQgd2ls bCBwcm92aWRlIGEgPGJyPg0KYmFzaXMgZm9yIGluY3JlbWVudGFsIGRlcGxveW1lbnQuIFdvcmsg b24gdGhpcyBkb2N1bWVudCB3aWxsIDxicj4NCmJlZ2luIHdoZW4gdGhlIFRBUFMgVHJhbnNwb3J0 IFNlcnZpY2VzIGhhdmUgYmVlbiBzcGVjaWZpZWQuJnF1b3Q7PGJyPg0KPGJyPg0KSGVyZSdzIG15 IHRha2UgZm9yIHdoeSB0aGUgcG9zdC1zb2NrZXRzIGVmZm9ydCBpcyBpbiBzY29wZTo8YnI+DQo8 YnI+DQoxLiBJIGJlbGlldmUgdGhhdCBjaG9vc2luZyB0aGUgY29ycmVjdCBwYXRoL3Byb3RvY29s IHN0YWNrIGZvciBhIGNvbm5lY3Rpb24sIHRha2luZyBpbnRvIGFjY291bnQgYm90aCBjbGllbnQg cHJlZmVyZW5jZXMgYW5kIHN5c3RlbSBwb2xpY3ksIHJlcXVpcmVzIHNvbWUgQVBJIHN1cHBvcnQg YmV5b25kIGEgc29ja2V0LiBXZSBuZWVkIHNldmVyYWwgdGhpbmdzIGJleW9uZCB0cmFkaXRpb25h bCBzb2NrZXRzLiBPbmUgaXMgdG8gYWxsb3cgZm9yIG11bHRpcGF0aA0KIGFuZCBmYXN0LW9wZW4g c2VtYW50aWNzLCB3aGljaCBjYW4gYmUgc2hpbW1lZCBvbnRvIHNvY2tldHMsIGJ1dCByZXF1aXJl IHNpZ25pZmljYW50IGNoYW5nZXMgdGhhdCBtYWtlIHRoZW0gaW5jb21wYXRpYmxlIHdpdGggdHJh ZGl0aW9uYWwgYWRvcHRlcnMuIEFub3RoZXIgYXNwZWN0IGlzIHRoZSBwb2ludCBJIGJyb3VnaHQg dXAgaW4gbXkgcHJlc2VudGF0aW9uIHRvZGF5OiB3ZSBuZWVkIHN1cHBvcnQgZm9yIG11bHRpcGxl IG9wdGlvbnMgdGhhdA0KIG1heSBiZSBhdHRlbXB0ZWQgYW5kIHNlbGVjdGVkIChiZXR3ZWVuIHBy b3RvY29scywgaW50ZXJmYWNlcywgYW5kIGVuZHBvaW50cyksIGFuZCB0aGlzIG1vcmUgY29tcGxl eCBzZXR1cCBpcyBub3QgY29tcGF0aWJsZSB3aXRoIGEgc2luZ2xlLWZpdmUtdHVwbGUgc2luZ2xl LWludGVyZmFjZSBzb2NrZXQgYWJzdHJhY3Rpb24uIFRoZXNlIHJlcXVpcmVtZW50cyBzZWVtIGlt cG9ydGFudCBmb3IgJnF1b3Q7aG93IHRvIHNlbGVjdCBhbmQgZW5nYWdlIGFuIGFwcHJvcHJpYXRl DQogcHJvdG9jb2wmcXVvdDssIHdoaWNoIGlzIGluIHRoZSBjaGFydGVyLjxicj4NCjxicj4NCjIu IFRoZSBjaGFydGVyIG1lbnRpb25zIHRoYXQgdGhlIHRoaXJkIHBoYXNlICZxdW90O3dpbGwgcHJv dmlkZSBhIGJhc2lzIGZvciBpbmNyZW1lbnRhbCBkZXBsb3ltZW50JnF1b3Q7LiBJZiBJIHRyeSB0 byBpbWFnaW5lIGhvdyB3ZSBjYW4gYWxsb3cgbmV3IHByb3RvY29sIGRldmVsb3BtZW50IHRvIHBy b3ZpZGUgZnVuY3Rpb25hbGl0eSBpbiBhIG5vbi1kaXNydXB0aXZlIG1hbm5lciwgaXQgc2VlbXMg bW9zdCB0cmFjdGFibGUgdG8gKGEpIGRlZmluZSBhbiBBUEkgbGF5ZXINCiB0aGF0IHByb3ZpZGVz IHRoZSBtaW5pbWFsIHN1YnNldCBpbiBhIHdheSB0aGF0IGlzIGNvbXBhdGlibGUgYm90aCB3aXRo IGV4aXN0aW5nIGRlcGxveW1lbnRzIGFuZCBmdXR1cmUgZ29hbHM7IChiKSBtb3ZlIGNsaWVudHMg dG8gYWRvcHQgc2FpZCBBUEkgbGF5ZXIgYXMgYSBjb21tb24gYWJzdHJhY3Rpb247IGFuZCAoYykg aW5jcmVtZW50YWxseSBhZGQgbW9yZSBsb2dpYyBmb3IgcHJvdG9jb2wgc2VsZWN0aW9uIGFuZCBt b2RpZmljYXRpb25zIHVuZGVybmVhdGgNCiB0aGlzIHN0YWJsZSBsZXZlbC4gVGhpcyBpcyB0aGUg YXBwcm9hY2ggd2UndmUgdGFrZW4gaW4gb3VyIGRlcGxveW1lbnRzLCBhbmQgaXQgaGFzIHdvcmtl ZCB3ZWxsIGZvciBlbmFibGluZyBuZXcgZmVhdHVyZXMuIElmIFBvc3QgU29ja2V0cyBpcyB0aGUg Y29ycmVjdCBleHByZXNzaW9uIG9mIHRoZSBtaW5pbWFsIHN1YnNldCB0aGF0IGNhbiBsaWZ0IHVw IHRoZSBBUEkgYW5kIGFsbG93IFRBUFMgdG8gYWRkIG1vcmUgc21hcnRzIHRvIHRoZSBzdGFjaywN CiBpdCB3b3VsZCBzZWVtIHdlIHdvdWxkIGhhdmUgYWRkcmVzc2VkIHRoZSB3b3JrIGl0ZW0uPGJy Pg0KPGJyPg0KVGhlIHdvcmsgVEFQUyBoYXMgZG9uZSBzbyBmYXIgdG8gY2F0YWxvZyB0aGUgcHJv dG9jb2wgb3B0aW9ucyB3ZSBzZWUgaW4gZXhpc3RpbmcgdHJhbnNwb3J0cyBpcyAod2hpbGUgdGVk aW91cykgdmVyeSBpbXBvcnRhbnQsIGFuZCBJIHRoaW5rIGxlYWRzIHRvIHRoZSBjb25jbHVzaW9u IHRoYXQgYSBjYXJlZnVsbHkgY29uc2lkZXJlZCBBUEkgaXMgcmVxdWlyZWQgdG8gZ28gZm9yd2Fy ZC4gSSBhbSBjb25jZXJuZWQgdGhhdCBpZiB3ZSBkbyBub3QgYWdncmVzc2l2ZWx5DQogYW5kIGNy ZWF0aXZlbHkgdHJ5IHRvIG1pbmltaXplIGFuZCB1bmlmeSB0aGUgaW50ZXJmYWNlcyBhcHBsaWNh dGlvbnMgdXNlIGZvciBuZXR3b3JraW5nLCB3ZSB3aWxsIGVuZCB1cCB3aXRoIHN0aWxsIG1vcmUg b3NzaWZpY2F0aW9uIG9mIHRoZSBzdGFjay4gVG9kYXksIHRoaW5ncyBhcmUgb3NzaWZpZWQgYXJv dW5kIFRDUCB3aGVuIGFwcGxpY2F0aW9ucyB1c2Ugc29ja2V0cy4gSWYgd2Ugc2ltcGx5IGFkZCBv cHRpb25zIGZvciB0aGUgZmVhdHVyZXMNCiB3ZSB0aGluayBzaG91bGQgYmUgYWRkZWQgZm9yIFRB UFMsIHdlIHN0aWxsIGVuZCBpbiBvc3NpZmljYXRpb24gaWYgaXQgYm9pbHMgZG93biB0byAmcXVv dDthbGwgYXBwcyB0aGF0IHVzZSB0aGUgQVBJIGluIGEgY2VydGFpbiBtYW5uZXIgYWx3YXlzIGdl dCBwcm90b2NvbCBBJnF1b3Q7LiBJIGhvcGUgdGhhdCB3aXRoIGFuIGFyY2hpdGVjdHVyZSBsaWtl IFBvc3QgU29ja2V0cywgd2UgY2FuIGRpc3RpbGwgdGhlIGVzc2VudGlhbCBwYXR0ZXJucyBvZiBj b21tdW5pY2F0aW9uDQogYmV0d2VlbiBlbmRwb2ludHMgc28gZmFyIHRoYXQgdGhleSBjYW4gaW5k ZWVkIGdyb3cgYWxvbmcgd2l0aCBmdXR1cmUgbmV0d29yayBwcm90b2NvbCBpbm5vdmF0aW9ucy48 YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KVG9tbXk8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTm92IDE2LCAyMDE2LCBhdCAxMDo0OCBB TSwgQnJpYW4gVHJhbW1lbGwgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQHRyYW1tZWxsLmNoIj5p ZXRmQHRyYW1tZWxsLmNoPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KSGksIGFsbCw8YnI+DQo8 YnI+DQpMb29raW5nIGF0IHdoZXJlIHdlIGFyZSBpbiB0aGUgYWdlbmRhLCB3ZSdyZSBub3QgZ29p bmcgdG8gZ2V0IHRvIHRhbGsgYWJvdXQgUG9zdCBTb2NrZXRzIGluIHRoZSBtZWV0aW5nIGluIFNl b3VsIHRvZGF5LiBBcyBtb3N0IG9mIHRoZSBwcm9wZXJ0aWVzIG9mIHRoZSBBUEkgYXJlIGFscmVh ZHkgYmVpbmcgZGlzY3Vzc2VkIGR1cmluZyBDb2xpbidzIHByZXNlbnRhdGlvbiwgdGhpcyBpc24n dCB0aGF0IGJpZyBhIGRlYWwuIEhvd2V2ZXIsIGlmIGFueW9uZQ0KIHdobyBoYXMgcmVhZCBkcmFm dC10cmFtbWVsbC1wb3N0LXNvY2tldHMgd291bGQgbGlrZSB0byB0YWxrIHRvIHVzIGFib3V0IGl0 IGhlcmUgaW4gU2VvdWwsIHBsZWFzZSBkcm9wIG1lIGEgbGluZS48YnI+DQo8YnI+DQpUbyBhbnN3 ZXIgWmFoZWQncyBxdWVzdGlvbiBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBtZWV0aW5nOiB3ZSBk aWRuJ3QgY2FsbCB0aGlzIGRyYWZ0LXRyYW1tZWxsLXRhcHMtcG9zdC1zb2NrZXRzIGJlY2F1c2Ug aXQncyBub3QgY2xlYXIgdGhhdCBpdCdzIHJlYWxseSBpbiBzY29wZSBmb3IgVEFQUy4gSXQgcHJl c2VudHMgYSByYWRpY2FsbHkgY2hhbmdlZCByZXBsYWNlbWVudCBpbiB0aGUgYWJzdHJhY3QgZm9y IHRoZSBzb2NrZXRzIEFQSS4gSG93ZXZlciwNCiBpZiB0aGUgd29ya2luZyBncm91cCBpcyBpbnRl cmVzdGVkIGluIGNvbnRpbnVpbmcgdG8gZGlzY3VzcyBpdCwgd2UncmUgaGFwcHkgdG8gcmVzdWJt aXQgYXMgZHJhZnQtdHJhbW1lbGwtdGFwcy1wb3N0LXNvY2tldHMgaWYgaXQgbWFrZXMgdGhpbmdz IGVhc2llciB0byBmb2xsb3cuIDopPGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NCjxicj4NCkJyaWFu PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpUYXBzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUYXBzQGlldGYu b3JnIj5UYXBzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdGFwcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby90YXBzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpUYXBzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUYXBzQGll dGYub3JnIj5UYXBzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdGFwcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90YXBzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM3PR07MB292691BF665C189964158279FB10AM3PR07MB292eurprd_-- From nobody Fri Nov 18 09:38:46 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A18512949A for ; Fri, 18 Nov 2016 09:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTzT3miZD7mG for ; Fri, 18 Nov 2016 09:38:42 -0800 (PST) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0633129453 for ; Fri, 18 Nov 2016 09:38:42 -0800 (PST) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out01.uio.no with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1c7n7X-0005y6-Sh for taps@ietf.org; Fri, 18 Nov 2016 18:38:39 +0100 Received: from [58.123.138.206] (helo=[10.35.133.12]) by mail-mx3.uio.no with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.80) (envelope-from ) id 1c7n7K-0008Ba-Ca for taps@ietf.org; Fri, 18 Nov 2016 18:38:37 +0100 From: Michael Welzl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: Date: Sat, 19 Nov 2016 02:38:22 +0900 To: "taps@ietf.org" X-Mailer: Apple Mail (2.3251) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 4 sum rcpts/h 8 sum msgs/h 7 total rcpts 48954 max rcpts/h 54 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: AAC13780A76071A4E39A24767B9942B660B91BF4 X-UiO-SPAM-Test: remote_host: 58.123.138.206 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 18 max/h 4 blacklist 0 greylist 0 ratelimit 0 Archived-At: Subject: [Taps] TAPS: update from NEAT X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Nov 2016 17:38:45 -0000 Dear all, I just wanted to point the mailing list to our slides that we didn=E2=80=99= t get to present: = https://www.ietf.org/proceedings/97/slides/slides-97-taps-taps-related-top= ics-from-the-neat-project-naeem-khademi-00.pdf Maybe there=E2=80=99s a chance next time for an update? We NEATers saw significant overlap between Apple=E2=80=99s = implementation described by Tommy Pauly at the meeting ( = https://www.ietf.org/proceedings/97/slides/slides-97-taps-moving-beyond-so= ckets-architecture-and-observations-tommy-pauly-apple-00.pdf ) and our approach - which, we think, is a very cool thing! Cheers, Michael From nobody Mon Nov 21 08:30:47 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559BF129480 for ; Mon, 21 Nov 2016 08:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrYUeAxDFRZ6 for ; Mon, 21 Nov 2016 08:30:43 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E7061288B8 for ; Mon, 21 Nov 2016 08:30:43 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id p16so205775735qta.0 for ; Mon, 21 Nov 2016 08:30:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/kopEKTmFATaj+MhUcVWfMefCe7znayU2o+hTiUM3qE=; b=TEuyeNsD9g3AAtZUr+OnTvLLn0JeLYN6fzYgwBD7jSbYrwW/xjejWaf4bUrNGk5V51 BB7Bcr6FC2uvw+k7t4QtpTzLusY8e/f3kGokAg2nJupjwlpVPsLw2wCKLn2xTOksYVn9 yDpFAsTnQhaJafO5KUqzBlqevbN0fBeVFrONtYKfpqV6AkYIBrUc3Mk/cI37H6+oZBpo vC0DexHtTCbP8goETEdYQ1lPVDRRi9arR3mz3GIl4e1nLGEO2Cv6axy2GF9PTO3M7wGv 9GXKTolhJXYDQdtCN0LtccPnLeji+b4ps1aL3ugsULOZUcAiTw0VwnL5ANaR4QrDFdTz 9LgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/kopEKTmFATaj+MhUcVWfMefCe7znayU2o+hTiUM3qE=; b=WrZXx1qVGzg1dlaEXJ67AVN5mpuD9eY/BMW2sD/FQVHBpqbK0myf/6EEbcIQAugKt8 dqDBp35aaMndeUN4nk/9lF1+2esN2aY0NqRJukJ3q++Ez9bZHvAasZrrcRqLvI7NNigN jQMdtBdALu/1+EvJzwoFvB1W7MIsb/9wBqsDk7hCbMF1Ula7t4s3DURyUZVmZ88mK4rQ pOIkXNSPuEB5Livixz78BxHKJvrp4uOAXGyN7mQuz/8dIvGks2BaEF3XACDLwjkG5XA7 xecNHoNz67ihp95ry35GqXdz/tkxza0FBfTAw+ghLYw6Y4E1u1c+4Zp9p0GZTEmUfzmG toQA== X-Gm-Message-State: AKaTC03OzUghdljYc985iMSGMjXDTYp5cjsM9t5J/fUk0VIrwYcNmBbsE2b7d6Bnup6v+A== X-Received: by 10.200.40.204 with SMTP id j12mr8704259qtj.284.1479745842356; Mon, 21 Nov 2016 08:30:42 -0800 (PST) Received: from bos-mpy2z.kendall.corp.akamai.com ([72.246.0.14]) by smtp.gmail.com with ESMTPSA id f66sm11572961qkj.23.2016.11.21.08.30.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 21 Nov 2016 08:30:41 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Aaron Falk In-Reply-To: Date: Mon, 21 Nov 2016 11:30:41 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Michael Welzl X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "taps@ietf.org" Subject: Re: [Taps] TAPS: update from NEAT X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 16:30:45 -0000 Yes, of course Michael, you=E2=80=99ll get some time on the Chicago = agenda. Again, my apologies for mis-managing the meeting. =20 =E2=80=94aaron > On Nov 18, 2016, at 12:38 PM, Michael Welzl = wrote: >=20 > Dear all, >=20 > I just wanted to point the mailing list to our slides that we didn=E2=80= =99t get to present: > = https://www.ietf.org/proceedings/97/slides/slides-97-taps-taps-related-top= ics-from-the-neat-project-naeem-khademi-00.pdf >=20 > Maybe there=E2=80=99s a chance next time for an update? >=20 > We NEATers saw significant overlap between Apple=E2=80=99s = implementation described by Tommy Pauly at the meeting > ( = https://www.ietf.org/proceedings/97/slides/slides-97-taps-moving-beyond-so= ckets-architecture-and-observations-tommy-pauly-apple-00.pdf ) > and our approach - which, we think, is a very cool thing! >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Nov 22 03:46:07 2016 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A74781299C0; Tue, 22 Nov 2016 03:45:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.38.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147981515963.9195.500696488322232793.idtracker@ietfa.amsl.com> Date: Tue, 22 Nov 2016 03:45:59 -0800 Archived-At: Cc: aaron.falk@gmail.com, draft-ietf-taps-transports@ietf.org, taps-chairs@ietf.org, taps@ietf.org Subject: [Taps] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Abstain_on_draft-ietf-t?= =?utf-8?q?aps-transports-12=3A_=28with_COMMENT=29?= X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 11:46:01 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-taps-transports-12: Abstain 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm a co-author. From nobody Tue Nov 22 03:50:12 2016 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBFF1299C8; Tue, 22 Nov 2016 03:50:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.38.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147981540687.9179.17289664194566492679.idtracker@ietfa.amsl.com> Date: Tue, 22 Nov 2016 03:50:06 -0800 Archived-At: Cc: aaron.falk@gmail.com, draft-ietf-taps-transports@ietf.org, taps-chairs@ietf.org, taps@ietf.org Subject: [Taps] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Recuse_on_draft-ietf-ta?= =?utf-8?q?ps-transports-12=3A_=28with_COMMENT=29?= X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 11:50:07 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-taps-transports-12: Recuse 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm a co-author. From nobody Mon Nov 28 12:49:03 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576D4129546; Mon, 28 Nov 2016 12:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.396 X-Spam-Level: X-Spam-Status: No, score=-3.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIb_edSQUDYa; Mon, 28 Nov 2016 12:49:00 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A68C129492; Mon, 28 Nov 2016 12:49:00 -0800 (PST) Received: from unnumerable.local ([47.186.56.40]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uASKmxTY018548 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Mon, 28 Nov 2016 14:48:59 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [47.186.56.40] claimed to be unnumerable.local To: General Area Review Team , taps@ietf.org, draft-ietf-taps-transports.all@ietf.org References: <2622b864-acce-d442-ab1a-4cc5808868d3@nostrum.com> From: Robert Sparks Message-ID: <431806df-63fe-c45c-5b26-c2e79394e6ad@nostrum.com> Date: Mon, 28 Nov 2016 14:48:59 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <2622b864-acce-d442-ab1a-4cc5808868d3@nostrum.com> Content-Type: multipart/alternative; boundary="------------51C45359AC641786EB62FA60" Archived-At: Subject: Re: [Taps] Gen-art LC review: draft-ietf-taps-transports-11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2016 20:49:01 -0000 This is a multi-part message in MIME format. --------------51C45359AC641786EB62FA60 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-taps-transports-12 Reviewer: Robert Sparks Review Date: 28 Nov 2016 IETF LC End Date: 9 Sep 2016 IESG Telechat date: 1 Dec 2016 Summary: Ready for publication as an Informational RFC Thanks for addressing the nits I commented on in -11. --------------51C45359AC641786EB62FA60 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-taps-transports-12
Reviewer: Robert Sparks
Review Date: 28 Nov 2016
IETF LC End Date: 9 Sep 2016
IESG Telechat date: 1 Dec 2016

Summary: Ready for publication as an Informational RFC

Thanks for addressing the nits I commented on in -11.
--------------51C45359AC641786EB62FA60-- From nobody Tue Nov 29 20:24:52 2016 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED9F129CDB; Tue, 29 Nov 2016 20:24:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Suresh Krishnan" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.38.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148047985416.11748.10342727934503959574.idtracker@ietfa.amsl.com> Date: Tue, 29 Nov 2016 20:24:14 -0800 Archived-At: Cc: aaron.falk@gmail.com, draft-ietf-taps-transports@ietf.org, taps-chairs@ietf.org, taps@ietf.org Subject: [Taps] Suresh Krishnan's No Objection on draft-ietf-taps-transports-12: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 04:24:46 -0000 Suresh Krishnan has entered the following ballot position for draft-ietf-taps-transports-12: 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for writing this document. I found it to be very useful summary of the transport protocols. * Section 3.1 Missing the Abort command. * Section 3.3 Why does UDP has a reference to the base IPv6 spec [RFC2460]? Is this for the pseudo-header calculation? If so, it needs to be added to TCP as well. * Section 3.3.1 - Might be worthwhile adding a reference to RFC6936 as well to explain the applicability of UDP zero checksums in IPv6. e.g. OLD: IPv6 does not permit UDP datagrams with no checksum, although in certain cases this rule may be relaxed [RFC6935]. NEW: IPv6 does not permit UDP datagrams with no checksum, although in certain cases [RFC6936] this rule may be relaxed [RFC6935]. The following sentence at the end of Page 11 seems incomplete Applications that need to provide fragmentation * Section 3.12 The reference for ICMPv6 is wrong. It should be RFC4443 instead of RFC4433 as stated in the draft. * Section 3.12.1 RFC1716 has long been obsoleted by RFC1812. Is there any reason to use the old router requirement spec? * Section 5 ICMP can be used with multicast addresses as well. From nobody Wed Nov 30 12:18:26 2016 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C5129129B20; Wed, 30 Nov 2016 12:18:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148053710476.9666.10162670717986574082.idtracker@ietfa.amsl.com> Date: Wed, 30 Nov 2016 12:18:24 -0800 Archived-At: Cc: aaron.falk@gmail.com, draft-ietf-taps-transports@ietf.org, taps-chairs@ietf.org, taps@ietf.org Subject: [Taps] Alissa Cooper's No Objection on draft-ietf-taps-transports-12: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 20:18:25 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-taps-transports-12: 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In Section 3.7, it seems like a reference to draft-ietf-tls-tls13 is warranted. From nobody Wed Nov 30 14:40:19 2016 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62501129BB4; Wed, 30 Nov 2016 14:40:13 -0800 (PST) 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: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148054561336.9698.4824027339203861305.idtracker@ietfa.amsl.com> Date: Wed, 30 Nov 2016 14:40:13 -0800 Archived-At: Cc: aaron.falk@gmail.com, draft-ietf-taps-transports@ietf.org, taps-chairs@ietf.org, taps@ietf.org Subject: [Taps] Stephen Farrell's Yes on draft-ietf-taps-transports-12: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 22:40:13 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-taps-transports-12: 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for a useful document. I think this will be quite informative for many people so please consider my comments below as just suggestions offered for consideration, and it's entirely fine if you'd rather not even think about 'em. (I can well imagine that a document like this could be polished forever and never finished.) - abstract: Having finished a first read of this I don't find the "classifies" and "compares" claims from the abstract to have really been met. - end of p11 - seems like a truncated paragraph there or something. - 3.5 (and to a lesser extent 3.6): This reads to me as if the authors regret that the world hasn't adopted the SCTP (resp. DCCP) as "planned." There's no particular action following from that, but we might want to consider whether or not that's the impression we want readers to get. I think it might be a tiny bit better to do a pass to try make the language in those bits more neutral. - 3.7: I agree with Alissa that referring to the TLS1.3 draft would be good. SSL can also be referred to via RFC6101. It'd be a little better to refer to RFC7525 as BCP195 I think. - 3.7.2: I think it'd be good to consider whether or not this should describe the so-called 0RTT feature of TLS1.3. That is a dangerous implement that could be usefully covered in this document as informing likely readers of this about how to properly use (or more importantly, not use) that new "feature" could be well worth while. - 3.7.2: The mention of RNGs here is a bit odd. Those aren't usually an external interface but rather a dependency that the implementation has on the system/OS. Similar things didn't seem to be mentioned in other equivalent sections. You also don't say that there's no standard API. There was also a relatively recent paper on how awful TLS cert APIs are and how those damage security that might be worth a reference. [1] This section could maybe do with a little more work. (If you want to, I'm nowhere near trying to insist.) [1] https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html - 3.9.1: Cookies as "MIME headers"? Huh? Was this text checked over by some HTTP folks? That sentence makes me think 3.9 might need some more checking. - 3.10.2: Seems odd to have URLs here for non-maintained implementations of a rarely used protocol when the same wasn't provided for very widely used protocols. - 3.10 and 3.11: It wasn't clear to me why it's useful to include these. - 3.12: This seems oddly placed and I'm not clear why it's worth including ICMP but not DNS or CDNs or load balancing or issues related to head of line blocking. From nobody Wed Nov 30 14:54:58 2016 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F26C7129BA9; Wed, 30 Nov 2016 14:54:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148054649197.9698.16116293523331885712.idtracker@ietfa.amsl.com> Date: Wed, 30 Nov 2016 14:54:51 -0800 Archived-At: Cc: aaron.falk@gmail.com, draft-ietf-taps-transports@ietf.org, taps-chairs@ietf.org, taps@ietf.org Subject: [Taps] Ben Campbell's Yes on draft-ietf-taps-transports-12: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2016 22:54:53 -0000 Ben Campbell has entered the following ballot position for draft-ietf-taps-transports-12: 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.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-transports/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just a few very minor comments: - 1, 2nd paragraph: Would it make sense to include citations for things like NewReno, TFRC, and LEDBAT? - 3.5.1, 2nd to last paragraph: Would a citation to WebRTC (perhaps the overview or the transports draft)? -3.5.2, paragraph starting with "For the following SCTP protocol extensions the BSD Sockets API..." The paragraph is hard to parse.