From nobody Wed Sep 3 14:30:10 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45831A700F; Wed, 3 Sep 2014 14:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.5 X-Spam-Level: X-Spam-Status: No, score=-100.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YRAwyHRUi1A; Wed, 3 Sep 2014 14:30:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACF7D1A872B; Wed, 3 Sep 2014 14:25:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Adrian Farrel" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140903212553.27060.91654.idtracker@ietfa.amsl.com> Date: Wed, 03 Sep 2014 14:25:53 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/esjq-E1dYggmybAx67jMJM5KXRA Cc: taps@ietf.org Subject: [Taps] Adrian Farrel's No Objection on charter-ietf-taps-00-02: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 21:30:07 -0000 Adrian Farrel has entered the following ballot position for charter-ietf-taps-00-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-taps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Wow, nearly every word of this text has changed since the IESG saw it last! I continue to have no objection to the formation of this WG, but I have some wordwmithing suggestions. --- You have two tones of the word "provided" in the following... We use the term "Transport Service" to mean an end-to-end facility provided by the transport layer that can only be correctly provided with information from the application. This information may be provided at design time, compile time, or run time and may include guidance from the application on whether the facility in question is required or simply a preference by the application. "...provided with information" means "...given information". This is reinforced by the next sentence saying "This informaiton is provided", but you mean that it is the service that can only be correctly provided if... Furthermore, it is the service that is provided not the layer! I suggest... We use the term "Transport Service" to mean an end-to-end facility provided by the transport layer. That service can only be provided correctly if information is supplied from the application. This information may be supplied at design time, compile time, or run time and may include guidance from the application on whether the facility in question is required or simply a preference by the application. Finally, it is not clear what is being deisgned, compiled, or run. I think you need to clarify that as well. --- Four examples of Transport Services are reliable delivery, no guarantee of order preservation, content privacy to in-path devices, and minimal latency. Hmmm, "no guarantee" is a service? Where can I sign up for that? I think it is a service level. The service is "ordered delivery of data". --- I think you have to decide whether you want to consider HTTP as a transport protocol or an application protocol (or call it out as both). Currently you have... Many firewalls only pass TCP and UDP and some only support HTTP over TCP. ...implying HTTP is a protocol carried by a transport protocol. An impression reinforced by not including it in the previous list of transport protocols. But then... Applications, therefore, must always be able to fall back to TCP or UDP, or even HTTP in many cases, and once the application programmer has committed to making an application work on TCP or UDP or HTTP, there is little incentive to try other transport protocols before falling back. ...with "fall back to ... HTTP" implying HTTP is a transport protocol. --- how to discover which protocols are available for a given connection. I wonder whether "connection" is the right word. I think you probably mean "for the selected service between a given pair of end points." --- TAPS is not chartered to perform detailed analysis of the security aspects of transport protocols This is fine, but will people lose track of the fact that security is a transport service? From nobody Thu Sep 4 04:07:33 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1561A06A3; Thu, 4 Sep 2014 04:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRokptiBP5DP; Thu, 4 Sep 2014 04:07:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B509F1A6F0C; Thu, 4 Sep 2014 04:07:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140904110723.26312.68882.idtracker@ietfa.amsl.com> Date: Thu, 04 Sep 2014 04:07:23 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/CwNV2ghzWS0Ca7jb3Xrhv1l6X8g Cc: taps@ietf.org Subject: [Taps] Benoit Claise's No Objection on charter-ietf-taps-00-02: (with COMMENT) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 11:07:25 -0000 Benoit Claise has entered the following ballot position for charter-ietf-taps-00-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/charter-ietf-taps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) Define a set of Transport Services, prioritizing those provided by existing IETF protocols and congestion control mechanisms. As a starting point, the working group will consider services used between two endpoints. What does "prioritizing" mean in the above sentence? If I take your 4 examples (reliable delivery, no guarantee of order preservation (*) content privacy to in-path devices, and minimal latency.), how can you prioritize those? You can't, it's purely an application programmers choice. Or maybe I missed something? Don't you mean "identifying" instead of "prioritizing", or maybe "identifying the most common ones" (*) btw, same remark as Adrian wrt "no" guarantee of order preservation as a service From nobody Tue Sep 9 09:17:35 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0281A1A6FFD for ; Tue, 9 Sep 2014 09:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.902 X-Spam-Level: X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwDpj91g5VEp for ; Tue, 9 Sep 2014 09:17:31 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9EADC1A6FFA for ; Tue, 9 Sep 2014 09:17:29 -0700 (PDT) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) by trammell.ch (Postfix) with ESMTPSA id A6A181A0446 for ; Tue, 9 Sep 2014 18:17:27 +0200 (CEST) From: Brian Trammell Content-Type: multipart/signed; boundary="Apple-Mail=_D9D9D55C-E615-4BBB-9994-779ABE9FB6A9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 9 Sep 2014 18:17:29 +0200 References: <9D725DD0-7136-4D02-99E0-48E03C173C9E@iab.org> To: taps WG Message-Id: <2A1A7030-B24F-459A-A568-0B83F9F669CD@trammell.ch> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/wHklzK86qbvm825JDG3AGM6EFlY Subject: [Taps] Fwd: Call for Papers: IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 16:17:34 -0000 --Apple-Mail=_D9D9D55C-E615-4BBB-9994-779ABE9FB6A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Greetings, all, FYI, for those of you not on ietf-announce... Cheers, Brian Begin forwarded message: > From: IAB Chair > Subject: Call for Papers: IAB Workshop on Stack Evolution in a = Middlebox Internet (SEMI) > Date: 9 Sep 2014 18:09:43 GMT+2 > To: IETF Announce > Cc: IAB , IETF > Reply-To: IAB >=20 > IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI) > 26-27 January 2015 =96 ETH Z=FCrich, Switzerland >=20 > The Internet=92s transport layer has ossified, squeezed between narrow=20= > interfaces (from BSD sockets to pseudo-transport over HTTPS) and=20 > increasing in-network modification of traffic by middleboxes that make=20= > assumptions about the protocols running through them. This = ossification=20 > makes it difficult to innovate in the transport layer, through the=20 > deployment of new protocols or the extension of existing ones. At the=20= > same time, emerging applications require functionality that existing=20= > protocols can provide only inefficiently, if at all. >=20 > To begin to address this problem, the Internet Architecture Board = (IAB),=20 > within the scope of its IP Stack Evolution Program, is organizing a=20 > workshop to discuss approaches to de-ossifying transport, especially=20= > with respect to interactions with middleboxes and new methods for=20 > implementing transport protocols. Recognizing that the end-to-end=20 > principle has long been compromised, we start with the fundamental=20 > question of matching paths through the Internet with certain=20 > characteristics to application and transport requirements. Which paths=20= > through the Internet are actually available to applications? Which=20 > transports can be used over these paths? How can applications = cooperate=20 > with network elements to improve path establishment and discovery? Can=20= > common transport functionality and standardization help application=20 > developers to implement and deploy such approaches in today=92s = Internet?=20 > Could cooperative approaches give us a way to rebalance the Internet=20= > back toward its end-to-end roots? >=20 > Topics >=20 > For this workshop we would like to consider topics that speak to these=20= > questions, including the following: >=20 > - Development and deployment of transport-like features in = application- > layer protocols > - Methods for discovery of path characteristics and protocol=20 > availability along a path > - Methods for middlebox detection and characterization of middlebox=20 > behavior and functionality > - Methods for NAT and middlebox traversal in the establishment of end- > to-end paths > - Mechanisms for cooperative path-endpoint signaling, and lessons=20 > learned from existing approaches > - Economic considerations and incentives for cooperation in middlebox=20= > deployment >=20 > We will explicitly focus on approaches that are incrementally = deployable=20 > within the present Internet. >=20 > The outcome of the workshop will be architectural and engineering=20 > guidance on future work in the area, published as an IAB workshop=20 > report, based on discussion of proposed approaches; future work will = be=20 > pursued within the IAB Stack Evolution Program. We will also explore=20= > possible areas for standardization, e.g. new protocols that separate=20= > signaling to and from on-path devices and common transport semantics=20= > from the rest of the transport protocol; and for general guidance, = e.g.=20 > how transports as well as middleboxes can be designed and deployed to=20= > achieve these goals. >=20 > Submission Instructions >=20 > Attendance at the workshop is by invitation. Prospective participants=20= > are invited to submit short position papers outlining their views on = one=20 > or more topics related to the scope of the workshop. Position papers=20= > will be published on the IAB website at:=20 > http://www.iab.org/activities/workshops/semi/. >=20 > Submissions accepted at:=20 > https://www.easychair.org/conferences/?conf=3Dsemi2015 >=20 > Submission Deadline: 31 October 2014 >=20 > Notification Deadline: 17 November 2014 >=20 > Workshop Dates: 26-27 January 2015 >=20 > Sponsored by the Internet Architecture Board, the Internet Society, = and=20 > ETH Z=FCrich. Mirja K=FChlewind and Brian Trammell, General Chairs. --Apple-Mail=_D9D9D55C-E615-4BBB-9994-779ABE9FB6A9 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 iQEcBAEBCgAGBQJUDygZAAoJENt3nsOmbNJc5WoH/2ABaq7VjsKTHU7XET1E5grs 3exUABGJ/CAmfrKnyEAogY2sPJoYVdHTOPG7gUAxBQMUOhKFPxXhOUjiJQ43WRyN aD+Z/2lm1Anba6puFv76XZkq5p/DCoRST9YR/8T6zrV+09aIOtDD4i8D4xdYFk9b y0gzs3kqzD39h0dTbRiofsMsyakJJs1HKESTUdqS1gdbqmA6cYwGbjV0RCHBHvnr 61eNN7GopPAlXVJeNofrQYG/V5vcr8AtjDxCmwKPMs0O8Ad2LBJaP0PV6Sw+bOz1 YBTMa2lgxbdFaLjqwOOkmfDjUCvubsGY5Jp0m8VCVc0ixmxgFE6uDQ5xy3Sc8W4= =Vqw6 -----END PGP SIGNATURE----- --Apple-Mail=_D9D9D55C-E615-4BBB-9994-779ABE9FB6A9-- From nobody Wed Sep 24 00:19:45 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863A31A1B94; Tue, 23 Sep 2014 16:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham 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 vFeeWFzCZ09J; Tue, 23 Sep 2014 16:33:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC5A1A8965; Tue, 23 Sep 2014 16:33:25 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140923233325.32456.9852.idtracker@ietfa.amsl.com> Date: Tue, 23 Sep 2014 16:33:25 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/THL77CDcpdM2hWAnWuQ5ism6hN0 X-Mailman-Approved-At: Wed, 24 Sep 2014 00:19:44 -0700 Cc: taps WG Subject: [Taps] WG Action: Formed Transport Services (taps) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 23:33:28 -0000 A new IETF working group has been formed in the Transport Area. For additional information please contact the Area Directors or the WG Chair. Transport Services (taps) ------------------------------------------------ Current Status: Proposed WG Chairs: Aaron Falk Assigned Area Director: Spencer Dawkins Mailing list Address: taps@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/taps Archive: http://www.ietf.org/mail-archive/web/taps/ Charter: Most Internet applications make use of the Transport Services provided by TCP (a reliable, in-order stream protocol) or UDP (an unreliable datagram protocol). We use the term "Transport Service" to mean an end-to-end facility provided by the transport layer. That service can only be provided correctly if information is supplied from the application. The application may determine the information to be supplied at design time, compile time, or run time and may include guidance on whether the facility in question is required or simply a preference by the application. Four examples of Transport Services are reliable delivery, ordered delivery of data, content privacy to in-path devices, and minimal latency. Transport protocols such as SCTP, DCCP, WebSockets, MPTCP, and UDP-Lite and the LEDBAT congestion control mechanism extend the set of available Transport Services beyond those provided to applications by TCP and UDP. For example, SCTP provides potentially faster reliable delivery for applications than TCP because it can accept blocks of data out of order, and LEDBAT provides low-priority "scavenger" communication. However, application programmers face difficulty when they use protocols other than TCP or UDP. Most network stacks ship with only TCP and UDP as transport protocols. Many firewalls only pass TCP and UDP and some only allow TCP when it carries HTTP as its payload. As a result, using other transport protocols or building a new protocol over raw sockets risks having an application not work in many environments. Applications, therefore, must always be able to fall back to TCP or UDP, or even to using HTTP as a transport substrate in some cases, and once the application programmer has committed to making an application work on TCP or UDP or HTTP, there is little incentive to try other transport protocols before falling back. Further, different protocols can provide the same services in different ways. Layering decisions must also be made (for example, whether a protocol is used natively or tunneled through UDP). Because of these complications, programmers often resort to either using TCP or HTTP or implementing their own customized "transport services" over UDP. When application developers re-implement transport features already available elsewhere they open the door to problems that simply using TCP would have avoided and ensure that the applications can't benefit from other transport protocols as they become available. And, since even TCP and UDP are not guaranteed to work in all environments today, some programmers simply give up on using TCP or UDP directly, relying instead on "HTTP as a Substrate". BCP 56 identified many issues with this strategy, but assuming that if "any protocol is available on a given network path and on the hosts that will be communicating, that protocol will be HTTP" is a reasonable strategy for today's Internet. The IESG has agreed with this viewpoint enough to publish the WebSocket protocol on the standards track. The goal of the TAPS working group is to help application and network stack programmers by describing an (abstract) interface for applications to make use of Transport Services. The Working Group deliverables emphasize defining Transport Services that are important to applications followed by experimental mechanisms to a) determine if the protocols to provide the requested services are available on the end points and supported along the path in the network and b) fall back, i.e., select alternate, possibly less-preferred, protocols when desired protocols are not available. The Working Group will not define a richer set of Transport Services for applications, although the TAPS deliverables could inform proposals for future chartered work on Transport Services. The Working Group will: 1) Define a set of Transport Services, identifying the services provided by existing IETF protocols and congestion control mechanisms. As a starting point, the working group will consider services used between two endpoints. 2) Specify the subset of those Transport Services, as identified in item 1, that end systems supporting TAPS will provide, and give guidance on choosing among available mechanisms and protocols. Note that not all the capabilities of IETF Transport protocols need to be exposed as Transport Services. 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. The following topics are out of scope for this Working Group: - Signaling-based Quality-of-Service (QoS) mechanisms - Definition of new encapsulations and tunneling mechanisms - Extension, modification, or creation of transport protocols - Language-specific APIs TAPS is not chartered to perform detailed analysis of the security aspects of transport protocols. While security can be a transport service, TAPS is being chartered almost simultaneously with TCPINC, which is developing the TCP extensions to provide unauthenticated encryption and integrity protection of TCP streams, and TAPS will work with TCPINC to ensure that TAPS will be able to accommodate the protocol extensions that TCPINC defines. Milestones: Jun 2015 - Submit an Informational document to the IESG defining a set of services provided by IETF transport protocols and congestion control mechanisms Dec 2015 - Submit an Informational document to the IESG recommending a minimal set of Transport Services that end systems should support Mar 2016 - Submit an Experimental document to the IESG specifying one or more methods to provide applications with the Transport Services identified by the WG Mar 2016 - Recharter or conclude. From nobody Wed Sep 24 02:59:54 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2411A6F96 for ; Wed, 24 Sep 2014 02:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIHkhZAr70Ah for ; Wed, 24 Sep 2014 02:59:50 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC13D1A6EE5 for ; Wed, 24 Sep 2014 02:59:49 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1XWjMR-0000WN-Ja for taps@ietf.org; Wed, 24 Sep 2014 11:59:47 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1XWjMQ-0000h3-Te for taps@ietf.org; Wed, 24 Sep 2014 11:59:47 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Michael Welzl In-Reply-To: <20140923233325.32456.9852.idtracker@ietfa.amsl.com> Date: Wed, 24 Sep 2014 11:59:46 +0200 Content-Transfer-Encoding: 7bit Message-Id: <6207133D-FE6E-43C8-B52F-0991336E7737@ifi.uio.no> References: <20140923233325.32456.9852.idtracker@ietfa.amsl.com> To: taps WG X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 3 sum rcpts/h 13 sum msgs/h 7 total rcpts 20597 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 90C5AE99E48061EC3143EB66CB861FBDAF9CF81F X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 6197 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/BBGOxHDjce1TdV_s3Xq1BuEQ8Kg Subject: Re: [Taps] WG Action: Formed Transport Services (taps) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 09:59:53 -0000 Hooray! Thanks everyone for your efforts!! On 24. sep. 2014, at 01:33, The IESG wrote: > A new IETF working group has been formed in the Transport Area. For > additional information please contact the Area Directors or the WG Chair. > > Transport Services (taps) > ------------------------------------------------ > Current Status: Proposed WG > > Chairs: > Aaron Falk > > Assigned Area Director: > Spencer Dawkins > > Mailing list > Address: taps@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/taps > Archive: http://www.ietf.org/mail-archive/web/taps/ > > Charter: > > Most Internet applications make use of the Transport Services > provided by TCP (a reliable, in-order stream protocol) or UDP > (an unreliable datagram protocol). We use the term "Transport > Service" to mean an end-to-end facility provided by the > transport layer. That service can only be provided correctly if > information is supplied from the application. The application may > determine the information to be supplied at design time, > compile time, or run time and may include guidance on whether > the facility in question is required or simply a preference by the > application. Four examples of Transport Services are reliable > delivery, ordered delivery of data, content privacy to in-path > devices, and minimal latency. > > Transport protocols such as SCTP, DCCP, WebSockets, MPTCP, and > UDP-Lite and the LEDBAT congestion control mechanism extend the > set of available Transport Services beyond those provided to > applications by TCP and UDP. For example, SCTP provides potentially > faster reliable delivery for applications than TCP because it can > accept blocks of data out of order, and LEDBAT provides low-priority > "scavenger" communication. > > However, application programmers face difficulty when they use > protocols other than TCP or UDP. Most network stacks ship with only > TCP and UDP as transport protocols. Many firewalls only pass TCP > and UDP and some only allow TCP when it carries HTTP as its payload. > As a result, using other transport protocols or building a new protocol > over raw sockets risks having an application not work in many > environments. Applications, therefore, must always be able to fall back > to TCP or UDP, or even to using HTTP as a transport substrate in some > cases, and once the application programmer has committed > to making an application work on TCP or UDP or HTTP, there is little > incentive to try other transport protocols before falling back. > Further, different protocols can provide the same services in different > ways. Layering decisions must also be made (for example, whether a > protocol is used natively or tunneled through UDP). > > Because of these complications, programmers often resort to either > using TCP or HTTP or implementing their own customized "transport > services" over UDP. When application developers re-implement transport > features already available elsewhere they open the door to problems > that simply using TCP would have avoided and ensure that the > applications can't benefit from other transport protocols as they > become available. And, since even TCP and UDP are not guaranteed to > work in all environments today, some programmers simply give up on > using TCP or UDP directly, relying instead on "HTTP as a Substrate". > BCP 56 identified many issues with this strategy, but assuming that > if "any protocol is available on a given network path and on the hosts > that will be communicating, that protocol will be HTTP" is a reasonable > strategy for today's Internet. The IESG has agreed with this viewpoint > enough to publish the WebSocket protocol on the standards track. > > The goal of the TAPS working group is to help application and network > stack programmers by describing an (abstract) interface for applications > to make use of Transport Services. The Working Group deliverables > emphasize defining Transport Services that are important to applications > followed by experimental mechanisms to a) determine if the protocols to > provide the requested services are available on the end points and > supported along the path in the network and b) fall back, i.e., select > alternate, possibly less-preferred, protocols when desired protocols > are not available. The Working Group will not define a richer set of > Transport Services for applications, although the TAPS deliverables > could inform proposals for future chartered work on Transport Services. > > The Working Group will: > > 1) Define a set of Transport Services, identifying the > services provided by existing IETF protocols and congestion > control mechanisms. As a starting point, the working group will > consider services used > between two endpoints. > > 2) Specify the subset of those Transport Services, as identified > in item 1, that end systems supporting TAPS will provide, and > give guidance on choosing among available mechanisms and > protocols. Note that not all the capabilities of IETF Transport > protocols need to be exposed as Transport Services. > > 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. > > The following topics are out of scope for this Working Group: > > - Signaling-based Quality-of-Service (QoS) mechanisms > > - Definition of new encapsulations and tunneling mechanisms > > - Extension, modification, or creation of transport protocols > > - Language-specific APIs > > TAPS is not chartered to perform detailed analysis of the security > aspects of transport protocols. While security can be a transport > service, TAPS is being chartered almost simultaneously with TCPINC, > which is developing the TCP extensions to provide unauthenticated > encryption and integrity protection of TCP streams, and TAPS will > work with TCPINC to ensure that TAPS will be able to accommodate > the protocol extensions that TCPINC defines. > > Milestones: > Jun 2015 - Submit an Informational document to the IESG defining a set > of services provided by IETF transport protocols and congestion control > mechanisms > Dec 2015 - Submit an Informational document to the IESG recommending a > minimal set of Transport Services that end systems should support > Mar 2016 - Submit an Experimental document to the IESG specifying one > or more methods to provide applications with the Transport Services > identified by the WG > Mar 2016 - Recharter or conclude. > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed Sep 24 03:47:28 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7951A6FCF for ; Wed, 24 Sep 2014 03:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TodCeE0B75cS for ; Wed, 24 Sep 2014 03:47:24 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4731A1A7E for ; Wed, 24 Sep 2014 03:47:22 -0700 (PDT) X-AuditID: 1209190f-f79aa6d000005b45-cf-5422a139c26f Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 1A.68.23365.931A2245; Wed, 24 Sep 2014 06:47:21 -0400 (EDT) Received: from outgoing-exchange-3.mit.edu (outgoing-exchange-3.mit.edu [18.9.28.13]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s8OAlKbN029900; Wed, 24 Sep 2014 06:47:21 -0400 Received: from OC11EXEDGE4.EXCHANGE.MIT.EDU (oc11exedge4.exchange.mit.edu [18.9.3.27]) by outgoing-exchange-3.mit.edu (8.13.8/8.12.4) with ESMTP id s8OAlHDd012638; Wed, 24 Sep 2014 06:47:20 -0400 Received: from W92EXHUB11.exchange.mit.edu (18.7.73.20) by OC11EXEDGE4.EXCHANGE.MIT.EDU (18.9.3.27) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 24 Sep 2014 06:46:48 -0400 Received: from OC11EXPO28.exchange.mit.edu ([169.254.1.222]) by W92EXHUB11.exchange.mit.edu ([18.7.73.20]) with mapi id 14.03.0158.001; Wed, 24 Sep 2014 06:47:15 -0400 From: Marie-Jose Montpetit To: Michael Welzl Thread-Topic: [Taps] WG Action: Formed Transport Services (taps) Thread-Index: AQHP18fsdDXm0Hq5OECvmnwVmNjrGZwQUAgA///KNhw= Date: Wed, 24 Sep 2014 10:47:14 +0000 Message-ID: References: <20140923233325.32456.9852.idtracker@ietfa.amsl.com>, <6207133D-FE6E-43C8-B52F-0991336E7737@ifi.uio.no> In-Reply-To: <6207133D-FE6E-43C8-B52F-0991336E7737@ifi.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCKsWRmVeSWpSXmKPExsUixCmqrGu5UCnEoP2vrMWPsztZLe7EODB5 LFnyk8lj9eqHzAFMUVw2Kak5mWWpRfp2CVwZR7buZy54bFvR+G0HawPjJOMuRk4OCQETidV/ pjFC2GISF+6tZ+ti5OIQEpjNJHHz9CsWCOcAo8S7T6ugMscZJR49W8gE4WxnlJj89AQjhLOa UWLRhtPsIMPYBHQknrYuYgaxRQTUJE4sX80GYjMLSEtMWj+ZCcQWFrCX+Na9jbWLkQOoxkFi /VuociuJRxOego1hEVCV6L90CMzmBYpfObMErFVIoEji56IvLCA2p4CdRPOUW2A1jEA/fD+1 hglilbjErSfzmSB+E5RYNHsPM8yf/3Y9hDpHT+LG1ClQtrbEsoWvmSF2CUqcnPmEZQKjxCwk o2YhaZmFpGUWkpYFjCyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdE30cjNL9FJTSjcxgiNQkn8H 47eDSocYBTgYlXh4J4grhQixJpYVV+YeYpTkYFIS5b08ByjEl5SfUpmRWJwRX1Sak1p8iFGC g1lJhPdVD1CONyWxsiq1KB8mJc3BoiTOu+kHX4iQQHpiSWp2ampBahFMVoaDQ0mCt2gBUKNg UWp6akVaZk4JQpqJgxNkOA/QcGOQGt7igsTc4sx0iPwpRl2OdZ3f+pmEWPLy81KlxHlvzQcq EgApyijNg5sDS5yvGMWB3hLmLQAZxQNMunCTXgEtYQJacv+4PMiSkkSElFQDY3R8vNeWf5uc T8g91FabK+8kFDn/TV6ousHFCTEJ5wM41iXaP1BuaXhk+rlfctOH240M/NM1fhy1Uexqjc+6 FJnNZrtR/a3QJcOoP5wXl71ek55yZP49aUd/IaauU3adrUs+T51ZzNenJycudaRu6RalNW7n A8utdjanXHzu5Oi7IOlXTGuAEktxRqKhFnNRcSIA0EXJcncDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/taps/aXuql5NA7XPdnToKepYoA29Vb0M Cc: taps WG Subject: Re: [Taps] WG Action: Formed Transport Services (taps) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 10:47:27 -0000 Congratulations! Marie-Jos=E9 Montpetit mariejo@mit.edu > On Sep 24, 2014, at 05:59, Michael Welzl wrote: >=20 > Hooray! Thanks everyone for your efforts!! >=20 >=20 >> On 24. sep. 2014, at 01:33, The IESG wrote: >>=20 >> A new IETF working group has been formed in the Transport Area. For >> additional information please contact the Area Directors or the WG Chair= . >>=20 >> Transport Services (taps) >> ------------------------------------------------ >> Current Status: Proposed WG >>=20 >> Chairs: >> Aaron Falk >>=20 >> Assigned Area Director: >> Spencer Dawkins >>=20 >> Mailing list >> Address: taps@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/taps >> Archive: http://www.ietf.org/mail-archive/web/taps/ >>=20 >> Charter: >>=20 >> Most Internet applications make use of the Transport Services=20 >> provided by TCP (a reliable, in-order stream protocol) or UDP=20 >> (an unreliable datagram protocol). We use the term "Transport >> Service" to mean an end-to-end facility provided by the >> transport layer. That service can only be provided correctly if >> information is supplied from the application. The application may >> determine the information to be supplied at design time,=20 >> compile time, or run time and may include guidance on whether=20 >> the facility in question is required or simply a preference by the=20 >> application. Four examples of Transport Services are reliable=20 >> delivery, ordered delivery of data, content privacy to in-path=20 >> devices, and minimal latency. >>=20 >> Transport protocols such as SCTP, DCCP, WebSockets, MPTCP, and=20 >> UDP-Lite and the LEDBAT congestion control mechanism extend the=20 >> set of available Transport Services beyond those provided to=20 >> applications by TCP and UDP. For example, SCTP provides potentially=20 >> faster reliable delivery for applications than TCP because it can=20 >> accept blocks of data out of order, and LEDBAT provides low-priority=20 >> "scavenger" communication.=20 >>=20 >> However, application programmers face difficulty when they use=20 >> protocols other than TCP or UDP. Most network stacks ship with only=20 >> TCP and UDP as transport protocols. Many firewalls only pass TCP=20 >> and UDP and some only allow TCP when it carries HTTP as its payload.=20 >> As a result, using other transport protocols or building a new protocol= =20 >> over raw sockets risks having an application not work in many=20 >> environments. Applications, therefore, must always be able to fall back= =20 >> to TCP or UDP, or even to using HTTP as a transport substrate in some=20 >> cases, and once the application programmer has committed=20 >> to making an application work on TCP or UDP or HTTP, there is little=20 >> incentive to try other transport protocols before falling back.=20 >> Further, different protocols can provide the same services in different= =20 >> ways. Layering decisions must also be made (for example, whether a=20 >> protocol is used natively or tunneled through UDP).=20 >>=20 >> Because of these complications, programmers often resort to either=20 >> using TCP or HTTP or implementing their own customized "transport=20 >> services" over UDP. When application developers re-implement transport=20 >> features already available elsewhere they open the door to problems=20 >> that simply using TCP would have avoided and ensure that the=20 >> applications can't benefit from other transport protocols as they=20 >> become available. And, since even TCP and UDP are not guaranteed to=20 >> work in all environments today, some programmers simply give up on=20 >> using TCP or UDP directly, relying instead on "HTTP as a Substrate".=20 >> BCP 56 identified many issues with this strategy, but assuming that=20 >> if "any protocol is available on a given network path and on the hosts=20 >> that will be communicating, that protocol will be HTTP" is a reasonable= =20 >> strategy for today's Internet. The IESG has agreed with this viewpoint=20 >> enough to publish the WebSocket protocol on the standards track.=20 >>=20 >> The goal of the TAPS working group is to help application and network=20 >> stack programmers by describing an (abstract) interface for applications= =20 >> to make use of Transport Services. The Working Group deliverables=20 >> emphasize defining Transport Services that are important to applications= =20 >> followed by experimental mechanisms to a) determine if the protocols to= =20 >> provide the requested services are available on the end points and=20 >> supported along the path in the network and b) fall back, i.e., select=20 >> alternate, possibly less-preferred, protocols when desired protocols=20 >> are not available. The Working Group will not define a richer set of=20 >> Transport Services for applications, although the TAPS deliverables=20 >> could inform proposals for future chartered work on Transport Services.= =20 >>=20 >> The Working Group will: >>=20 >> 1) Define a set of Transport Services, identifying the=20 >> services provided by existing IETF protocols and congestion=20 >> control mechanisms. As a starting point, the working group will=20 >> consider services used=20 >> between two endpoints. >>=20 >> 2) Specify the subset of those Transport Services, as identified=20 >> in item 1, that end systems supporting TAPS will provide, and=20 >> give guidance on choosing among available mechanisms and=20 >> protocols. Note that not all the capabilities of IETF Transport=20 >> protocols need to be exposed as Transport Services. >>=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 >>=20 >> The following topics are out of scope for this Working Group:=20 >>=20 >> - Signaling-based Quality-of-Service (QoS) mechanisms=20 >>=20 >> - Definition of new encapsulations and tunneling mechanisms=20 >>=20 >> - Extension, modification, or creation of transport protocols=20 >>=20 >> - Language-specific APIs=20 >>=20 >> TAPS is not chartered to perform detailed analysis of the security=20 >> aspects of transport protocols. While security can be a transport=20 >> service, TAPS is being chartered almost simultaneously with TCPINC,=20 >> which is developing the TCP extensions to provide unauthenticated=20 >> encryption and integrity protection of TCP streams, and TAPS will=20 >> work with TCPINC to ensure that TAPS will be able to accommodate=20 >> the protocol extensions that TCPINC defines.=20 >>=20 >> Milestones: >> Jun 2015 - Submit an Informational document to the IESG defining a set >> of services provided by IETF transport protocols and congestion control >> mechanisms >> Dec 2015 - Submit an Informational document to the IESG recommending a >> minimal set of Transport Services that end systems should support >> Mar 2016 - Submit an Experimental document to the IESG specifying one >> or more methods to provide applications with the Transport Services >> identified by the WG >> Mar 2016 - Recharter or conclude. >>=20 >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu Sep 25 09:52:24 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF481A01CB for ; Thu, 25 Sep 2014 09:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jktjFyzR1eJT for ; Thu, 25 Sep 2014 09:52:18 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6856E1A8706 for ; Thu, 25 Sep 2014 09:52:16 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id p10so7881030wes.3 for ; Thu, 25 Sep 2014 09:52:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZdlUXzC/U8FyA0ettXJH2K0NhZTFJ5m1BzmQIGnrwC0=; b=lAPlbkK/s5NQ+5eqbYpf509eYLQP7W7/R3WSpVyzPSAgBCIxmnoYjwAdo5b7jZwrFQ +1lOR20ekQGgvtEAJFZpAhhWW8OLe633ksiz8IbJTJJRo96ln3+Fhe2UGeI4Fv40I2ZF 387al2ec81ORbs3bZ/ufVdG2q5bFPMYQM60tuylaaKSZbhndKJ9ZZDirI3RwdvdjXTEz 2o4fJ6ceeZbhsgVPYppqdun+r78ct/wcFRdYPc4ACsfYYI/MSEiPGJjIVRMinsFycFsP XWkkGrT8ohZB7Ih2R8OgWtkPkLlG38k4c06R3udKBtedsE4QelTAritC8YHfy/g0//yF M7xA== MIME-Version: 1.0 X-Received: by 10.195.12.103 with SMTP id ep7mr4872044wjd.121.1411663935046; Thu, 25 Sep 2014 09:52:15 -0700 (PDT) Received: by 10.194.88.99 with HTTP; Thu, 25 Sep 2014 09:52:14 -0700 (PDT) In-Reply-To: References: <20140923233325.32456.9852.idtracker@ietfa.amsl.com> <6207133D-FE6E-43C8-B52F-0991336E7737@ifi.uio.no> Date: Thu, 25 Sep 2014 09:52:14 -0700 Message-ID: From: Dragana Damjanovic To: Marie-Jose Montpetit Content-Type: multipart/alternative; boundary=047d7bfcf880640c900503e69ff1 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/wBs1NfqC0zngMoo0HN2ZwrY2y-U Cc: Michael Welzl , taps WG Subject: Re: [Taps] WG Action: Formed Transport Services (taps) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 16:52:23 -0000 --047d7bfcf880640c900503e69ff1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Congratulations dragana On Wed, Sep 24, 2014 at 12:47 PM, Marie-Jose Montpetit wrote: > Congratulations! > > Marie-Jos=C3=A9 Montpetit > mariejo@mit.edu > > > On Sep 24, 2014, at 05:59, Michael Welzl wrote: > > > > Hooray! Thanks everyone for your efforts!! > > > > > >> On 24. sep. 2014, at 01:33, The IESG wrote: > >> > >> A new IETF working group has been formed in the Transport Area. For > >> additional information please contact the Area Directors or the WG > Chair. > >> > >> Transport Services (taps) > >> ------------------------------------------------ > >> Current Status: Proposed WG > >> > >> Chairs: > >> Aaron Falk > >> > >> Assigned Area Director: > >> Spencer Dawkins > >> > >> Mailing list > >> Address: taps@ietf.org > >> To Subscribe: https://www.ietf.org/mailman/listinfo/taps > >> Archive: http://www.ietf.org/mail-archive/web/taps/ > >> > >> Charter: > >> > >> Most Internet applications make use of the Transport Services > >> provided by TCP (a reliable, in-order stream protocol) or UDP > >> (an unreliable datagram protocol). We use the term "Transport > >> Service" to mean an end-to-end facility provided by the > >> transport layer. That service can only be provided correctly if > >> information is supplied from the application. The application may > >> determine the information to be supplied at design time, > >> compile time, or run time and may include guidance on whether > >> the facility in question is required or simply a preference by the > >> application. Four examples of Transport Services are reliable > >> delivery, ordered delivery of data, content privacy to in-path > >> devices, and minimal latency. > >> > >> Transport protocols such as SCTP, DCCP, WebSockets, MPTCP, and > >> UDP-Lite and the LEDBAT congestion control mechanism extend the > >> set of available Transport Services beyond those provided to > >> applications by TCP and UDP. For example, SCTP provides potentially > >> faster reliable delivery for applications than TCP because it can > >> accept blocks of data out of order, and LEDBAT provides low-priority > >> "scavenger" communication. > >> > >> However, application programmers face difficulty when they use > >> protocols other than TCP or UDP. Most network stacks ship with only > >> TCP and UDP as transport protocols. Many firewalls only pass TCP > >> and UDP and some only allow TCP when it carries HTTP as its payload. > >> As a result, using other transport protocols or building a new protoco= l > >> over raw sockets risks having an application not work in many > >> environments. Applications, therefore, must always be able to fall bac= k > >> to TCP or UDP, or even to using HTTP as a transport substrate in some > >> cases, and once the application programmer has committed > >> to making an application work on TCP or UDP or HTTP, there is little > >> incentive to try other transport protocols before falling back. > >> Further, different protocols can provide the same services in differen= t > >> ways. Layering decisions must also be made (for example, whether a > >> protocol is used natively or tunneled through UDP). > >> > >> Because of these complications, programmers often resort to either > >> using TCP or HTTP or implementing their own customized "transport > >> services" over UDP. When application developers re-implement transport > >> features already available elsewhere they open the door to problems > >> that simply using TCP would have avoided and ensure that the > >> applications can't benefit from other transport protocols as they > >> become available. And, since even TCP and UDP are not guaranteed to > >> work in all environments today, some programmers simply give up on > >> using TCP or UDP directly, relying instead on "HTTP as a Substrate". > >> BCP 56 identified many issues with this strategy, but assuming that > >> if "any protocol is available on a given network path and on the hosts > >> that will be communicating, that protocol will be HTTP" is a reasonabl= e > >> strategy for today's Internet. The IESG has agreed with this viewpoint > >> enough to publish the WebSocket protocol on the standards track. > >> > >> The goal of the TAPS working group is to help application and network > >> stack programmers by describing an (abstract) interface for applicatio= ns > >> to make use of Transport Services. The Working Group deliverables > >> emphasize defining Transport Services that are important to applicatio= ns > >> followed by experimental mechanisms to a) determine if the protocols t= o > >> provide the requested services are available on the end points and > >> supported along the path in the network and b) fall back, i.e., select > >> alternate, possibly less-preferred, protocols when desired protocols > >> are not available. The Working Group will not define a richer set of > >> Transport Services for applications, although the TAPS deliverables > >> could inform proposals for future chartered work on Transport Services= . > >> > >> The Working Group will: > >> > >> 1) Define a set of Transport Services, identifying the > >> services provided by existing IETF protocols and congestion > >> control mechanisms. As a starting point, the working group will > >> consider services used > >> between two endpoints. > >> > >> 2) Specify the subset of those Transport Services, as identified > >> in item 1, that end systems supporting TAPS will provide, and > >> give guidance on choosing among available mechanisms and > >> protocols. Note that not all the capabilities of IETF Transport > >> protocols need to be exposed as Transport Services. > >> > >> 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. > >> > >> The following topics are out of scope for this Working Group: > >> > >> - Signaling-based Quality-of-Service (QoS) mechanisms > >> > >> - Definition of new encapsulations and tunneling mechanisms > >> > >> - Extension, modification, or creation of transport protocols > >> > >> - Language-specific APIs > >> > >> TAPS is not chartered to perform detailed analysis of the security > >> aspects of transport protocols. While security can be a transport > >> service, TAPS is being chartered almost simultaneously with TCPINC, > >> which is developing the TCP extensions to provide unauthenticated > >> encryption and integrity protection of TCP streams, and TAPS will > >> work with TCPINC to ensure that TAPS will be able to accommodate > >> the protocol extensions that TCPINC defines. > >> > >> Milestones: > >> Jun 2015 - Submit an Informational document to the IESG defining a set > >> of services provided by IETF transport protocols and congestion contro= l > >> mechanisms > >> Dec 2015 - Submit an Informational document to the IESG recommending a > >> minimal set of Transport Services that end systems should support > >> Mar 2016 - Submit an Experimental document to the IESG specifying one > >> or more methods to provide applications with the Transport Services > >> identified by the WG > >> Mar 2016 - Recharter or conclude. > >> > >> > >> _______________________________________________ > >> Taps mailing list > >> Taps@ietf.org > >> https://www.ietf.org/mailman/listinfo/taps > > > > _______________________________________________ > > Taps mailing list > > Taps@ietf.org > > https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > --047d7bfcf880640c900503e69ff1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Congratulations

dragana

On Wed, Sep 24, 2014 at = 12:47 PM, Marie-Jose Montpetit <mariejo@mit.edu> wrote:
Congratulations!

Marie-Jos=C3=A9 Montpetit
mariejo@mit.edu

> On Sep 24, 2014, at 05:59, Michael Welzl <michawe@ifi.uio.no> wrote:
>
> Hooray! Thanks everyone for your efforts!!
>
>
>> On 24. sep. 2014, at 01:33, The IESG wrote:
>>
>> A new IETF working group has been formed in the Transport Area. Fo= r
>> additional information please contact the Area Directors or the WG= Chair.
>>
>> Transport Services (taps)
>> ------------------------------------------------
>> Current Status: Proposed WG
>>
>> Chairs:
>> Aaron Falk <aaron.falk@= gmail.com>
>>
>> Assigned Area Director:
>> Spencer Dawkins <spencerdawkins.ietf@gmail.com>
>>
>> Mailing list
>> Address: taps@ietf.org
>> To Subscribe: https://www.ietf.org/mailman/listinfo/taps
>> Archive: http://www.ietf.org/mail-archive/web/taps/
>>
>> Charter:
>>
>> Most Internet applications make use of the Transport Services
>> provided by TCP (a reliable, in-order stream protocol) or UDP
>> (an unreliable datagram protocol).=C2=A0 =C2=A0We use the term &qu= ot;Transport
>> Service" to mean an end-to-end facility provided by the
>> transport layer. That service can only be provided correctly if >> information is supplied from the application. The application may<= br> >> determine the information to be supplied at design time,
>> compile time, or run time and may include guidance on whether
>> the facility=C2=A0 in question is required or simply a preference = by the
>> application. Four examples of Transport Services are reliable
>> delivery, ordered delivery of data, content privacy to in-path
>> devices, and minimal latency.
>>
>> Transport protocols such as SCTP, DCCP, WebSockets, MPTCP, and
>> UDP-Lite and the LEDBAT congestion control mechanism extend the >> set of available Transport Services beyond those provided to
>> applications by TCP and UDP. For example, SCTP provides potentiall= y
>> faster reliable delivery for applications than TCP because it can<= br> >> accept blocks of data out of order, and LEDBAT provides low-priori= ty
>> "scavenger" communication.
>>
>> However, application programmers face difficulty when they use
>> protocols other than TCP or UDP. Most network stacks ship with onl= y
>> TCP and UDP as transport protocols.=C2=A0 Many firewalls only pass= TCP
>> and UDP and some=C2=A0 only allow TCP=C2=A0 when it carries HTTP a= s its payload.
>> As a result, using other transport protocols or building a new pro= tocol
>> over raw sockets risks having an application not work in many
>> environments. Applications, therefore, must always be able to fall= back
>> to TCP or UDP, or even to using HTTP as a transport substrate in s= ome
>> cases, and once the application programmer has committed
>> to making an application work on TCP or UDP or HTTP, there is litt= le
>> incentive to try other transport protocols before falling back. >> Further, different protocols can provide the same services in diff= erent
>> ways. Layering decisions must also be made (for example, whether a=
>> protocol is used natively or tunneled through UDP).
>>
>> Because of these complications, programmers often resort to either=
>> using TCP or HTTP or implementing their own customized "trans= port
>> services" over UDP. When application developers re-implement = transport
>> features already available elsewhere they open the door to problem= s
>> that simply using TCP would have avoided and ensure that the
>> applications can't benefit from other transport protocols as t= hey
>> become available. And, since even TCP and UDP are not guaranteed t= o
>> work in all environments today, some programmers simply give up on=
>> using TCP or UDP directly, relying instead on "HTTP as a Subs= trate".
>> BCP 56 identified many issues with this strategy, but assuming tha= t
>> if "any protocol is available on a given network path and on = the hosts
>> that will be communicating, that protocol will be HTTP" is a = reasonable
>> strategy for today's Internet. The IESG has agreed with this v= iewpoint
>> enough to publish the WebSocket protocol on the standards track. >>
>> The goal of the TAPS working group is to help application and netw= ork
>> stack programmers by describing an (abstract) interface for applic= ations
>> to make use of Transport Services. The Working Group deliverables<= br> >> emphasize defining Transport Services that are important to applic= ations
>> followed by experimental mechanisms to a) determine if the protoco= ls to
>> provide the requested services are available on the end points and=
>> supported along the path in the network and b) fall back, i.e., se= lect
>> alternate, possibly less-preferred, protocols when desired protoco= ls
>> are not available. The Working Group will not define a richer set = of
>> Transport Services for applications, although the TAPS deliverable= s
>> could inform proposals for future chartered work on Transport Serv= ices.
>>
>> The Working Group will:
>>
>> 1) Define a set of Transport Services, identifying the
>>=C2=A0 services provided by existing IETF protocols and congestion<= br> >>=C2=A0 control mechanisms. As a starting point, the working group w= ill
>>=C2=A0 consider services used
>>=C2=A0 between two endpoints.
>>
>> 2) Specify the subset of those Transport Services, as identified >>=C2=A0 in item 1, that end systems supporting TAPS will provide, an= d
>>=C2=A0 give guidance on choosing among available mechanisms and
>>=C2=A0 protocols.=C2=A0 Note that not all the capabilities of IETF = Transport
>>=C2=A0 protocols need to be exposed as Transport Services.
>>
>> 3) Specify experimental support mechanisms to provide the Transpor= t
>>=C2=A0 Services identified in work item 2. This document will expla= in
>>=C2=A0 how to select and engage an appropriate protocol and how to<= br> >>=C2=A0 discover which protocols are available for the selected serv= ice
>>=C2=A0 between a given pair of end points. Further, it will provide= a
>>=C2=A0 basis for incremental deployment. Work on this document will=
>>=C2=A0 begin when the TAPS Transport Services have been specified.<= br> >>
>> The following topics are out of scope for this Working Group:
>>
>> - Signaling-based Quality-of-Service (QoS) mechanisms
>>
>> - Definition of new encapsulations and tunneling mechanisms
>>
>> - Extension, modification, or creation of transport protocols
>>
>> - Language-specific APIs
>>
>> TAPS is not chartered to perform detailed analysis of the security=
>> aspects of transport protocols. While security can be a transport<= br> >> service, TAPS is being chartered almost simultaneously with TCPINC= ,
>> which is developing the TCP extensions to provide unauthenticated<= br> >> encryption and integrity protection of TCP streams, and TAPS will<= br> >> work with TCPINC to ensure that TAPS will be able to accommodate >> the protocol extensions that TCPINC defines.
>>
>> Milestones:
>> Jun 2015 - Submit an Informational document to the IESG defining a= set
>> of services provided by IETF transport protocols and congestion co= ntrol
>> mechanisms
>> Dec 2015 - Submit an Informational document to the IESG recommendi= ng a
>> minimal set of Transport Services that end systems should support<= br> >> Mar 2016 - Submit an Experimental document to the IESG specifying = one
>> or more methods to provide applications with the Transport Service= s
>> identified by the WG
>> Mar 2016 - Recharter or conclude.
>>
>>
>> _______________________________________________
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
>
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps

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

--047d7bfcf880640c900503e69ff1-- From nobody Fri Sep 26 12:50:07 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB081A00F3 for ; Fri, 26 Sep 2014 12:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Di1QDtAQFIqK for ; Fri, 26 Sep 2014 12:50:05 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D92591A00A3 for ; Fri, 26 Sep 2014 12:50:04 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id m20so1302112qcx.24 for ; Fri, 26 Sep 2014 12:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=fwFMvXtReMZrpvbLsfL6RuMUX2mwXexLEnWaJBaIulM=; b=zQKu8IgpVzJzfg5vkLUrZrh6JU4KJFgdZB3OPr9pJiOSwUn+t89J7bprcll7/Kc1TB 7BgCN7/9FNthyEDm2pUpe1bKW+/XGQpK0ThrSlwH8suB/JXOf5eYJwwphsx9amBx6XQ2 lVPan3XOCAiGc9jp6eAChMW++1UTh0kxd9jFkpT8ZAPkSEWFEaYByJz/M71fViJi5uKk DjMOgNh6ZnHOjH2kj76wY7CU5wN66y4zEXvWVVF8hYWjkzBwiJubU6UTjHGXp4MjWJ/c 1ll0staQZlJb0ZYE7i18RneuQOna2W9YHWlZ5tGIhWProOQFh8X5C0GqyKOSzSJTFxSz ujXA== MIME-Version: 1.0 X-Received: by 10.140.83.105 with SMTP id i96mr35327002qgd.18.1411761003917; Fri, 26 Sep 2014 12:50:03 -0700 (PDT) Received: by 10.229.73.69 with HTTP; Fri, 26 Sep 2014 12:50:03 -0700 (PDT) Date: Fri, 26 Sep 2014 15:50:03 -0400 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=001a11c13cde2594e00503fd3967 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/73X4Hq8zK93X8ylfruVsGicyUHE Subject: [Taps] kicking things off X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 19:50:06 -0000 --001a11c13cde2594e00503fd3967 Content-Type: text/plain; charset=UTF-8 Well, I hope you've all seen the good news that the TAPS wg has been chartered. There were a few minor improvements made in the charter text but nothing of substance. Spencer is looking for a co-chair with APPS area expertise so if you have nominations, please send them to him. The wg will be meeting in Honolulu this November so don't forget to grab hotel and flights soon if you plan to attend. Let's get things started on the first doc. The first step is to select one or two document editors. For the editor role it would be a good thing (but not required) to have someone who has experience taking an IETF draft through a wg to publication. Also, desirable is to have someone with sufficient time to keep up on working group discussions, experience with ID editing tools, and the ability to attend most IETF meetings. In Toronto, we polled for volunteers for editor and the following folks raised their hands: Brian Trammel Michael Tuexen Gorry Fairhurst Michael Welzl Does anyone else want to volunteer? (Or any volunteers want to change their mind?) I'll pause here for any discussion. --aaron --001a11c13cde2594e00503fd3967 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well, I hope you've all seen the good news that the TA= PS wg has been chartered.=C2=A0 There were a few minor improvements made in= the charter text but nothing of substance.=C2=A0 Spencer is looking for a = co-chair with APPS area expertise so if you have nominations, please send t= hem to him.=C2=A0 The wg will be meeting in Honolulu this November so don&#= 39;t forget to grab hotel and flights soon if you plan to attend.

<= /div>
Let's get things started on the first doc.=C2=A0 The first st= ep is to select one or two document editors.=C2=A0 For the editor role it w= ould be a good thing (but not required) to have someone who has experience = taking an IETF draft through a wg to publication.=C2=A0 Also, desirable is = to have someone with sufficient time to keep up on working group discussion= s, experience with ID editing tools, and the ability to attend most IETF me= etings.=C2=A0 In Toronto, we polled for volunteers for editor and the follo= wing folks raised their hands:

Brian Trammel
=
Michael Tuexen
Gorry Fairhurst
Michael Welzl

Does anyone else want to volunteer? =C2=A0(Or any v= olunteers want to change their mind?) =C2=A0I'll pause here for any dis= cussion.

--aaron

--001a11c13cde2594e00503fd3967-- From nobody Sun Sep 28 13:32:11 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3051A1BED for ; Sun, 28 Sep 2014 13:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqB6Ggygri0r for ; Sun, 28 Sep 2014 13:32:09 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A9D1A1BEA for ; Sun, 28 Sep 2014 13:32:09 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id u57so442715wes.12 for ; Sun, 28 Sep 2014 13:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=xSR4zGE6UWXc3QZt8+BCW5Ryj8ttxrc5VrS1gnm6Umk=; b=gqD+M2iH9VnKXUCvLM7NEgEh14qAzEbMufCT6Vc3hEn82NQxcevMaJBH90fFaJFhs0 xc4E9X4tkAKByZgKlj7M4YuxFOdDvgp83pOgkp07l5s5gTtPz+G2WXhKXmXEmEVxCpU7 8RewWysqwx+TbW0Twv7n3QeBQaaiUgOtu2pY34TOYd3AdPn+9geIdUoSi9xZqNCRiF9+ KXJZ8ibIclnAyvnwkIbdJ1xukJ9VW3GXL+X6KuS0XJcRNR/s6g5rF2tOTZDkCrOlenjk tv63Otab0k4eVyYsOVCRIgvObhJu36oXifb3SjCiXI/p0+Jt+28vzvaThcNHv8hEKx2d 95vg== MIME-Version: 1.0 X-Received: by 10.180.72.45 with SMTP id a13mr40796574wiv.50.1411936328207; Sun, 28 Sep 2014 13:32:08 -0700 (PDT) Received: by 10.216.209.193 with HTTP; Sun, 28 Sep 2014 13:32:08 -0700 (PDT) Date: Sun, 28 Sep 2014 16:32:08 -0400 Message-ID: From: Aaron Falk To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=001a11c24cc449d5be0504260b30 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/YYeVXXEm_Kh8hUteoI7AuSwFIXo Subject: [Taps] meeting planning X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 20:32:11 -0000 --001a11c24cc449d5be0504260b30 Content-Type: text/plain; charset=UTF-8 Hi Folks- I'm putting in a request for a meeting in Honolulu. If you are planning to be an __active contributor__ to this group, it would be helpful if you would send me (directly) wg sessions that TAPS should avoid conflict with. Please only identify wgs conflict would be a problem, as opposed to a preference. As I'm sure you all know, there are no promises when it comes to meeting scheduling. Thanks, --aaron --001a11c24cc449d5be0504260b30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Folks-

I'm putting in a request = for a meeting in Honolulu.=C2=A0 If you are planning to be an __active cont= ributor__ to this group, it would be helpful if you would send me (directly= ) wg sessions that TAPS should avoid conflict with. Please only identify wg= s conflict would be a problem, as opposed to a preference.=C2=A0 As I'm= sure you all know, there are no promises when it comes to meeting scheduli= ng. =C2=A0

Thanks,

--aaro= n
--001a11c24cc449d5be0504260b30-- From nobody Tue Sep 30 14:52:04 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67EF1A930A for ; Tue, 30 Sep 2014 14:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0oaCsAA8CA3 for ; Tue, 30 Sep 2014 14:52:02 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C781A9244 for ; Tue, 30 Sep 2014 14:52:01 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id m15so3356402wgh.4 for ; Tue, 30 Sep 2014 14:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4YdANYRf8jEoPRBAK9TdPMwjfnClSB+fuuZkAIfaOa8=; b=ZjBwCO+fwMsGBNX4nakr2XW2R7fZE19+MbYFPL64Lh7HI2SMJT6kVtAOKDMFXHDrEN akb0vAvctbfCeDMIR5eEnamEFvA9mPTxapr0hJsEIG3elD5L3UQFN24YnpdBpduQ444t Z+p68vTfEjVpF/AuI/1ad2YKb5IWaTOVoPugyPzEfJ+zAJtwr+arFOu5gbflnOEQOTO6 EntVacqamQJ3JofVCk0UlGxPG2d1RR56g5jLpPloo18eEGdfAzUAkCBBk/5xSn+XA1KR WYJfdfd7dT455iTUGrMB1eBuyjkqIprOdEyVYLDczz/ys36tEz5QeQVd+lZWftWPmPVX yTvw== MIME-Version: 1.0 X-Received: by 10.180.24.226 with SMTP id x2mr15225498wif.1.1412113920447; Tue, 30 Sep 2014 14:52:00 -0700 (PDT) Received: by 10.216.209.193 with HTTP; Tue, 30 Sep 2014 14:52:00 -0700 (PDT) In-Reply-To: References: <54281A9E.8000907@gmail.com> Date: Tue, 30 Sep 2014 17:52:00 -0400 Message-ID: From: Aaron Falk To: Stephanie McCammon Content-Type: multipart/alternative; boundary=f46d04428f549c5d9905044f64e0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/oofC6igltQhwyktP8IIgZhr-PnU Cc: Martin Stiemerling , Spencer Dawkins , "taps@ietf.org" Subject: Re: [Taps] kicking things off X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 21:52:03 -0000 --f46d04428f549c5d9905044f64e0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Stephanie- Here is the meeting request. Let me know if I've missed anything. ---aaron =3D=3D=3D=3D=3D=3D WGname: TAPS Area: TSV # sessions: 1 Length of sessions: 2hrs # attendees: 80 People who must be present: spencerdawkins.ietf@gmail.com, aaron.falk@gmail.com Conflicts to avoid: appsarea aqm httpsbis iccrg (IRTF) icnrg (IRTF) mptcp ncrg (IRTF) nvo3 ppsp rmcat supa (BOF) tcpinc tcpm tsvarea tsvsg webpush Resources: - projector - meetecho On Mon, Sep 29, 2014 at 1:22 PM, Stephanie McCammon wrote: > > > Hello everyone, > > I=E2=80=99ve closed the session request tool today. Aaron, if you let me = know the > requirements for the TAPS meeting (i.e. expected attendance, conflicts, > length of session) I will be happy to put the request in for you. Please > let me know the requirements prior to Wednesday. > > Sincerely, > > Stephanie McCammon > IETF Project Manager > 48377 Fremont Blvd, Ste. 117 > Fremont, CA 94538 > T: +1.510.492.4081 > F: +1.510.492.4001 > > Association Management Solutions (AMS) > Forum Management, Meeting, and Event Planning > www.amsl.com > > > > > On Sep 28, 2014, at 13:26 , Aaron Falk wrote: > > > Will do. > > > > --aaron > > > > On Sun, Sep 28, 2014 at 10:26 AM, Spencer Dawkins < > spencerdawkins.ietf@gmail.com> wrote: > > Dear Aaron, > > > > I should have asked - do you know how to request meeting slots, these > days? :-) > > > > I'm betting TAPS wasn't quite approved enough for you to be seeing > "please your meeting" emails for IETF 91, until now. > > > > There's an online request form at > https://datatracker.ietf.org/secr/sreq/. > > > > There's a description of the fields at > http://www.ietf.org/old/2009/instructions/session_request_tool_instructio= n.html > . > > > > Could you take a shot at that? > > > > I will, of course, approve the meeting :D > > > > Spencer > > > > > > On 09/26/2014 02:50 PM, Aaron Falk wrote: > >> Well, I hope you've all seen the good news that the TAPS wg has been > chartered. There were a few minor improvements made in the charter text > but nothing of substance. Spencer is looking for a co-chair with APPS ar= ea > expertise so if you have nominations, please send them to him. The wg wi= ll > be meeting in Honolulu this November so don't forget to grab hotel and > flights soon if you plan to attend. > >> > >> Let's get things started on the first doc. The first step is to selec= t > one or two document editors. For the editor role it would be a good thin= g > (but not required) to have someone who has experience taking an IETF draf= t > through a wg to publication. Also, desirable is to have someone with > sufficient time to keep up on working group discussions, experience with = ID > editing tools, and the ability to attend most IETF meetings. In Toronto, > we polled for volunteers for editor and the following folks raised their > hands: > >> > >> Brian Trammel > >> Michael Tuexen > >> Gorry Fairhurst > >> Michael Welzl > >> > >> Does anyone else want to volunteer? (Or any volunteers want to change > their mind?) I'll pause here for any discussion. > >> > >> --aaron > >> > >> > >> > >> _______________________________________________ > >> Taps mailing list > >> > >> Taps@ietf.org > >> https://www.ietf.org/mailman/listinfo/taps > > > > > > --f46d04428f549c5d9905044f64e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Stephanie-

Here is the meeting reque= st.=C2=A0 Let me know if I've missed anything.

---aaron

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

<= div>WGname: TAPS

Area: TSV

# sessions: 1

Length of sessions: 2hrs

# attendees: 80

People who must be= present:=C2=A0spencerdawk= ins.ietf@gmail.com, aaron.falk@= gmail.com

Conflicts to avoid:
<= font face=3D"arial, sans-serif">appsarea
aqm=C2=A0
httpsbis
iccrg (IRTF)
icnrg=C2=A0(IRTF)
mptcp=
ncrg=C2=A0(IRTF)
n= vo3
ppsp=C2=A0
rmcat
supa (BOF)=C2=A0
tcpinc
tcp= m
tsvarea
tsvsg
webpush

Resources:
- projector
= - meetecho

<= br>

O= n Mon, Sep 29, 2014 at 1:22 PM, Stephanie McCammon <smccammon@amsl.com> wrote:


Hello everyone,

I=E2=80=99ve closed the session request tool today. Aaron, if you let me kn= ow the requirements for the TAPS meeting (i.e. expected attendance, conflic= ts, length of session) I will be happy to put the request in for you. Pleas= e let me know the requirements prior to Wednesday.

Sincerely,

Stephanie McCammon
IETF Project Manager
48377 Fremont Blvd, Ste. 117
Fremont, CA 94538
T: +1.510.492.4081=
F: +1.510.492.4001=

Association Management Solutions (AMS)
Forum Management, Meeting, and Event Planning
www.amsl.com




On Sep 28, 2014, at 13:26 , Aaron Falk <aaron.falk@gmail.com> wrote:

> Will do.
>
> --aaron
>
> On Sun, Sep 28, 2014 at 10:26 AM, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrot= e:
> Dear Aaron,
>
> I should have asked - do you know how to request meeting slots, these = days? :-)
>
> I'm betting TAPS wasn't quite approved enough for you to be se= eing "please your meeting" emails for IETF 91, until now.
>
> There's an online request form at https://datatracker.ietf.org/secr/sre= q/.
>
> There's a description of the fields at http://www.ietf.org/old/2009/instructions/session_request_tool_inst= ruction.html.
>
> Could you take a shot at that?
>
> I will, of course, approve the meeting :D
>
> Spencer
>
>
> On 09/26/2014 02:50 PM, Aaron Falk wrote:
>> Well, I hope you've all seen the good news that the TAPS wg ha= s been chartered.=C2=A0 There were a few minor improvements made in the cha= rter text but nothing of substance.=C2=A0 Spencer is looking for a co-chair= with APPS area expertise so if you have nominations, please send them to h= im.=C2=A0 The wg will be meeting in Honolulu this November so don't for= get to grab hotel and flights soon if you plan to attend.
>>
>> Let's get things started on the first doc.=C2=A0 The first ste= p is to select one or two document editors.=C2=A0 For the editor role it wo= uld be a good thing (but not required) to have someone who has experience t= aking an IETF draft through a wg to publication.=C2=A0 Also, desirable is t= o have someone with sufficient time to keep up on working group discussions= , experience with ID editing tools, and the ability to attend most IETF mee= tings.=C2=A0 In Toronto, we polled for volunteers for editor and the follow= ing folks raised their hands:
>>
>> Brian Trammel
>> Michael Tuexen
>> Gorry Fairhurst
>> Michael Welzl
>>
>> Does anyone else want to volunteer?=C2=A0 (Or any volunteers want = to change their mind?)=C2=A0 I'll pause here for any discussion.
>>
>> --aaron
>>
>>
>>
>> _______________________________________________
>> Taps mailing list
>>
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
>
>


--f46d04428f549c5d9905044f64e0-- From nobody Tue Sep 30 15:07:56 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731921A1BD9 for ; Tue, 30 Sep 2014 15:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tb_-PO0yyh8k for ; Tue, 30 Sep 2014 15:03:19 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id A8F2B1ACC81 for ; Tue, 30 Sep 2014 15:03:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 011581E59CD; Tue, 30 Sep 2014 15:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c9a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeXgRI2P9XuS; Tue, 30 Sep 2014 15:02:58 -0700 (PDT) Received: from [64.170.98.162] (unknown [64.170.98.162]) by c8a.amsl.com (Postfix) with ESMTPSA id D87D51E59CA; Tue, 30 Sep 2014 15:02:58 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Stephanie McCammon In-Reply-To: Date: Tue, 30 Sep 2014 15:03:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <96B17B15-85AB-4581-B8C3-751B13673DAC@amsl.com> References: <54281A9E.8000907@gmail.com> To: Aaron Falk X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/nI-e2oRRnIWT09NhjVSnlRVoHD0 X-Mailman-Approved-At: Tue, 30 Sep 2014 15:07:55 -0700 Cc: Martin Stiemerling , Spencer Dawkins , "taps@ietf.org" Subject: Re: [Taps] kicking things off X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 22:03:21 -0000 Hi Aaron, The request for TAPS has been entered. Thank you! Sincerely, Stephanie McCammon IETF Project Manager 48377 Fremont Blvd, Ste. 117 Fremont, CA 94538 T: +1.510.492.4081 F: +1.510.492.4001 Association Management Solutions (AMS) Forum Management, Meeting, and Event Planning www.amsl.com On Sep 30, 2014, at 14:52 , Aaron Falk wrote: > Hi Stephanie- >=20 > Here is the meeting request. Let me know if I've missed anything. >=20 > ---aaron >=20 > =3D=3D=3D=3D=3D=3D >=20 > WGname: TAPS >=20 > Area: TSV >=20 > # sessions: 1 >=20 > Length of sessions: 2hrs >=20 > # attendees: 80 >=20 > People who must be present: spencerdawkins.ietf@gmail.com, = aaron.falk@gmail.com >=20 > Conflicts to avoid: > appsarea > aqm=20 > httpsbis > iccrg (IRTF) > icnrg (IRTF) > mptcp > ncrg (IRTF) > nvo3 > ppsp=20 > rmcat > supa (BOF)=20 > tcpinc > tcpm > tsvarea > tsvsg > webpush >=20 > Resources: > - projector > - meetecho >=20 >=20 >=20 > On Mon, Sep 29, 2014 at 1:22 PM, Stephanie McCammon = wrote: >=20 >=20 > Hello everyone, >=20 > I=92ve closed the session request tool today. Aaron, if you let me = know the requirements for the TAPS meeting (i.e. expected attendance, = conflicts, length of session) I will be happy to put the request in for = you. Please let me know the requirements prior to Wednesday. >=20 > Sincerely, >=20 > Stephanie McCammon > IETF Project Manager > 48377 Fremont Blvd, Ste. 117 > Fremont, CA 94538 > T: +1.510.492.4081 > F: +1.510.492.4001 >=20 > Association Management Solutions (AMS) > Forum Management, Meeting, and Event Planning > www.amsl.com >=20 >=20 >=20 >=20 > On Sep 28, 2014, at 13:26 , Aaron Falk wrote: >=20 > > Will do. > > > > --aaron > > > > On Sun, Sep 28, 2014 at 10:26 AM, Spencer Dawkins = wrote: > > Dear Aaron, > > > > I should have asked - do you know how to request meeting slots, = these days? :-) > > > > I'm betting TAPS wasn't quite approved enough for you to be seeing = "please your meeting" emails for IETF 91, until now. > > > > There's an online request form at = https://datatracker.ietf.org/secr/sreq/. > > > > There's a description of the fields at = http://www.ietf.org/old/2009/instructions/session_request_tool_instruction= .html. > > > > Could you take a shot at that? > > > > I will, of course, approve the meeting :D > > > > Spencer > > > > > > On 09/26/2014 02:50 PM, Aaron Falk wrote: > >> Well, I hope you've all seen the good news that the TAPS wg has = been chartered. There were a few minor improvements made in the charter = text but nothing of substance. Spencer is looking for a co-chair with = APPS area expertise so if you have nominations, please send them to him. = The wg will be meeting in Honolulu this November so don't forget to = grab hotel and flights soon if you plan to attend. > >> > >> Let's get things started on the first doc. The first step is to = select one or two document editors. For the editor role it would be a = good thing (but not required) to have someone who has experience taking = an IETF draft through a wg to publication. Also, desirable is to have = someone with sufficient time to keep up on working group discussions, = experience with ID editing tools, and the ability to attend most IETF = meetings. In Toronto, we polled for volunteers for editor and the = following folks raised their hands: > >> > >> Brian Trammel > >> Michael Tuexen > >> Gorry Fairhurst > >> Michael Welzl > >> > >> Does anyone else want to volunteer? (Or any volunteers want to = change their mind?) I'll pause here for any discussion. > >> > >> --aaron > >> > >> > >> > >> _______________________________________________ > >> Taps mailing list > >> > >> Taps@ietf.org > >> https://www.ietf.org/mailman/listinfo/taps > > > > >=20 >=20