From nobody Tue May 20 00:52:51 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 9002E1A0307 for ; Tue, 20 May 2014 00:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnnxJyBkAFkO for ; Tue, 20 May 2014 00:52:47 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E097D1A0306 for ; Tue, 20 May 2014 00:52:45 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Wmeqp-0005S5-Rk for taps@ietf.org; Tue, 20 May 2014 09:52:43 +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 1Wmeqp-00067T-8e for taps@ietf.org; Tue, 20 May 2014 09:52:43 +0200 From: Michael Welzl Content-Type: multipart/mixed; boundary="Apple-Mail=_7B7F19D1-5FD2-4EE8-8D39-3E3A46EBC4F0" Date: Tue, 20 May 2014 09:52:42 +0200 Message-Id: <3760DEA3-68BD-48CC-BB12-281F77F7E6F3@ifi.uio.no> To: taps@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 2 sum rcpts/h 4 sum msgs/h 3 total rcpts 16463 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: AEE5FE1D02FBD94908DC24C3EB83ACE43A67DCEF X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 5347 max/h 16 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/5naMpEl_0cUjd0TESSXV20Fp0oI Subject: [Taps] First draft of an article for the IETF journal 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, 20 May 2014 07:52:49 -0000 --Apple-Mail=_7B7F19D1-5FD2-4EE8-8D39-3E3A46EBC4F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear all, I was invited to write an article about the TAPS BOF for the IETF = journal, with deadline end of May ("exact due date TBD"). This is the = information they gave me: *** For BoFs, most articles end up being an overview of the BoF, its goals, = and any next steps and/or ongoing work. Pictures and figures are = welcome, too, as separate high-resolution files. Articles can be anywhere from 500-1500 words, but we are pretty flexible = if you have more or less to say. We publish articles online to = http://www.internetsociety.org/publications/ietf-journal and our Twitter = account ( http://twitter.com/ietfjournal) as they are finalized, and = then package everything into a print version just in time for the next = IETF. *** I produced the text below, with two figures attached to this email. = Please let me have any comments / suggestions by the end of this week = latest, thanks! Cheers, Michael ******************************************************** TAPS BOF SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion control mechanism = offer a large number of services to applications in addition to the = long-standing two services provided by TCP and UDP. For an application = programmer, using protocols other than TCP or UDP is hard: not all = protocols are available everywhere, hence a fall-back solution must be = implemented. Some protocols provide the same services in different ways. = Layering decisions must be made (e.g. should a protocol be used natively = or over UDP?). Because of these complications, programmers often resort = to either using TCP or implementing their own customized solution over = UDP, and chances of benefiting from other transport protocols are lost. = The intention of the Transport Services (TAPS) initiative is to identify = the services provided by IETF transport protocols and congestion control = mechanisms as well as network requirements of applications and the APIs = they use to communicate. By finding a mapping between these lists, a = potential later WG could define services that a transport API should = offer. Then, it would specify how these transport services can be = implemented using native IETF transports and encapsulated transports, = including the definition of mechanisms to validate that a transport (or = transports) can be supported on a path. The TAPS initiative began in August 2013 with a mailing list and an = accompanying web page. We held a "Bar BOF" at IETF-88 in Vancouver, = where it was already clarified that TAPS should be careful to provide = what application programmers really need instead of being too focused on = the Berkeley Sockets API. Accordingly, several Internet-drafts were = written, including use cases and an overview of how higher level APIs = could better be supported by enhanced IETF transport services. By = breaking the dependency of applications on specific protocols, TAPS has = the potential to make the currently rigid transport layer more flexible; = this is schematically shown in Figure 1. In December 2013, a = presentation was given at the IAB Workshop on Internet Technology = Adoption and Transition in Cambridge, UK, explaining how the = evolutionary benefit of TAPS is connected to its best-effort nature. = These activities culminated in a Birds-of-a-Feather (BoF) meeting at = IETF-89. This BoF was designated "non-WG-forming" to allow the IETF = community to discuss the various angles of this large problem space = without having to spend time on charter word-smithing. Discussion was = indeed lively at this two-hour long session, with 129 attendees and a = debate in which more than 6650 words were spoken at the microphone. There were four presentations at the TAPS BoF: Jon Crowcroft outlined = the potential of this activity, calling it "socket science" and putting = it in relation to security. Then, Martin Sustrik presented how = middleware such as his own ZeroMQ could benefit from transports other = than TCP; notably, the strict reliability of TCP is a poor match for = pub/sub communication. As shown in Figure 2, updating middleware offers = an easy deployment path, where applications could exploit some of the = benefits of TAPS without having to be changed (except for re-compiling = with a new version of the middleware). Gorry Fairhurst presented a = possible implementation of TAPS, and Margaret Wasserman presented the = API of the Multiple Interfaces (MIF) Working Group. This API is clearly = related, and it seems obvious that a TAPS API should be somehow = connected to the MIF API. All presentations were accompanied by active debate. For example, not = everyone agreed with the particular way of providing transport services = that was presented. The flexibility shown in Figure 1 comes at a cost -- = application programmers may need a very predictable behavior, where a = certain way of using an API always leads to the exact same protocol = choice underneath. This point was made by Stuart Cheshire from Apple, = who suggested to make such decisions at development time, not at = runtime; Marie-Jos=E9 Montpetit from MIT stressed the importance of = testing. Changing the transport protocol must not break an application. = Ran Atkinson and Dave Thaler suggested to support name-based instead of = IP-address-based transports, at least as an option. Several participants = stated that TAPS should not be focusing on an API -- for example, Pete = Resnick said that TAPS should be thought about in terms of a layer, and = we should leave it to OSes that interface with applications to do the = work to build the API and actually produce the layer that we want with = all the information that we want and whatever APIs are needed. There is an ongoing conversation between the TSV ADs who sponsored the = TAPS BOF, APPs and RAI ADs, and interested IAB members about next steps. = The group=92s mailing list, taps@ietf.org, currently has 120 = subscribers, and can be joined at = https://www.ietf.org/mailman/listinfo/taps. The accompanying webpage is = at https://sites.google.com/site/transportprotocolservices. Activities of some TAPS participants (Michael Welzl, Gorry Fairhurst) = were part-funded by the European Community under its Seventh Framework = Programme through the Reducing Internet Transport Latency (RITE) project = (ICT-317700). The views expressed are solely those of the author(s). Figure 1 caption text: Without TAPS (left), the application is tied to = protocol X. With TAPS (right), the application could benefit from = protocol Y that is supported by ISP B. Figure 2 caption text: Before (left) and after (right) applying TAPS = below a non-TAPS-enabled application. Nothing changes in the application = and the middleware API that it uses. --Apple-Mail=_7B7F19D1-5FD2-4EE8-8D39-3E3A46EBC4F0 Content-Disposition: inline; filename=fig1.pdf Content-Type: application/pdf; x-mac-type=50444620; x-unix-mode=0644; name="fig1.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHVmk2PHEUShu/1K/I4c3CR3x/HxdrDcjLyHBYZDshgDWgG lrVXK/79PpFVWZnV1d1uAxKsLPA4pqIqMt7MiDci4xf1pfpFffbyvVFv3yuj3r9VWllj1bOKafnp qf6k1RO/kf8/qndKz1H9IGp2UTPKTKimWXvnvVUm69kYfnhWxpi52DDIngZZMHOKKfHarrvKJvlU l/Y3vsPOL/jvx8WAl6+rYVq9fslSTP3HC6Ne5DgHZYubw/T2WcnfYhvfdrPLIYtpJc++mtZkmLbJ PKY56zCt666yalqXNu1n9Rp3NmfqxZk/jEaFPJeMGcrEOHuvi5j2+YMyfjXbqxcu4zrtggrY//Cs Pnt4wL3q4Z16o+7+dq9e6Nmqu3/dA8Lw99P9VP/9wyp/2x78tv3wof3q5/WRn+7VN+rhC/X3B6ze ITrJB+tm6P5vSI2INtmIqHX41Ijbmu5kumxEtGk/s6HOA6d2wDXnj8B1kDpwSc86ZdlTHaIuexyk /Y23Awc8uvggpp0CF2atHZse4KZT4F79u+HQ3P+h/bBB1QRPK0BqAWiqALXDJoewQjO4rG+ri9bZ MMcYOIYH4+7+ea8efhx3wYa+SXNIDqXI3nIlyXlm+6VgcrFGRTfn4mKZOGkhZJNU8XMM3hjlwpxy LlHlMnsdfFFvFbYFTVRQpczRxRRUsrMvwUVV0lxSNCKwyRk7DWoCYs4SQLSeUePwWD1nm51K8sYS Er+ymJAcoYpjTkThc8b62WcTp8hLndOhPmWzTsrxypIxzs82J5/FNJeNGJntnH3yPKMxvDgVOBnZ 6KhsmqMpzk4+zTkk7OhalhVxrIk3cc45lUT4mZ2LLEZ5P4eoxf5Tb05viXAHKT6+dh6M9mxvwgNr mm3Ujucz3mapZrJiiI5O9rgGEj5KPMs+FNyBG3JRVvTrBkYkOxa0WNaco3PKyE4qARcX9gmQTyJJ QLLTIxZrIKl6xll8o9PsBBFrPC/QvAAEtSBi+UjhVSzWGk34MzzuDKYDW+blAogNZS6arWE4qJxd VhcCYTCTloiVZXZeZGw4XXSajEszv8OoGPA3LzDOzw5QdnomzkaCrSXYRnIa28VEJzZ5lumK7IjF mdPmzArJGRffGCDYgRhSD8UxQAB19FE2BzkxaK3tIb7/Yz36r1/dy86I6k7dT45NVUM/PwSRDHH7 GAW6CedilBwwjhNhwJdS8jFQfX33vkWq/6zGnOaaFqe2kPZhVZn2tt0Qsq4aS9pwpGxAlTiBtfuo OgauXdK9wSdEMfH/9MD2GnIvmbyUCDloX9wDdKd+/unp16/vTwMmMZmUeZF/CA7GcwxI/XWHB0lP oywn2IANpCz22XTwG6fDo8uxJvmEFOTME9UWGbGpClEOkIr6XJNVonJOGwoHh9JwqMFZA2Xam0ww EPMmMXlhMBzdzWR43rq0LiOubQtetbFZDpGRP0IWXZGYHfjXQu1kUZ5E4OWEbrKnQbYQhsxCu+4q qwvt0v7GThYlcV4hibJinyRoBTOtJFFACpk9UU1aaJ7wii5bGIRF1nRZeCWOInvcpOMbPxZKPBnD l0jsriSREHikGgNH3B+K6xxx4YyNCG7EY+WI090ncMQFSOG43e0Lz/PqeepANtkAJBtCJ1/EQ5vu IHvs0pU5enbetZzYfb/wvLjDrck6btNKFs0Ot4X5i6zjVo8rbFLeeA636Rf8IPuKiqPjpkvNx+eA GzjiPra8me5+B0dc6NsaOCYx6JQj3mDdyhHhPL3yIK5ReYyhdqkU6jEW9L0mKWcoAzkdNmilsHIQ qxSFBELGLL/iqGvKvIkN7XSKWVEi8JPOKhpOXIGc8SYIm6ZySJCDAq/xUA8N1VHk/2gJy0gS7CBs SnAKgR5i6IU6aqtJroF46Dy5FeZGuifve2iGjuw3V2arIUJ8DN5IqIdGwaJyjnHyBK9EocriKQkN pJRUjaRASkgWjupRbIzwuoBMFgTh4SmSsim2VGJsE8HQTYRqmCrsd9Q0EJpA6H5hZlbGAVcuQWNS 4LE4Q5xwwsGZlSIepLj46nGAewWBxOJd6KCEMS9ejZPFg7AxABDuLJW3hddivxBdeK1AYh2pBe4r XmIBAUiskMfqXGGzgonlXOek3RSQWDAZtWBlUTCxoAxAKoB/Fkisl5QekSRhxUBiA+oFQvJ2CoX0 JZAIG4wwuvqUFUwsCNr6JlKcFUzw/exhU2Ikr8gVk8LnXLJTwFxeDtmlIGGBhoUUGC4+H/U03hFE 5KmCw0DXzdQlwvWTLKqwK05dKQTxKD0fHcbkup0/9ouWU3Gm9N8TxJP4oO7OkUMl5HCSvsB1cnj4 /Lng1Mnhn8YLb7Fz5IUnho6B6hInvPSJGzjhSUPmCh8k/r5+OWaHE3IVCJdLkiftsMUNZ3STWWKF lM+kojXp2In23BbWZQXwVOpyIhTNoiIHnLK0yti6i4yMCxU5lT1O57Rv4YPdPAAQ88jKgbqrLmMw mfBykD0Oi1u1sVkWRykv/9G9ynsy0djeyAqbbCATQ3OpkYl9w6lJKW5rs1ES1M2sUA5pZxeN2Y2s sMk6u2icQZhi1107UJWodmnT/oT4YZYeTzwTPyQUy1Ya8jf7cOkcPtyrBJMdWoivXlNJ1qbh+/tp 6Sr+2kq/rQb88H0TPY9l565dyDfkD2QgELklZU4bf6dQoSKmg7Lj9F3WMMF9q27HSYhYk45vvJb7 SAlLghgoPP0qaRdgwUrhAaHLGgT0uTfdLnscpK0A2IEF2WLhmnb4QAUjBX7y0ga5icK3SL+Qrd9D 4VWj8NNdq9Ivt3mPuNESqu1bKPyGWztNnu284TbQ9YaQGmQdt/GN767Ew+77RtefB4yarOM2Uviu O1L4Lm3aO9yAbMFtNKrjdoXCwzaydhDNzpLxpJyyP5DCL1UFFp7dVRetg8IHeLT0d7ZctVL4r067 Fv3U4iBnaYctFJ5mHwEuwHA1zeyFxEMPOZ6OjtzK4fkCnCzQ8lwYPF09jj8EDIZJp61SeG5bIgYR kfihcni4oEg0pG7Tg+IKVDR6akNY0yXkKWIVJBkKWEm8NJtpCDohhSuJhzHyFDQNFt1IPL1entI0 iTuLp+Ent1LS66ssXuyMLIrOKbyysniIN/8S6si1Ef1HCGOydLXpN0ND86hJS5X2Hq7qLF4IsDcU HiuLxzOn/qws/iCteWiA94QhRKhuFlQGFh9rD93bxuMTrqMDCiyNx+PXhAukFb3Q+OanJLisPD4C EAFKcFl5vJ1EEgSXQY/7L3i7vKsSeQhJ4iZACy4rk88qESuJrUgWJp9YbIJHJ8FlZfLUdDxFox9J Y/KJSENNxbsXJi8VYIK316sv25h8hH/TfaHTuzB5lkedRhxnwV0vUpVlQWVj8pH2fRFQNiZ/dKcw +aP0fJA4ewwXJk9n+9CfMfRnKGfWTm8L72uUuEDkycTT3ect215q8m4Rav34X5TG32AmdecSRwH9 N7D4C1+4ROIlVklclI/t8bhT3/70He5ud2Ct+9oi8Nn8cNH7cIS+qpMPfXU/DR+pN+41CQ0x4MKq hh41x8aaLHcuR7cdO9PLIq52piNJU7hKz6jk/lXGlU2tRKTn2iqR5cZfahGyE9cqFOYQnaUSIU6j jI7IpqUSQQZxIGPV5wYZp++M9scqETlt3byllhBKn6jmK+UaTI5QklMZX20LlthHHSPaQyVSKxKW tvGaoW7Y+M8m65yo8SS5+u66fGK9Dh85UWO95ysREvbaUjxNCQeCOpKkTlo7uV2oT4LwntIhqU5G ctu0PyH+/ZUrEZNos3BJ2eoGubrm7pc0QWdxG095GmQLJuKWptsqkcVVTTq+8VolYrmhCVjQqo7a GOV+2lULlloiAwxZcZUtEMj+6bpd9jhIV+11466NjrOViLT3ijQb/08qkebl7vuOG5fRtYIXPDqW /YR13S6TC/ZlJ4xvvFaJHH1PQ/sMRk02yZ31OnDSdbtsxK2hef6QjZmm47aU+x8bONmnmj+yEtm6 TkOausG633SZYGRoy3FmhoETA7mjH0+KIbXKzTqIUt1Yxh22cRMZakgk+HHcRGYSPAG7j5tY3O/p h2/jJiKwXFZsanDXCiE2wPrXcROmJmhq0Orfxk0oEDCAHDyMm8ikmefKQC5m67jJJE9ZGb1o4yY2 kLuDpVzZxk2ojWDPIlrHTSyNakI1Tel13IQULHWAm7qS3F5FzRXyNm1i8BdXJMOsycGRdbBhlVLa YOMyz3M1hFGFaYFjG4/gMELzU+X766zJJB6jaqOcxK46ayL0neeoJfqwifinCBzbsImT0CRwbMMm IkmCx6DnvNzJCh68oA6bOA40b4MBtWETJzdFgscwbOK4GCqCRxs2YTwEMgAc27CJo5RMgscwbOLE zQLINmziuE8yFZE2bOIoFmUycFDjsoDKpUKyzJpwWzEbuYFooyaMAlVf7kdNmnT08Eq0Oj88aS5t h+/aqEktQD510kS6gTfUIAcDLhYhRXqRf+6gyS3Gsu0g7VIML8bur9RvuVO49JWr5Qid2vbFffi+ UpIsSf5cKG674QjGWpP09bWvHTtDl+5MLq3vWJjI1eBZLx6LkyWzXC1OnBxx6EtPsiTjVTbOoIzF yZawrFxECPchLrWxGYkGIpvaiIxwCXJVfW6QkbXPaN9SnHTzqD7qVI+Y3FhYH5GhmbYysy5j9GFb cNeWxbWR5zfK8+cbCoTvapHwkYkWS/DiItRO61SKDNlISGIekbjb6MhS3LWJoDfL24c9ti9DaD7J xNH4gvMv7R8iqNZZakkfJ7ow4P4crbR15vrSmi9aRT+SzMnsIyyRUSvGeFiqtIFkmqhJPnGh0m4b 1c+9cPsEQ1Dto3staq9qRp2lrM9sxfTFGC/TU4FGJpkQOlG4uzg2meQSMCWalzy6j1jcIPx3vdpp sz4fHldBuxZow30f2iXQekFU75KX26BXr8crn8HzcsNHDUWSvGwdF4OMmTL88UnWnRizu60ap6G/ /B9/neW8CmVuZHN0cmVhbQplbmRvYmoKNSAwIG9iagozNzQ3CmVuZG9iagoyIDAgb2JqCjw8IC9U eXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyA2IDAgUiAvQ29udGVudHMgNCAwIFIg L01lZGlhQm94IFswIDAgNjcwIDIxMl0KPj4KZW5kb2JqCjYgMCBvYmoKPDwgL1Byb2NTZXQgWyAv UERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0NzMSA3IDAgUiAvQ3MyIDggMCBSID4+IC9Gb250 IDw8Ci9UVDEgOSAwIFIgPj4gPj4KZW5kb2JqCjEwIDAgb2JqCjw8IC9MZW5ndGggMTEgMCBSIC9O IDEgL0FsdGVybmF0ZSAvRGV2aWNlR3JheSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0K eAGFVV1oHFUUPrszO3mJQxFtSyt18K8hpGFSrSYWtdtNurtN2K6bjTZVqtPZ2e50JzPjndm0CX0K gm9aEMRXRXwSLYjQasTkxb60VKiJFIsgKLRYQRD6IAp+Z3ayOxuRzHBnvjn3O+ee8917GKK+ZcP3 nbRGNOeGIl/Jzh6fPaH1fUdpUqmfcBlm4GfL5SnGruda/O697q1Tii039nGs3rktvzI1KzDBWsHw aoE5R5TSiZRh0xchUd/rsI+eDX3G7wM/0KxWcsCfAKuxLyA9mLdcS9imlhfGglYWXt12krluNc8x trzmnBbnytcejP6gOT2J9yByPlczxhk/BfyhaUxMAw8Br/vh4Uqbk063mjPZtj09VBdHZmL78Uar wHiYKL202Ki+DLwN+KJ7qnQs5q+YQe4E8GOw321YRd4PjUjaZofFKjB8JV14FeaDI52sWeMTwM8C LzW9Sc5hJ/ByMD/NduZ/v9jIlYCxlpw+YxwtA28Hvt9y8sxHHHnAD8sccxR4ynVKvC7qld+0gqjG AeBPw0a1EPPXQ1Fl30dg/6tuHykCQ4fMQw1RYDvyyRR8JzpPTwMviVaFa38C+JIhJvLAiJn5yXJn WENgRaGXUgZZ5NEpPE1y6R/UHpBN8xHySWCujm+H8mC4GALDAes00K8UYp6t7B9QEzb2ZUaAZxlD xP4a1fDV9rMxy4gj3o58zE3cHOK4tEgGeO2V78Q8T94h6/KTGAflKfk5eVQeI01+QT4kPy+Pwzom H4x8BHwXELVbAa94B1Hbkd6gVk8+q8g5hI9DP4PjRRkGyOBvRGhGzIQaF3a1Bnz/vbeXxGu2ef2d PxLqcG3NuM6uPglfOpZUO9K/tlntzC+Z25k1PG9mbiWq0TI/Zm7hvtlTlxevZqM+G5lvKMva29hV r4e9sQObWVlU7kR7ModqWX3eUVaflWwBh3jWYXVpXzLilfPLOzu8BdLW5Euv3ui/cv5/NWF9WGeL EqrU3Qu7fP/kx6ym9VbpXomWhvSL+l39I/0H/Xd9Tf8A6DfpXekL6WvpsvSldJU0aUValb6RvpU+ k77C1+ewrkqXkVvy1LVPWef0INP2OTTjE8b18CkOiBVgNtfP1g2lzmCumymf7c0rsM7dE91ZSz2s 7lYfVcfVh9XH1Sl1UD2gHlJ3qPsxRtSCuhczuzsqcU+x1jbeZbw3+s6m2Uir9o5wVg2oJ5Clgbub F/eo3YmGOKn7oDNH63J4jXZ324iixd3roWMNmkHFNp2NtAvw7eAbu/kfb+5JZJd6BSfLlvfII3Ix 7sGsfABdONnTj6PcpcqEMq5kSVMGlTFlRDnKOKqVO1RT9mJ2DM+JZPaInuD0KIK/T2idw3+LKOf5 C8I+3Qi1/br+jJbFb9LSiq45PKQZjqNFU4EmrMAS81ZtmPgfzH5Ef74Y/VtT26+aLTHftlEqdY3o X/q6h3sKZW5kc3RyZWFtCmVuZG9iagoxMSAwIG9iagoxMDg4CmVuZG9iago3IDAgb2JqClsgL0lD Q0Jhc2VkIDEwIDAgUiBdCmVuZG9iagoxMiAwIG9iago8PCAvTGVuZ3RoIDEzIDAgUiAvTiAzIC9B bHRlcm5hdGUgL0RldmljZVJHQiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGFVd9v 21QUPolvUqQWPyBYR4eKxa9VU1u5GxqtxgZJk6XtShal6dgqJOQ6N4mpGwfb6baqT3uBNwb8AUDZ Aw9IPCENBmJ72fbAtElThyqqSUh76MQPISbtBVXhu3ZiJ1PEXPX6yznfOec7517bRD1fabWaGVWI lquunc8klZOnFpSeTYrSs9RLA9Sr6U4tkcvNEi7BFffO6+EdigjL7ZHu/k72I796i9zRiSJPwG4V HX0Z+AxRzNRrtksUvwf7+Gm3BtzzHPDTNgQCqwKXfZwSeNHHJz1OIT8JjtAq6xWtCLwGPLzYZi+3 YV8DGMiT4VVuG7oiZpGzrZJhcs/hL49xtzH/Dy6bdfTsXYNY+5yluWO4D4neK/ZUvok/17X0HPBL sF+vuUlhfwX4j/rSfAJ4H1H0qZJ9dN7nR19frRTeBt4Fe9FwpwtN+2p1MXscGLHR9SXrmMgjONd1 ZxKzpBeA71b4tNhj6JGoyFNp4GHgwUp9qplfmnFW5oTdy7NamcwCI49kv6fN5IAHgD+0rbyoBc3S OjczohbyS1drbq6pQdqumllRC/0ymTtej8gpbbuVwpQfyw66dqEZyxZKxtHpJn+tZnpnEdrYBbue F9qQn93S7HQGGHnYP7w6L+YGHNtd1FJitqPAR+hERCNOFi1i1alKO6RQnjKUxL1GNjwlMsiEhcPL YTEiT9ISbN15OY/jx4SMshe9LaJRpTvHr3C/ybFYP1PZAfwfYrPsMBtnE6SwN9ib7AhLwTrBDgUK cm06FSrTfSj187xPdVQWOk5Q8vxAfSiIUc7Z7xr6zY/+hpqwSyv0I0/QMTRb7RMgBxNodTfSPqdr az/sDjzKBrv4zu2+a2t0/HHzjd2Lbcc2sG7GtsL42K+xLfxtUgI7YHqKlqHK8HbCCXgjHT1cAdMl Detv4FnQ2lLasaOl6vmB0CMmwT/IPszSueHQqv6i/qluqF+oF9TfO2qEGTumJH0qfSv9KH0nfS/9 TIp0Wboi/SRdlb6RLgU5u++9nyXYe69fYRPdil1o1WufNSdTTsp75BfllPy8/LI8G7AUuV8ek6fk vfDsCfbNDP0dvRh0CrNqTbV7LfEEGDQPJQadBtfGVMWEq3QWWdufk6ZSNsjG2PQjp3ZcnOWWing6 noonSInvi0/Ex+IzAreevPhe+CawpgP1/pMTMDo64G0sTCXIM+KdOnFWRfQKdJvQzV1+Bt8Ookmr dtY2yhVX2a+qrykJfMq4Ml3VR4cVzTQVz+UoNne4vcKLoyS+gyKO6EHe+75Fdt0Mbe5bRIf/wjvr VmhbqBN97RD1vxrahvBOfOYzoosH9bq94uejSOQGkVM6sN/7HelL4t10t9F4gPdVzydEOx83Gv+u Nxo7XyL/FtFl8z9ZAHF4CmVuZHN0cmVhbQplbmRvYmoKMTMgMCBvYmoKMTA0NwplbmRvYmoKOCAw IG9iagpbIC9JQ0NCYXNlZCAxMiAwIFIgXQplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMg L01lZGlhQm94IFswIDAgNjcwIDIxMl0gL0NvdW50IDEgL0tpZHMgWyAyIDAgUiBdID4+CmVuZG9i agoxNCAwIG9iago8PCAvVHlwZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIgPj4KZW5kb2JqCjkgMCBv YmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvQlZQSUxOK0hl bHZldGljYS1Cb2xkIC9Gb250RGVzY3JpcHRvcgoxNSAwIFIgL0VuY29kaW5nIC9NYWNSb21hbkVu Y29kaW5nIC9GaXJzdENoYXIgMzIgL0xhc3RDaGFyIDEyMSAvV2lkdGhzIFsgMjc4CjAgMCAwIDAg MCAwIDAgMzMzIDMzMyAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgNzIyIDcyMgowIDAgMCAwIDAgMCAyNzggMCAwIDAgMCAwIDAgNjY3IDAgMCA2NjcgNjExIDAg MCAwIDY2NyA2NjcgMCAwIDAgMCAwIDAgMCA1NTYKMCA1NTYgNjExIDU1NiAwIDAgNjExIDI3OCAw IDAgMjc4IDg4OSA2MTEgNjExIDYxMSAwIDM4OSA1NTYgMzMzIDYxMSAwIDc3OAowIDU1NiBdID4+ CmVuZG9iagoxNSAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0ZvbnROYW1lIC9CVlBJ TE4rSGVsdmV0aWNhLUJvbGQgL0ZsYWdzIDMyIC9Gb250QkJveApbLTEwMTggLTQ4MSAxNDM2IDEx NTldIC9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgNzcwIC9EZXNjZW50IC0yMzAgL0NhcEhlaWdodAo3 MjAgL1N0ZW1WIDE0OSAvWEhlaWdodCA1MzIgL1N0ZW1IIDEyNCAvQXZnV2lkdGggNDc5IC9NYXhX aWR0aCAxNTAwIC9Gb250RmlsZTIKMTYgMCBSID4+CmVuZG9iagoxNiAwIG9iago8PCAvTGVuZ3Ro IDE3IDAgUiAvTGVuZ3RoMSAxMTc0NCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHF egt4VNX179rnPc/MJJlnHjOTmcnk/YJMEghkCHlBMhACxCQmkAChgYIGRR5aKAIaCLZqW+VR76VW qojVOwSLA1QvpfiXovSzogWRSv0XUIuR1ouiwpz5r30mRJKvfz/ud/16z5k1+3n2Xvu31l5773XO 8rvu6QYdrAMWGtu6eheCcmVvA2Dq5i/t6o2lEw9j+Mb8FcudsTSfA8BuWtj7vaWxtPQigGbr95as HnredAzA1NDT3bUgVg7XMfT3YEYsTcZi6OlZunxVLJ3YgOHyJXfOHyo3PYTp8qVdq4b6h7OYdt7R tbQ7Vj+b5mf03nn38qF0IobtvXd1D9UnLcjfSSCYmwL3ggqWgAQMGPBGDsWPNFuBw1JajhQ3Pvn4 3Ljyz8EoKc390pe3jkZOHDj40tWz132ataoarKdS6tMCfEbIlDMBtATL39OsHS6hpfRKCUN7dhia kOqQJiKNRcrK3isFDpJHILHjSkBFHBxoHKdtn75C8lAGF5X/EMkLaHWgmr+h3DF/w4a6zEkqUg8l HAEHqQaPElYNeJ5zhMnEAY8bgwmxgBkoScEUBFQlHkekZJ7jeklYIoEkx5eenzquIn3hqXB87il0 /AnrvVlS6zgxCcsHHK9nhRkMjnvCHAnEOY557nf8piTT8WLJeMeAD/MGHHsnYbDfsavkfsdTG5Wc X2YpwZOeMNkx4PgFDfY7dmL7j29QCh6LPbg+FvRuVDq6c58S3LEvzDy337HUk+6Yhw+SgMbR4Vni aPeUOWZNChPvgCNIH9vvaPCdcNTTrgccgVhH/ljrxR6F46JYtzmeQ46MWA9ptHYgweH0NDhSsP2c XzzuyPHMcUzKCpPdL9VlZHnqfI/7w+SK0gcNkFEa3BEL5vteJs9ALWSSNvCS7fvqMpFn8siAYwMG O/bVZZR4w+xHgXjHPl+dbyOSH8mLNDtMZgVyxK3iAnG2OEbMFjPFdNElpopJYqIULxkkvaSV1JIk CRInMRJIieHoXwPZVJMSBQMNBI7+c0rcwNA4/uE/MERiYCqEBXjAvKLCWhE/0VhWU/Uv/jqVzM6q 7G8u6zfRbCtJCT1eP7MltCelNVREI9GU1pvK/1+i3ZX4dH3T6n1Nqy81V3e7qzvd1d1InaEtK3qs oXXznM69l1bTAmeITe+cN7+Hhl3dodXu7qrQJXeVc2+T8tyo4mZa3OSu2gvN1bNa9jYHuqsGmgJN 1e6uqtZ9jdV100b0tXm4r7rqf9FXNW2sjvbVqDw3qq9ptLiR9jWN9jWN9tUYaFT6ys6uXjSzEvjD YOSPQC6/FVK4SrQsED2D9B4N5ZnRy/yboI5GooMsWjeSRuncNZII/wtEeAnWosV5C/YQFbhhkBTB uySFZMFpkOE9+E+wwxb4Bf5Xw0fkC7Q0H5MMrOOH9fA/YWe0F3qhAu+PCA8mKIWPo/dFj0W/gkro h6NEJAkkJXoA8qEP7x3wBNEy86J7wQoNsBIt+3r4A5yJDkT/ju374QIxknxufPQvqGA85pTBZtgD LxEXcZMscnv0AuZbkcd22BMNRlfgc5exVj5Mg/uwtw+Ig6STbLKDvM8ORtdFf4xjS8ay2TAf76Vw P2yDJ+B5pdY8Lpk3YftVUI9lP4Y34CP4DI1uJqkkq5h32L+z/+DGczuiR5GP2dhfJ+wkLKLiIbPJ AtJLnicvkt+TL5gSpostY9/herknkbfZsAmehJfhNTgJf4FLMAhfQ4RwyNNEMp3cR/4HPvefzBim g1nDPMScYS6zhez7nMht4R/gD0W56DvRr5HnVMiC8TjTZ0ALdOO9EO6Ae+CHsJGIsBX2wu+R23Nw jqiJgeSTQlJLZpHbyffJaniU7CIHyVlynlwkHyN3CYyDcTP5zArsbz2zmXmeGWAOMIOskV3OrmEP s++zX3AmroM7jPc5PpdfLiQL9eIM+WfyuWhu9JHoDpSLGW8PZEIuTCQcorgUNqIkNyNmT8AueA5e gAEYiF4jZXAU/oR8fQCX4SpKLBlvFykipaSRzEAOl5Cl5IdkG3K4h+xHLg+RQ3CKnCLX8JbBxqiY XOZ2potZjfcO2MacVPDRsi42g81l69mZ0X+yz7N72c84L9fGLePu4/q5bdxOPpmfwN/Gt/G9/GP8 fv51/s/8Zf6KkCL0CbuEF4WToiSOFbeJMklDXpzECy/CK6h1j7O9mPbAZLIRpdoMb6D2DsKrcA2+ gsPwDEkBmaXSTI8+CeHoJpTmy/Ab9gdQDo8yP2WmRivY3ayKFEWvYlsFKK/hO5CVmeFL93rcaS6n IzUlOclus1rMpsSEeKMhTq/TatQqSRR4jmUI5FS7azqdofTOEJfurqvLpWl3F2Z03ZTRGXJiVs3I OiEnfa4Li0bUDGDNhaNqBmI1A8M1icFZDuW5Oc5qtzN0osrtDJO2GS0Y/1GVu9UZGlTiQSX+iBLX Ydzlwgec1daeKmeIdDqrQzUrevqrO6tyc8iBAC4G6twcOAAQAA1tOASTu9agcYXJtEZ1yO6uqg7Z 3BjHMtZb3bUg1DijpboqyeVqzc0Jkcnz3fNC4K4MxWUPPU6fQyPobWrBvnNzFoWQf9iiXeBesCUc gHmdNNbV3hJiu1pDTCftw5gdsrirQpZ7L1i/Sd6IVT90U2GI8dZ0dffXhAKdWxB0muykqa6HMFU/ 04nNMg+0toTIA8gcZULhPTaK2DLh7VzsDKncle6e/sWdiDk0tgzYA/Zqd2dVawiaWgZsAZuSyM05 YF073oWgHMidlDuJhuNd1rWx8MMNsfy3DtPQuvboXzGsbxrGhdC+3VOQzZBzPnaCWCCvpfSvuxT6 55cifHi1EhzlIuRncohBVWK9Id47pSu0buYQG109VUPMLa4aUNnsyrpU2Yr1O/sN41CAWN/gdvZ/ DihZ9+AnI3O6hnIEr+FzoIVU/sMqFCJdN+Ir6PrpxSWpx+ruoeJboYga025r9U0ZmKbrVi5uOHPq w6BqbNlLyI9bwyT6QBiqUg7gAsPOnYPF2VThFlVhd5jIycGMLBfGkIMa7KiGaoaz39k/ZUG/s8bZ gyrFeZUQC7r7W/MRsJktCAvManGFAq1Jw9Hu1tZx2E4ebQcfwer9rdjC4qEWMFSy8iNYKT+nHkeV 3tgyoyW0riopFKhqRdBRiQ83toQOo/62tmKtgmFOkeM1i6xDPBcizwVZWF4UawW3Neuwidb+ftrm zBa3K3S4vz+pn866WBp3yKMzAkMZYaBVKMJhsq4Rn8XA7UpSIHe5XchWK8V0DCrwDQXCbf23I1w8 zDc+6UduixWES74jhEtvBeGyW0J43DCnIxAejzyPowiX//sQnjAC4YnfjnDFMN/IZAC5rVAQnvQd IVx5KwhPviWEq4Y5HYFwNfJcRRGu+fchXDsC4bpvR3jKMN/I5FTkdoqCcP13hHDDrSAcvCWEpw1z OgLh6cjzNIpw478P4RkjEG76doRnDvONTM5CbmcqCM/+jhBuvhWEb7slhFuGOR2BcCvy3EIRbhtG OJAUgpvt8LpRZhe+c8N8+wjI278d8o7hgSDXc5D9DgXyud8R5J23AnnXLUE+b5jTEZDPR57nUcgX /H+EvPsmyIF/DXYwZeiy2AOtSCZMj0V6EvM28s3wFNJs7m/gwpCSm7sbxiPVYl4FhvkY9mHdzUhb xBRYR9NIlUhr2BRYj3Uqabs0LZSBHtMm3BfH/HjojAMBzx0ATmijjpMRF4P+zf+7i8NT6c2XcHMC T5D0knAjFbvUoBmK3Qi0GNGBHuKUDAMYlTAeEiARuTZjyoLnbBuerQGSkJKV8rEwFk9Ex0gzOUb+ wfiZP7MCu5uzcr/ls/iNglWYJzwu7BfniC+gH2me9GtVkeoHqjfVevXTeDLeAYDntCM4UhEmBly8 kILnH05MYUHNcyksy9hVgphCwCap9riWlKNzaNqV8mCkfJrhi/KgIVIOFeWRckqFBWOMLqMPaQf3 VPj6Cf7I1xPDXNO1FyiLBFrl+cyj/BkcSQf1ch5EGOJhbvakJMRfwpFJkI7kR6pBakZaiLQC6UGk x5GeRtqP9B9Iuo5JPLyDkQtITAeEgckPgza/oDDBXzJGFETBZEgwW9y+dB9jNPxx+rZTE9YWOlvH bjxZWz1tCzct/Hbvh5Gnj8p/lKPbPu1qeYGUkFwST/k0IZ9Bhc+xAWu8UZVgsljs8TopQcXeofta ZUs0veOqPEB+DYjElSsRY1lZfBl6hqouBqGiorAALHicZIU44vaXxBvH+tLzyRiyefo9W6ZV157c OLbVWbh2wileCMufyZ/KJ+U/vNDS9ek2QkjR0acjH/aiFNALxO9GeTBAteNs4Ps9DPHxGepSoURV J/SoV6k3cZuEHexj3DZhD/srbrcQJmH1MXJMfZo9rTYRURAYkFQq/FMTkWcS1WpvPCYTed4bj2Wi lEX9g2oNHnQFlZrlJY0OR6hRcwIfJokDKpbBYL/apu2+5y5r9opphivWYKSsDH/GMpsyUms+VFjK gxXl5fFlZfkoer4vL3uNoR634tzhpBB3tLUvzzqUwWIGe7TViDXx12coLxeRCgtIB3QQlwYdES50 JLgIk09WhJ8j7YxaHpgb+WCh/ApzEP0OVWTG1xNJvvwnRUOfRGy6MKbC2ZAJrYGcZ7lnxGfi2ZXm PjOTrM4ixAdZGYwmyyclG3i/dbqhxGHPBo3XZ8vK/i1JBRc0oftM0eGYCgcHrwzGl0HFYEUkviw/ UjbEmNFV5C9G4bkJxkqUqA+oswA1K5UogZ64XUYXeY0s7lrdWP19+bcY8c+bW9xJapZVVaVPXXZ3 ZVZF7e+WRRYwb3BH5ENTOr7nskRek1faCzbdjX5Vtnj7nA19TXnpmQM/3NBTne/PwIGh1DeiEu7n z6EmcFAQMHIMunI5ASXEoXPZxgsH0a/vIsV7Vw+NIqZ8KJEKRDUT+fWR/fIfSdF2/gi6Ghl4CjHT YNMSzryJgeStZKvAaLM4Ts9mxTF6SSpJsJtYnVePih0mKftcTc0j4MF2EaD8QQWYdDpkRAY4GsEo Z2LPrF4qo39v6WpSKH/5ufya/Edm/fvIcuc8edriu+XI6cin/JHzl9EGoBcueobX85chDz2DTwUW S3Ho7U63aWxxFpclfaG2W7co7UKuJtOQacqwp/vGmUrtB0zHTWdNb+VcSrhk/irha/NXuXF6MGrS rA6vRfKm6TWcNe/tbOvbyZPyE1luUrYq3/p4vtEyXXo8w17o8BtvA3+eraAwTFL3uZ4fGhmKHI0X St5YNoi4DVaUDw4aBo2WMoJaShUVaUgPzBbzmCH555N0X3rxWMBBW1wYdacJpkSL2UGwjikRXE4o JuQ+fWb9/qVV9wcCm5+42PIYcRLLx2SKJJ+WltR9f+WPa3J/Kj8ze6P8unxR/qu8n5lBXusuut2a t2ZKhi/VPXbCwnf/gwhXLz1Q6u1snu6zuydkTO559bj8OREvchlom1wA3OsoSxFKA1oiZIkMJ6lQ NSBMWgYYL87floBKQEt92EXnLlrq4JVIZNg6URuNCqLc3OtyrXxcruaPyNeuTeZeRi+b0r6yFmgI G9jRwvSwW+Ex7glhm1p4EB7gtgib1A9qeDefpSnkJ2j6NY/wOzW7+D2affxBze/545pT/EX+Km94 kN+sYd7kz2kY3srxAueNx1WEt6JrTfDGo9dPY1VrAI0SGimNFTRq8MYThjBoiDgQBTRLahVB4yUJ IseAhtewoool1EapthOblg7MFjNKMWsUNFiPGo4qdpiaqDKczeXluCKhdUKRGvqyJWqZ7m09ajXw /12C7zMMV0MbfteyDrKsI5OoiCv2I6RP3kHOyBPQwSwSPVmAsXNyv/wRc5k5KbvIuUhZhEcXPOq4 G+dbpTLfVPBMoOEA7BeZTCaTn8pM5duYNn6h9DPpWeZZ/kXpVelv0teSXiMRBIdCI0qMlRBvPM5V nsFJL6rQr4sillQaKmQSJnN+o5IYr4iCnkMFrdZs/0bQ1EJfGVqK8ifkW3HmWqiBLiNonTnFPN/b +qqV2urhFI4Vh4qGmKoF/rPsBdIhJ8hvyAy6rYt0/JHrPZE/M1nstshaZj3OYRbGR9/nSrm5uEcp g3HwcGD6eKbYv5psJtzpVJL+fy5mfejW63h8S5Bgz0ZfK5eel56XRTO4JE1akjlnnEPMUmtyijTj EoIQzBtXnDUx3V5uDyblSsFi2/jy3xIb6nkdeWHITA/N1vPGshMXLijTFTcbJ3COWuiCglPWosSz h2asnsQRuvon4sT1l/j81HjjXEW77cK4qwgnqzHRkkosJlce8WFNdxrO6hJ/SQLzflJJQaDNVzlj XPvP2eenp03oaOvOSlXLg6raZSRh35YtDJucLB/XqdnxwfblP/vdz2f/qpeJN5pUWoPF1zRl0pKH L6vj7CWTxxR5Kx5uf6S29lVZO3ZqaYYuyzXOG8gtfvbnf2grNJG3EUbUk9roGW4s4piCbxXuCFRv N+82M33JZIqpJb4nfpV6dXzY9FrCMZNkZQQu5S3Ok2oXzXq11vCS1pOoSTX44xzgT7Wk2J2S32Jz OPtcddNiM14xbsayyBXFuA3SGUEtHA0pRstw3VXMFwWJmjd/iQthcDmZYgOMQeNGWIPkKuh+pDg5 ecyPFsxSEbd61oPyV/JXX5L4f55AXZWTmEMTCisfbli7asqmJc3rlx8ipV8RGykNf0x2KWOrQB3p 5g/je/MUmB7I+UiLuxJTCmNgweIxiII6xaPWmFh7gkNwsD7O7rD7dbZUxzZXXfVNQ4hcOY+GmNpn /BlxZlOrDB1gtlADVozrbxpQluNjKzU1x+YxzL07CohLvjThieX/W75GyKmX1nZPbFpzz8rVXPtt QUb6OrC1q4UUf0YsJHD9rhcfPtY89uWHtv4G9To/epYbh/IQUPvS4LnAlBqpL3Er2Y77IqLiBQNv r+drDFOcD5IH4vocatbMWhLMCZY6qcHcYJlibze3W9rsZ8l73McpHzqvOg1TSY1hE7/BwOF26rHA mOn6ufo79axenyR40lyiJT4nSWNmmTTWb7kvLbVTu07LaO0exqF/LNXm9iAUQ9KMnMe1qiNoLDs/ mB+D4wRKE1fkjkhs8i7rANTtPNxv4kJkMYuuoTVLkSpCZDTAeELeXKonh8T7bt90pjaQoGEiZqFr /MyWklQLcWvaHrr+pnyEOC4ksst/sHjZPZcW3tG1rv5Huyozi5IKuhbsJFqSR5LwMwO8CL5hAm4O /zKeQyoCXp7xMS36Hj2XaIkHrcciGkS15OfttgSDz2iz2l5xNQ6JVDkwBAfRNivSVGarGeehCYVJ N1ooPmVdmkjGsJN/VZybKP8l1bd02T3yeZI88ak2bk5N3YT7fxJZx2xt8TdsfSgywL8cuTq3nvLE 4DsvIHv411GKIowPpDVAA2mHdny9txfNjiCqlTVS8BERl8aBGywphxi6cUdDWRHEDQ7dkOKOjtIe +RxqkUIcviqVV17DIyLBt61A6N6cBW8ggQGi5qld9hEbxw83G4ytt9hobDtGdst/Iyn4ED6/Dr8A eYJrwzd2RyYFoQQ5x1f4+G9G8iItwnPfYjzbrcbwXgw3Y9iP4XYMt2P4LNIBpA/xZKDH+i7cBbPg wBOjB9u0Kv9exMCBrabg8UrCM0Q+SsqCzwh4tlKROHzCCEFIxFgqOLGWD0Mb3ZERN7bXiO+SY3Mw ctRwZbDsyo3R4IpaUR6M7ZNiphYnIt4mdkh+OMNviDIWdZnQ4I5Bg2uhIf/wQ2V5BjUjn01MX7gi 1yJ/kOhZdG+WBUE2FefP3LgmONFZOrNlCddWWlM2s2RxZAazf2JGw7yxUyIrmc1dOdOn57ZGernA ztmeQMmYxs7cXBw/1cUunLNmHGF9IJcnJuLFk1yLpkcjkHiDoPLghNBzagvvt8QxdptR74sbqZVH 6U4wtg/ELcNgRcxGAi4SI4YVG4uP7T8ln7VkrXjUn4x6mVBS2NK3iGvfeyKSxmxtzpt136TuyACy OMtbSf0GLFSijX+C60Zp0VN7MJBhYYmk3aTdZGAtOmvcQh3Le6yJosaj11itEuO32O2S32iz2cNk xb5hExDbrRrLhvaqiP5duEPxxBY2xep5lO0n7k2dYCLMpQcfXLOmr28Nkyd/In+I9yckEc2zjSRG Tv5hYNeuvXt37RpYKD9HZv/jE9ImP/0JE0As18gzuR2omzrUiqmBTEuCpE62Mx6naBfUngSNTS/p rDq/wZ4mOJIcVp/N5krb5mq8YaWuUDMVHFQslGKxhw22svgOrTTF8dQcudPwVE4nu6Ig7PK77//5 uNTu8qaVa1KISo68sb45P1e+SIx5Y+duYHYe+em0Va8Ec8PbmTLcNV/GffNbkzzVkWP85SdrM6cg zDiHcGfCXOPa8YQz9QCwpHYfE6fDY3FtwJYg6gSt2skUMAGGpSd5Rq/xaZWzzoJ9rsaFN3T97dgm uYPaAlwq36bmABcaNKu4dVAsk8Is8xdNQlKW7tfjXXjmMVQWNq7j2gmRz7JMb8WGyFWu8pWlGZMp TwzK/j18H94F2ZADawPTVQYh3aZjVZxLo6lXT9HUuqqcdZmnWCklzalVc+ZszmzPyYkXuZwMTU5O nEntTDEH00RTrhj02vO0kBKMy4Vgti0376aVnp5dh48yuMAj/DEliZwwnMADTWHBnI45uL1TlgRl mfQqhxicliMOMcpEThTcznQ8w8xXpRY/PGt+RoYcPdDQMHjqDUIS5L8JtvxlHdOzsqJ7Zs/653U5 +jl+HNDe4CwrKiqw2SbkVVet2/ruU8dKnOPG+QrNltKMGU33/fLEu7tZnAjoU4n+nVnF9+A8nbrf kBPn0OYYD5JlwJH2gFmEdoEIVhRNnHCFU/ngJygna5jo97k6qXjeLj8fKb9STuXzKbpY0NuAZ/Ur 5wsLEoqpv2mMyW2M7fVMooAHNKNpG7Hv3Zt2my5F33d8agG79HVSIL/5euTwZBch7/BisHAhs5Pq e/QjbjbaDupLawjkqc12c5a51NwsdouCXVSDYNbr1Dzutew6tc9u1diTid9qS0r+Zkmj8zK+LBh5 W8Gc7rLQ5CPauL/EbRVuPKmO4z5FpFsVypqXPGn23fUTP35+IV/inObJa2Z9NiuffMJVRu7syJ+5 IrCImXHtlR18UUJ5zgudh5hHUxA7Pa4ZLvxuSAtl9EtA9HTx6OmSkACJRVLnH8TxoN8RxX8Qrf+N mHYoVlBIXEnU0aJ4WxKYPuJ6eg/JlI/K7z33vHyaOgv2cJXXL7PGa6+w9usXMf5ZTIdNci3XiBhR 7+O7gV6fulm9UP2Yepf6pFrg1UQQkkWjLld06iaIhbp6sUOklneluFqns8T5dX2qTZptmrBGSEzU SjrGqdX64jUatSAyDknyoU+KRnVqk1ajwrOeChxMToLDEJcomlEZ9DqNNky0+7BAjWFAm/ATydZt Mj8b04oVeLQ9b72Oe1pKQ24pnLzB85HzuFApnimEgx59eDz6NK2699UxQ04pGqcn/XwqrGV4/sEj vL9kIvHFUGLoicBH9nqyGuy2bE7uJRM+/QA9UP1L1r6cnpdH1v+JYdTxxiVa7q7rZ1nPtTfl448R VsBPSRkKGn7VRb8M+lcXumNwTdCgJD242ufAGFyRS/B7onL81qkGvyqqwy+eGmA6rsEzoAlm4jdL zXAbfmnUhl850VkUj0QvgfqvK5sbpzRMy67rXrKie/mi+V25lXcuWUBr3bh+gJFNSPhNLuxGQn0B /L4Wvx0D/KIK4EusLCFZkTKQSpHqkFqQepBWIW1C2oa0GymMdAzpNNJHSF/igCUkK1IGUml06MK2 YThOcDUZmca6I8rxe9gR6Umj0pWj0orJv6n9xlHlM0elZ41Kt4xKt45Kd41Kzx+VRpBH8KvI+iZ+ ekaVLxqVXjIqrXwLfdPzd4wqv3NUundU+q5R6btHpZePSt8zKr1yVHo1Tf8XoiA0SwplbmRzdHJl YW0KZW5kb2JqCjE3IDAgb2JqCjc0NjIKZW5kb2JqCjE4IDAgb2JqCihNYWMgT1MgWCAxMC45LjIg UXVhcnR6IFBERkNvbnRleHQpCmVuZG9iagoxOSAwIG9iagooRDoyMDE0MDUxMjE0MzgxNFowMCcw MCcpCmVuZG9iagoxIDAgb2JqCjw8IC9Qcm9kdWNlciAxOCAwIFIgL0NyZWF0aW9uRGF0ZSAxOSAw IFIgL01vZERhdGUgMTkgMCBSID4+CmVuZG9iagp4cmVmCjAgMjAKMDAwMDAwMDAwMCA2NTUzNSBm IAowMDAwMDE1MDAyIDAwMDAwIG4gCjAwMDAwMDM4NjMgMDAwMDAgbiAKMDAwMDAwNjUzMSAwMDAw MCBuIAowMDAwMDAwMDIyIDAwMDAwIG4gCjAwMDAwMDM4NDMgMDAwMDAgbiAKMDAwMDAwMzk2NyAw MDAwMCBuIAowMDAwMDA1Mjg4IDAwMDAwIG4gCjAwMDAwMDY0OTUgMDAwMDAgbiAKMDAwMDAwNjY2 NCAwMDAwMCBuIAowMDAwMDA0MDc1IDAwMDAwIG4gCjAwMDAwMDUyNjcgMDAwMDAgbiAKMDAwMDAw NTMyNCAwMDAwMCBuIAowMDAwMDA2NDc0IDAwMDAwIG4gCjAwMDAwMDY2MTQgMDAwMDAgbiAKMDAw MDAwNzA3NiAwMDAwMCBuIAowMDAwMDA3MzM0IDAwMDAwIG4gCjAwMDAwMTQ4ODcgMDAwMDAgbiAK MDAwMDAxNDkwOCAwMDAwMCBuIAowMDAwMDE0OTYwIDAwMDAwIG4gCnRyYWlsZXIKPDwgL1NpemUg MjAgL1Jvb3QgMTQgMCBSIC9JbmZvIDEgMCBSIC9JRCBbIDxjMTBiMGJiZDdkMTJhZGIwOTNiN2Ez YzgwZTY5Njc5Mz4KPGMxMGIwYmJkN2QxMmFkYjA5M2I3YTNjODBlNjk2NzkzPiBdID4+CnN0YXJ0 eHJlZgoxNTA3NwolJUVPRgoxIDAgb2JqCjw8L0F1dGhvciAoRGF2aWQgUm9zKS9DcmVhdGlvbkRh dGUgKEQ6MjAxNDA0MjAxNjI5MDBaKS9DcmVhdG9yIChPbW5pR3JhZmZsZSBQcm9mZXNzaW9uYWwg NC4yLjIpL01vZERhdGUgKEQ6MjAxNDA1MTIxNDM3MDBaKS9Qcm9kdWNlciAxOCAwIFIgL1RpdGxl IChMNC10cmFuc3BhcmVuY3kuZ3JhZmZsZSk+PgplbmRvYmoKeHJlZgoxIDEKMDAwMDAxNTYzNSAw MDAwMCBuIAp0cmFpbGVyCjw8L0lEIFs8YzEwYjBiYmQ3ZDEyYWRiMDkzYjdhM2M4MGU2OTY3OTM+ IDxjMTBiMGJiZDdkMTJhZGIwOTNiN2EzYzgwZTY5Njc5Mz5dIC9JbmZvIDEgMCBSIC9QcmV2IDE1 MDc3IC9Sb290IDE0IDAgUiAvU2l6ZSAyMD4+CnN0YXJ0eHJlZgoxNTgyNQolJUVPRgo= --Apple-Mail=_7B7F19D1-5FD2-4EE8-8D39-3E3A46EBC4F0 Content-Disposition: inline; filename=fig2.pdf Content-Type: application/pdf; x-unix-mode=0644; name="fig2.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAHNWEtvGzcQvvNXzK0SGjF87nKPqdtDg6ZwYOWU5JDadeNA ThsraNF/34+7nCElrR5Ae6gN2NTsznCeHz/qC72mL/T8amvpdkuWtrdkyPaRHinGblxtxpWhDZ7k vx/pnozu6CGruaxmdO/66AdldBq8s/1kyJpeDy46Sr02+Olg1IVBd7HvqmxTZTHhmce2GyW6VYaN RdpYvGepJ2uj9qHLzss+LFPNPqlHGMWWhydjUPKZNWCltd07bfwQ6FFV2yxrbIt2s0MjkxjgbdFW 4z70Ekn7NKX06mZMtaGbKxTHjh9WllaD0ZF8SPh7+0h2SDq4mA11OnQ5vcoHo21Or8g2UCgy5z0e +piDZ91GBtdYytpw7QYNwu1hpvZ4aJ2yfdJusIFsCNoOPnv23RqfiteBVhEl74N3tPJq/UjP12uL oNb39JYWPy9pZbSjxe+8+MwLWiIK3dNivaTe64EWL65vVr/y489LNWl+YMkvvNjwQl6+YwmMvqf1 S/phPTa+5HY/DHUYBrIXuoTRQGz7YYgPf/BGstiwnw/86Fbe/rrE7CB4edRmofo5Tdt8J2RHS90c lWrmQduvOoaqkaVBpzwo0gnQLTIMinTCjsXcCQZT3/hRs2YsaowSH6bNeR2tc5aijqX8bir/4tWS 1p9OlOK4UWt1iqa1WVvqm5xUS4stah3D1Dc/tmWfBy8oTeClRhQUOJgAKGDwK6iIrB18PXQm9jbn dAI+r2yVNYMv2nnwm2wem+9SmQ7TWKs6VWunqoA+DRQOtaoeCiKTqnqudbZ48Xx75Mf0yPlhiaPT NlgLhDoc8J+462UWf2OJjMHt3yjVOAg8EE8feGoEDrYyUTIkT3i9TkmTSelLdnpunAGaLqFeM+P8 LmPO6NAVO3sNNHJJD2rxrDxin9/wK9/z4vrd8pxjADTvuj7NOTZo5DnleSk4c+G8nLDpeh1M6obG 6PzA7MKRYCzXRYr4JHWRKgrqbtvg31LA73sy6g4ZzayhqdN8xwN1Oovgpd1DEWy4W50aWUfnI+gG zA5o89BjEeIw4DwHi/Gm0z6aHfIRcHSa5GJLPlimGqIhuo3s46zFzIQm7oMFcx/Vbi9n/yPxVpWn bKosdXrAT+Yisj3LRkgWaWPxvr5b2ETOWt1nYhgZ5lmmRLvZp5E1YTYWcVSjgnR3pHa5if3QZUhG q05sZGSQHlQl51tk4JIsa5iH6LJsCnjG4jm08ti8t13LRtRxNnJwjJ9nI+ooGyk8RsbhPBtRi2Ns ZCaMfVK1y0bUDqkSHwQyZSFDKpRjn42of8NG8uFwWE3cJWaqXmXTWZbPrapbZWhJ7gTpj+ncEmw5 2pm7/hRUKRsXVEGvzTCbUgGQ6+MkpGU2jNQgDyC2R5jNJUb/U2azB5C4n80AZKEjfYscIqvIQROZ CZngMBYVgjPKGuQQ7UxwTiJHWx/FDBSO7PdGhjCRFU6TZdIZjaz2S2vxYuRgysA8x5eLjMdFBhjd G1DZlbUHN5kX43Wlo8WfMn4yYzJ18qhBh3KNkaOVeQWfueBCBVvkzD3ChXB4q5H2zpIiAZVTEeIC nQZcDDL12AWVE5yIznIitWD+dPjuK0mTxCcSoXry6NkSXYwr01noPBGlC2BYQwIPPizjjTA+poDV c12Y3/7/ke6pmVulDDxTM26q3dtxihHspeF7l6HICaMgOriL+665dFW+xw32LRaHN2x+KjWQ1H8t qZdOvZgENpQvgjANAbdofIUT85dCMww44MrYpYQuFApcva/tIpf6slALmTNx8S+eHRmiJ3l2rIUu cNEDDA2+1Gg8PE3So4mgnhis/3PYZ128LOzX/wAcQxoDCmVuZHN0cmVhbQplbmRvYmoKNSAwIG9i agoxMzgwCmVuZG9iagoyIDAgb2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291 cmNlcyA2IDAgUiAvQ29udGVudHMgNCAwIFIgL01lZGlhQm94IFswIDAgNTU2IDE3NV0KPj4KZW5k b2JqCjYgMCBvYmoKPDwgL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gL0NvbG9yU3BhY2UgPDwgL0Nz MSA3IDAgUiAvQ3MyIDggMCBSID4+IC9Gb250IDw8Ci9UVDEgOSAwIFIgL1RUMiAxMCAwIFIgPj4g Pj4KZW5kb2JqCjExIDAgb2JqCjw8IC9MZW5ndGggMTIgMCBSIC9OIDEgL0FsdGVybmF0ZSAvRGV2 aWNlR3JheSAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGFVV1oHFUUPrszO3mJQxFt Syt18K8hpGFSrSYWtdtNurtN2K6bjTZVqtPZ2e50JzPjndm0CX0Kgm9aEMRXRXwSLYjQasTkxb60 VKiJFIsgKLRYQRD6IAp+Z3ayOxuRzHBnvjn3O+ee8917GKK+ZcP3nbRGNOeGIl/Jzh6fPaH1fUdp UqmfcBlm4GfL5SnGruda/O697q1Tii039nGs3rktvzI1KzDBWsHwaoE5R5TSiZRh0xchUd/rsI+e DX3G7wM/0KxWcsCfAKuxLyA9mLdcS9imlhfGglYWXt12krluNc8xtrzmnBbnytcejP6gOT2J9yBy Plczxhk/BfyhaUxMAw8Br/vh4Uqbk063mjPZtj09VBdHZmL78UarwHiYKL202Ki+DLwN+KJ7qnQs 5q+YQe4E8GOw321YRd4PjUjaZofFKjB8JV14FeaDI52sWeMTwM8CLzW9Sc5hJ/ByMD/NduZ/v9jI lYCxlpw+YxwtA28Hvt9y8sxHHHnAD8sccxR4ynVKvC7qld+0gqjGAeBPw0a1EPPXQ1Fl30dg/6tu HykCQ4fMQw1RYDvyyRR8JzpPTwMviVaFa38C+JIhJvLAiJn5yXJnWENgRaGXUgZZ5NEpPE1y6R/U HpBN8xHySWCujm+H8mC4GALDAes00K8UYp6t7B9QEzb2ZUaAZxlDxP4a1fDV9rMxy4gj3o58zE3c HOK4tEgGeO2V78Q8T94h6/KTGAflKfk5eVQeI01+QT4kPy+PwzomH4x8BHwXELVbAa94B1Hbkd6g Vk8+q8g5hI9DP4PjRRkGyOBvRGhGzIQaF3a1Bnz/vbeXxGu2ef2dPxLqcG3NuM6uPglfOpZUO9K/ tlntzC+Z25k1PG9mbiWq0TI/Zm7hvtlTlxevZqM+G5lvKMva29hVr4e9sQObWVlU7kR7ModqWX3e UVaflWwBh3jWYXVpXzLilfPLOzu8BdLW5Euv3ui/cv5/NWF9WGeLEqrU3Qu7fP/kx6ym9VbpXomW hvSL+l39I/0H/Xd9Tf8A6DfpXekL6WvpsvSldJU0aUValb6RvpU+k77C1+ewrkqXkVvy1LVPWef0 INP2OTTjE8b18CkOiBVgNtfP1g2lzmCumymf7c0rsM7dE91ZSz2s7lYfVcfVh9XH1Sl1UD2gHlJ3 qPsxRtSCuhczuzsqcU+x1jbeZbw3+s6m2Uir9o5wVg2oJ5ClgbubF/eo3YmGOKn7oDNH63J4jXZ3 24iixd3roWMNmkHFNp2NtAvw7eAbu/kfb+5JZJd6BSfLlvfII3Ix7sGsfABdONnTj6PcpcqEMq5k SVMGlTFlRDnKOKqVO1RT9mJ2DM+JZPaInuD0KIK/T2idw3+LKOf5C8I+3Qi1/br+jJbFb9LSiq45 PKQZjqNFU4EmrMAS81ZtmPgfzH5Ef74Y/VtT26+aLTHftlEqdY3oX/q6h3sKZW5kc3RyZWFtCmVu ZG9iagoxMiAwIG9iagoxMDg4CmVuZG9iago3IDAgb2JqClsgL0lDQ0Jhc2VkIDExIDAgUiBdCmVu ZG9iagoxMyAwIG9iago8PCAvTGVuZ3RoIDE0IDAgUiAvTiAzIC9BbHRlcm5hdGUgL0RldmljZVJH QiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGFVd9v21QUPolvUqQWPyBYR4eKxa9V U1u5GxqtxgZJk6XtShal6dgqJOQ6N4mpGwfb6baqT3uBNwb8AUDZAw9IPCENBmJ72fbAtElThyqq SUh76MQPISbtBVXhu3ZiJ1PEXPX6yznfOec7517bRD1fabWaGVWIlquunc8klZOnFpSeTYrSs9RL A9Sr6U4tkcvNEi7BFffO6+EdigjL7ZHu/k72I796i9zRiSJPwG4VHX0Z+AxRzNRrtksUvwf7+Gm3 BtzzHPDTNgQCqwKXfZwSeNHHJz1OIT8JjtAq6xWtCLwGPLzYZi+3YV8DGMiT4VVuG7oiZpGzrZJh cs/hL49xtzH/Dy6bdfTsXYNY+5yluWO4D4neK/ZUvok/17X0HPBLsF+vuUlhfwX4j/rSfAJ4H1H0 qZJ9dN7nR19frRTeBt4Fe9FwpwtN+2p1MXscGLHR9SXrmMgjONd1ZxKzpBeA71b4tNhj6JGoyFNp 4GHgwUp9qplfmnFW5oTdy7NamcwCI49kv6fN5IAHgD+0rbyoBc3SOjczohbyS1drbq6pQdqumllR C/0ymTtej8gpbbuVwpQfyw66dqEZyxZKxtHpJn+tZnpnEdrYBbueF9qQn93S7HQGGHnYP7w6L+YG HNtd1FJitqPAR+hERCNOFi1i1alKO6RQnjKUxL1GNjwlMsiEhcPLYTEiT9ISbN15OY/jx4SMshe9 LaJRpTvHr3C/ybFYP1PZAfwfYrPsMBtnE6SwN9ib7AhLwTrBDgUKcm06FSrTfSj187xPdVQWOk5Q 8vxAfSiIUc7Z7xr6zY/+hpqwSyv0I0/QMTRb7RMgBxNodTfSPqdraz/sDjzKBrv4zu2+a2t0/HHz jd2Lbcc2sG7GtsL42K+xLfxtUgI7YHqKlqHK8HbCCXgjHT1cAdMlDetv4FnQ2lLasaOl6vmB0CMm wT/IPszSueHQqv6i/qluqF+oF9TfO2qEGTumJH0qfSv9KH0nfS/9TIp0Wboi/SRdlb6RLgU5u++9 nyXYe69fYRPdil1o1WufNSdTTsp75BfllPy8/LI8G7AUuV8ek6fkvfDsCfbNDP0dvRh0CrNqTbV7 LfEEGDQPJQadBtfGVMWEq3QWWdufk6ZSNsjG2PQjp3ZcnOWWing6noonSInvi0/Ex+IzAreevPhe +CawpgP1/pMTMDo64G0sTCXIM+KdOnFWRfQKdJvQzV1+Bt8OokmrdtY2yhVX2a+qrykJfMq4Ml3V R4cVzTQVz+UoNne4vcKLoyS+gyKO6EHe+75Fdt0Mbe5bRIf/wjvrVmhbqBN97RD1vxrahvBOfOYz oosH9bq94uejSOQGkVM6sN/7HelL4t10t9F4gPdVzydEOx83Gv+uNxo7XyL/FtFl8z9ZAHF4CmVu ZHN0cmVhbQplbmRvYmoKMTQgMCBvYmoKMTA0NwplbmRvYmoKOCAwIG9iagpbIC9JQ0NCYXNlZCAx MyAwIFIgXQplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFnZXMgL01lZGlhQm94IFswIDAgNTU2 IDE3NV0gL0NvdW50IDEgL0tpZHMgWyAyIDAgUiBdID4+CmVuZG9iagoxNSAwIG9iago8PCAvVHlw ZSAvQ2F0YWxvZyAvUGFnZXMgMyAwIFIgPj4KZW5kb2JqCjkgMCBvYmoKPDwgL1R5cGUgL0ZvbnQg L1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvQ0dZQVhGK0hlbHZldGljYSAvRm9udERlc2Ny aXB0b3IKMTYgMCBSIC9FbmNvZGluZyAvTWFjUm9tYW5FbmNvZGluZyAvRmlyc3RDaGFyIDMyIC9M YXN0Q2hhciAxMjEgL1dpZHRocyBbIDI3OAowIDAgMCAwIDAgMCAxOTEgMzMzIDMzMyAwIDU4NCAy NzggMzMzIDI3OCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCA2NjcgMCA3MjIg NzIyIDAgMCAwIDAgMjc4IDAgMCA1NTYgODMzIDcyMiAwIDY2NyAwIDAgNjY3IDYxMSA3MjIgMCAw IDAKMCAwIDAgMCAwIDAgMCAwIDU1NiA1NTYgNTAwIDU1NiA1NTYgMCA1NTYgMCAyMjIgMCAwIDIy MiAwIDU1NiA1NTYgNTU2IDAgMzMzCjUwMCAyNzggMCA1MDAgNzIyIDAgNTAwIF0gPj4KZW5kb2Jq CjE2IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL0NHWUFYRitIZWx2 ZXRpY2EgL0ZsYWdzIDMyIC9Gb250QkJveCBbLTk1MSAtNDgxIDE0NDUgMTEyMl0KL0l0YWxpY0Fu Z2xlIDAgL0FzY2VudCA3NzAgL0Rlc2NlbnQgLTIzMCAvQ2FwSGVpZ2h0IDcxNyAvU3RlbVYgOTgg L1hIZWlnaHQKNTIzIC9TdGVtSCA4NSAvQXZnV2lkdGggLTQ0MSAvTWF4V2lkdGggMTUwMCAvRm9u dEZpbGUyIDE3IDAgUiA+PgplbmRvYmoKMTcgMCBvYmoKPDwgL0xlbmd0aCAxOCAwIFIgL0xlbmd0 aDEgMTMzODQgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBvXt5fJTF+fjMvOce2ex9 Zc9sdjfn5iIhIYEsIScQ5BBJkGACBAJC5YhBqPBFBYGIKCCHQCt4QAhqlpDCAl8opSBgrYIXineL lq9tvrb9obVAdn/PvBsi5Nv24x/9dN88M/PMzDvvM8888xzzvmlZ+GATikMrEIPGTm6cPxNJv+wG hMjV6fMa58dwXRXkb0xvbXHFcC4ZIWbuzPmz5sVw8RmE5PZZc5f03a9vQMg2v7mpcUasHd2EPL8Z KmI4HgR5UvO8lodiuLYb8mfmPjC9r12vB3z0vMaH+p6PPgbc9ZPGeU2x/tnFkCfNf2BRSwzPugD5 3PkLm/r641qg7y2EodaLNiIZuh8JiCA1XPUICVfldsRCK22HX9abH/3yvvjib5FGlPD7ap6S8t8e OXr4+6abfsUG8e9QIbvVn+Z8SiQFISWG9h7Fhv4W6T5IvGE0IS2MqgFKAPIA0tKGm9EKvAc9DbAL gEGz8RNoCcBagGcB2P7SPsCO4Ce6WDF4FC9BVjwyqGCdd+stTrNc4Xw7jPnunzs/NP/+GLbA6n2B LV1xSDZcjnfh59AM5MQvIS9eiqpQMt5+MGWuswGa9qH5ACsAGCnFeF+XI8d5AqcjL4vhHh9ysPiQ 8w/ZGc4vs8MEdzlP+cMsZL9yABaMd560/9z5S/ss5wmA/bGmjhTocci5zz7XuckRxtu7nBvtYQz3 bIhlD9rh1kPOeSlbnDOypfbRW8Jkf5ezENrvCSqc+QVuZ579ijPTHxYx4Bn20c7U7N86k+BG6OaC Qb1BjdNm3+QcAk0Oe7l/CMAx3IF3oFS8o8s70nkUijDdg9UpBVvC+KcHq5KzvWG8NJhflbwlpcrv TRnt9KZU+P1QvuecsFK4Vxgu5AhpQrLgE9xCgqAXtaJaVIlKUS6KohDGL3eVOPljeD8qAbbsPyjy IhfGr0Ilewy/IlW+clhkRSIiUR+Ofg7Ci5E+jPd3q2kJCod4qcSH8SsHY1WvBJ0sLbFSg5rQMiSQ IoJFgkaiEH4yzKNVxtYSc4l2mKawouyfJQ1Sy6007Z//zNge2jJqQm2ow14XyqGFqL3uVnfzrcI/ zVsehKam0rS0UeOXHGydP2dmeZOnvMFT3gTQEHqitdkcWjHN5TowZz5tcIUYX8O06c00b2wKzfc0 lYXmeMpcB1ql+wY0z6TNrZ6yA2hm+d21B2YGm8q6WoOt5Z7GsrqD00oX1t/xrLX9z1pY+g+eVUoH W0ifNU26b8Cz6mnzNPqsevqsevqsacFp0rPo5MtnTyhd1ALS6SqfPcoVSp4Qqh43uTbkaqwrC+M9 UFn2IOJOIjV3HCVzK5CVzUROhKIfAlymeWRi9CvuLFJH5kX/whTBoh6hQCIlxegkehLtQJ2IR+1Q TkZT0TZ0Hs+BvT0FdaP3sQMFQPeyKIxGozdwNHoRzUQvQv8WdAptRgeQEu6ZhwzQuh57o0sBD0J5 GloZfR4loQL0ODqOCmHU9agnui96EFrHo4moA+2H+3+DPeQAq4u+Gr2CRDQOxlwJLRejo6OdSIvS USkaC7Ur0QnsZS5Hm5EZFQF1O9FzaDf6FfoTfhR3R5ujrdEL0S9AVM3IhibAtQx34y+YTvbx6M7o 19EIcCIZpcJTG9Am9AKM3wnXSVCt5fh+3II34c0kSB4l3ewqzhTpBT6koEq4qtADaA1w4Ag6jf6K /o6/IWZGzbQwZ6J50f+HFGgUzJLOpAm1wrUarvUwp2OYx1l4BB6Ll+Fn8Gb8DkklE0ktWUweIl8x Y5gpzBLmHXYR28Wt47bxisi30WPRs9H3kAnZ0b1oIVoOszuFLqBr6DpmYCwb9uIiXIqnwrUC7yBH 8G58hIzFJ/EF0oE/w7/H3+AbhCNKYiBppIVsIvvJKfImM5vZzDzLfMZ8yw7jCLeb+5L3Ch9FpkXW Rt6MFkW/iH4PKlZEbliZUjQG3YcaYbbz0SD0XzCLV+DqhFU7jc6g89L1e2xDPeh74ALCWmzFObgG rjH4LjwTz8Y/x0fhOiHR8h2BhSAyoiEmYiMTyDQyj6wg75EVTAKTyoxkJjOdcJ1j3mduMDdYjtWx BraSrUbr2Hnsdrj2sO1sF/sWV8gN48Zw93AruLXcOmY6d5F7n1/Or+e7+G/4P4NaHC08IKyD1TkP MvsrkOUffixOAupz0E/QdFyGp6EtsBq7cSNqA+magdcAv+aj5Gg9s5ypJFkgDSfQT0Fat6NlaC0z Be2OfsB0oEsgKXNhyBVoL1uK7NxWWJ1HURZIUd8VTElNSfb7vEmeRLcLVL4twWoxm4wGvU6rUccp FXKZKPAcyxCM0ss9FQ2ukK8hxPo8VVUZFPc0QkXjbRUNsJVdoYo7+4Rc9L5GaLqjZxB6zhzQMxjr GezvidWuYlScke4q97hCvy3zuMJ48rhaKD9Z5qlzhXqkco1Ufloqx0HZ7YYbXOXm5jJXCDe4ykMV rc1t5Q1lGen4SBDYIc9Ip4ojiBR04BAa0bgMFCwaQXuUh6yesvKQxQNlaGO85Y0zQmPH1ZaXJbjd dVAHVeNr4RkZ6bNDQCd6QjnDM+OJcBBNa6Clxim1IaaxLkQa6FiatJDJUxYyLf3S/AN6q1S+7rbG EPFWNDa1VYSCDU8AcynaQLHGdYCNmuCCYcmqutoQXtVHBKVxDlBKyY3ZBG/DHFdI5in1NLfNaQDm ovG1XdagVVK+ITS2tssStEhIRvoR8/IiN8z+SMbwjOE0L3Kbl8fyPzwWq3/7JM3Ny09/Dvmo8f0M wJQDnmqgM+SaLj3EA8QW0KSpALVNLwA+wa8OwzRnAz0jQgRkhvGGOG91Y2jFhFtkNJfFiGuYU9Yl s1glI1RaB/0b2tRDYKWgv9rjavsWrHWDp+dPd9Y09tXwXvW3iDbShe6XlRBuvFVupcbSC7NuNnua 6fq2SmsKuMdcflsF4JQ1lOaQHgz42Fp3yFUHFeBNpo8KI9nY2gMYr68L4+iqMCqzHwEflblvKjSn U1GbXQbPByQjHSpS3VAKpLsq4MkVVFZcba626hltrgpXMwgT65VyaGhqq8sEDk6oBT6hu+GJwbqE /mJTXd0QGCeTjgO3QPe2OhhhTt8IkEtVmb3QKSsdjCnjG1s7rja0oiwhFCyrg1UA8T05tjZ0EiS3 rg56ZfdTChQvm23uozkHaM5Ohfbc2Cjgu6yAIera2uiYE2o97tDJtraENrrfYngYo4EVwb6KMKJd KMvDeMVYuBcyjztBWgO3xw1k1VGeDgKRviVR4LP/aw7n99MNdw4GavMlDhf8mzhc+GM4PORHcbio n9I7OFwMNBdRDg/9z3F42B0cLvnXHA720w1EDgdqgxKHS/9NHB7xYzhc9qM4XN5P6R0crgCayymH K/9zHK66g8PV/5rDI/vpBiJHAbUjJQ6P/jdxuObHcHjMj+LwXf2U3sHhsUDzXZTD4/5zHB5/B4cn /GsO391PNxA5Eai9W+LwPf8mDk/6MRyu/VEcruun9A4OTwaa6yiH7+3ncDAhhG7XwysGqF30b1fM U25jOXhKnBaVkkKInVejnaQDrQcoY19GU6CuA8oTIe/k7kEOiMkmA7wE+Hl2EdrJd6CtgO+ENtre wP4euQHvgLbxAK0QoBdBXgBQBTAUn0UrAdZCeSUAbWuF8ddCP/p8E+QKuF8LuQHIunWepIQo5wTg LjSZhve3/QjEBdAZcdBDgAjhx/xk0EkOEdGtn1IqxCEViocSnCbATwPxnE4q/d9ED7QZIQIyQ5MF wCp1SYDUBn63A3InUOqGPBF5IE0CgLM6uGrRLvQ7bMRVEIc8TrTkeYZlbEwZc4H1sQ9zVVwrd4Jf w/9VaBE+Fztk42UrZM/LIvJW+VVFQKlSTlVei3teVQABSylC7AWInRmY84jYuZiYGUYsgKgOI3QB gOJQZj6GMuQC5Azkso/RUbgLoXvSjsJIHORZ2bkat8YPUMquD9/8HXf8+ogwW3MDzlmA2zuZBXi8 9CxfUEd+xiDOZLKiFMbCcr9yH6uCM48x12p6x5Q3lX2FSmp6srMw42HweHeLmzve201G0zHWR6aS Ru49pEfDgjK9RqYzwhiyY3gnrJge7wyqgmgFO1ptMRj/5p473hwWclZJw/ZYP7H2vNvTN3gJjE0E XqM2GXWeAPb7/L489eB8HZn6s8zKcTmblmysSCkwKuqLjnHvRd56+qPIF5FP//xM5Osry+c+0z7p Lpz8h03YK82pDOgxAT06lB9UihqkMwA97Oh4HSUJjiWBJJlo0Rv+5i75aWyCQMUnt9Gh0w7O16j9 PibXgU0ObFALPFP5XKCCUrF9uC8rZWrR0chUnL/+EnZj95+fwcbvFjUtu7Yg8sHVzZFPJRqmwBo+ wBpADgcHbcxSjrhExVK5PA4o4ZeyMhcjX4osypLx5rQx6ms114p7i6/dYrKEZGfp8twaWDmDW+PR TMHd+3F3ZPR+fKgdH45Ut0dG4kPSczoiF/AKdBmkOyNoRB6VfIYoV8NDhEHyGUi0xE9vij2huPfW /GpgstlZpvzB+XmDfH5PXq5Bzwsd5bZ4TOa939B6UTkxI1VQCJdfX9xNNyms70T8KRlFtoI8uoJy lMlgK4dAPsK49KD7qCQiV9RfoUwqHTqgdyL+LiInW+mZDobYF0n0MQjkC6cycipfeAa9f4abEjdQ vgbnGjydFy9ehoMiOJKm+40bCvJJpD19OTi2CtfiZsysYbay2+T75GFZWM4nyzESeB4TUSaDRI4E Dq/DDOvSy+VeLdTpOc6rhQ4KBcfI5CzPYQXBDCIOQQzjuqAMQmNeJmc4wNqD2ji6StzP8c/lFmXc bve6qUClZcw1c01vr0VapIoyMyoxFZcU1/TCwmkKS7BGW1gIf5rCzNWBtGXqUeDBsycTQuzputUB c18FAxXM6bq0vr6r1cXFAgCIfX09qscKrMvFHsbNeDCz/rOeVV8Qw+XNvceee4M8TSaTtb2LmenX R+BwpErixuToZW4B9yWiGulAsCiB24q3cIwTO9lH8WpurY6bIDKP2zUaAz/EziiHGGQO4nBYmGxS pM7WWF2ybIvF6drtnjOzbwOMUX9X03OtR1uYiUpKekpoQQ3rOWJJcAiymbw6n8qb4FMYZTkoTq/O wVpNvFqwAcYhJgdjwjJyszIHxWshEa18DmYxJPSsEKuL1cVpabGUVjxSj+tFbIIt7klEGrU2N2dw /uBcXuDdLr9PAzve7WEdeJDmlPtM14eRb//yzceLhjpOWTd2Ri5F0atfvnwUVyZzX0YuH1u/J/JW 5EwkEvnlvroNV392fMdv8cu4/MLvQG4IegnkZjpwKg70+Kygc7Vmi5bkiApHPEEOkyhm66zWOK/K YrG+725de0sKKQ9QSW9JrzRxHzZqvAYfL3ACKzACETherhZhtkZIZFpFDhb0cLIDU0xLS6Xz8tKZ 0H2lJh63hnG7TEaNXiApmFxoGt4yssga/+FfIs+dIxNw5t7NtTsij/d2dhj8D9Q9MaESa3DgxjZO d+lU5OLXxyNd0t45D3tnI8yBQSb6NuQobCeEAmlw9knVP8nMytblajznz5+nKh0aQbmxo6A/h7KD OkQY4mA5kbEKmHhhw/JwTj/hoLuVSvOYa1R0x8CulWQYVC+MBFt351ly9eY4GO6vnTDeVnhrY4Lx dOg3wboyPAo2CZYxRmxhLmFOh22MXpGgnIRrmXfxR8y7io+UclbOxpWTxwk7jmwlJEWeHFcgL4ir JJNIKxG8M+LkhNEymCiUWoYXJa1M1ciOYJzcySj4XiUmvXFOLdQc0iGLvnW+pLuA1CuWa4WF8Ge+ QqmOGSO6/7SmQjhqPxCnDOOOboKJXAGFLkKY1VxNYGkvu+z0ai6WZ2eh+oUL8ML6BTq3DFOdOig/ D3uwQW80aDxbsR3vwS9g63E2Un8mMpk7wR2/4WMvXx/BTM+4sPhGCnspI/+TQTd/JskW8JlLBb7I QCe1BvWDcQFPBGzCflyJawkH/CZ0UibQOCA1IkwYXojIGbkc8yKsCrT9gmOtSqp7dgTlMmRRKHe5 6WT71+U7ujxUT0jbkU60sJAFzbJ62Rk6EVwPqgKMgwfD384/kq+Of9Ybf4IMAaIns3uuj2BfunEv 0Ef3Aehf9nsoy8E6NwbzZitna5col2rZKn2tvlm/VM8KokOjVsuxKt4BL1jkIuG1Slam12ezVmO8 zIvAaoex4qB7861dAgvwXU2vBlgPmgLUnxpUBWS4PjurXufOgVNHHqTfg/w+yNw5+XmdZPPpP7// aSTnLLPiodJFkRa87vG93PFPzr0c7d3EHhnijDALn6a0NkTfY78DnZYJZ5uR4NSUeL/H58tX5bkr fdN8S1WLk2T3i2aVyUvqVM2qjkRGrhqSmJQoZ1ib+XF9ZmaabYieYYekybKIXCVqkhKdyVlZGrPX VC16k605Tq+mGnkzLdk5u9xz+iYDGu8HxafVgA4HuE0B0lkGenPrF0gKoSY5oHEikfiIL8PLe60+ Jh2loYyAlHGpYhq265xpKMFgTsMWM85g05DMr0jDXgUOQFlIgcShtUGjERLY0aAW1ZKGlIqgJenv kUcegRU2moxUMeYN8vsyMXWFBiXl5rAGDxQ9ibxBbzI6aR+DnvWA2hyMsUMYNP36/Cldo0Y/f/bX 49Zh7Y0/4BHH4rPvvRzaPrnowpubx62L/OyPkf/dsYMhNfjysjEbXcN2PZSb481Iz5ty+LXIZ9+2 lix6ZtrcHFdWZmLRrNPX3l73xP+y4EZj6uuyoGPArxwUtGLegQTCijKwkegGYbwce4O3iNRIDvRk JN0C5k1yYdx57PmI5vWIhjveef2vnAoEk655R/RDLhPGpj53cdBj4vxcgZqRI8INUcuMjNGol3mV VjP26i0m8y735tguqYkt2y1rVQyyhzXAE4llsDHUAnG7GJ8F3LOW4rp3eu/Nfr368ci6yLpV1WQE d/xmy645u16Z+hyz7ubZyF82Rr7D8o04nikETTs++rH0BiAe3u0Uo0+CBalZWK4GPWfz51apZ8vm qIVCUauUMQk5QpLMrlbai9JIIKXocBEpykn1atUCJ9r8iSZbGLfBdOxOwW8PKIg9T1EsFBfb9EJK anuSdVhCim1kvL/AMnTYf+OtwOAjeAvqs8QxkbzSe/rW7MAagzmmolgPKiHQE+ih7obGVCgJZXL+ YEMiwhYvzo93I7MjwY2MLj24pYloMHEjq93khgWAhMobGOMfRKw+SeLXUKzC8RjsrwHHfEJPosAL nmE4NwfkS6OHTvAIFVhrcMlpBrKYP1iHVQvH3Fe3xd2cM29a9gTcPcygfGzpk0VueTv3txeOtz5o 8iodmtR0X32qUTb4zYc3Hz+6te2tyenVezYYbLwqzpY5C88V080ZUyaMTp3w2o6qqm29W22JDLNK yZd6glVzfrFm84s6fIXKSGv0U9bLnYKozYHmBwN7hL22SzYmUYx3EA4hk50TNHKHXaHQ+0WryxpQ B3AK0oB7s9p9vP6WUr1yRdroCHwb+NOApyZxz6w18nIjr/dhrRwSg2DyYZ3M4YtZdboTwTBSVmg1 eiJxwOBJoo5z3ybMbe0serHh3N+/u7z07pzCPWTmhg1P/vSIr/IUd6r3jzXjIj2Ra5FIqMhTs3bZ 1RP7Pj10cevUA5Lcw1sviAvHQHSZgPYGM/da8DZzu9hhZkaKmh16htHzdqsQZwcLKyQkmNR+LWb8 RGO1y/0miw0+BRAOuhcu65MYmFlxTU9h4T/y3gYhi+hVGuQ+pNKpYZbUb7MABn6bW/LbFMY4H/ht kMjMvI/6be5/4LdRlVSPjDGvDUQlJhW5VBxInhrlCuT935s61QuXvzwya83G+Y9ZOh1/Pvb2dax9 18aOCV2a/lj7vF27P167+L0zOPcreGU3hIN1LYheZnpgXRXIjhYHcwarKlWTVHvZfQmcV9STeLsa iXa7oJMTu0nBBXQBdYpGa3Uq/FaLw7navbD09un3XrkycG2tZptMjjA2K2BuNkiQhfiQPEH0wQTh T1K0WirefeuJTEYTtap5dFoob5A297uNu5ft3rN0zT7cNiFr6CvPl7z8wMHI9W8+xfddvXT+N7++ 8DoZPMgxitivD9s8vRZnXP8aTwIdUhW9zFrhLaINzga8WBlcslV81rrXyXAqEs/pDSptvEEfVAb1 YooVj1IcYs7i15izCR+IH8red37guWq66lGc1ZzVkiki506K3260JxXygmB0222C3G5UeIWttr22 w7AHWK8x3mvjLHKloFH54+1+zupPCgh+i8Xnf9e9Jyb84D1Jov9urxShSIFKZn2/kaMWvAf0ibQd KpCH5Rh4RYs5lneCN65V69R6NcsrvYkJST4497D7sMMuMwk+pDCofDhO5bG6oYqDRDSDXMWpIZFM m6RrJH2Tmpb6CF5QjxZAnAM2C7SK2wFbirr9Kgy6hpcCAZRL7RzsK/Cfut8vyNeqb37DPb31ybuz 9AeEu7LHLxk+/lzka2z+HXYqkke+8nA7hz1s5f0Tx80d+fwLZ+rzK4s2BMba1ODTQSCISyO+Byse PdiGP6Z2hkFDI0XMVVgTJ8qALwgOB2vy9dVitaxWrJOtUe5LaLfv8+9JO5KgCIqMMTFFdVqeCKqb 5VPsFrnWLo8PCIEAZ2MCxkBGCmfNUqr8ccN8fpslM+s2QbzWU0g53XvlW+BnXxwF2kZib4y/6Z5k q0OhSfKqfR6Hz4eSrZBoFCo3ilcp47z2RB/2J6TAflRqwejGFHZMZceklUpoXi4EFbw70efP7XMS JK2cpIFtiIB/fbsTfAdMHp6am7eneH7k/Ct/Uh2O8w997K2gj8nftuzVyA0sHMVlL/7XiQrvpodP 3ZUeuciWDvOMWH0z543WyzteqvIXb7znk/Fj/waOcRwORHaf7Lpv+y+Od05fSTIk/bUSHIMisNv0 jCo/aBO+ZMFR4Bk5dQuA/ykCA4pH1uGeFtulxTWne4tP3zrpKZZOkmjwooFof+Vh+LGpN97njr8B Y2O0FhIa8zMoJQhHEH1nBiQF0VOp24aEWCAWCsTiF8/a7m4pEqI2A+hjemC9LaBhpwazD/NnecLy et6vb+VbBE6vJHqzGiwH4s0KuVWwWpEyRWa14YA5xYIsCWC++YM/EN+3hWKrWgxrCm4ipnsm5osb bhlLiCqoCINMqzCEFXjl/tEdzVfGph+2Zy0PpowsyEjoxnvZzG1Txz836fneceSFacUz4oyleQtm 974FxMKMi6Ifsm6wC0qIWy3o6WDuNnGL+lnjS2y7uEe9zxgWz4mX2C9V/6NXDhF5u1lQ2rUKi2Cx GIg/3pog8xss1oQwloF16Nv9d3pKsZA+HY5ifQqdDHaqhviwYIISFwcluV7pQ1gNiWgEY8CoIKEO g5SkgRFI0lKPVDJ+xlwthO8E/IyYAfh8Vdbooy9t2fICfKRzM/K3TyI3sfYPfAuO37Nl6jM3u/Zf YS5H/gTmsDfyKk67CU5HkNqA1shE1gtTV8FpakswfZ+410SSRZdNo+LtBiGeV9ltikQV8ZutSXKw 7O6UxHiLJ+kfWnbJtGtAyUmqzGZMQJzVx/pQAkyMM0KCLSofYkzSnKQZUftOrXlszahTnYtzDeAF UXsPh36Swdd4yGt7vRVHj5V7IY0EOvOD9/70UORwy/Yl47OKupe88/aKKQeOzdj+8KQ9zIH11cnF kf+BOT6/5b48R3XvJ33yTDayleC/3BX0+Rlf3GCmkmVVopqoZBqZ0i9SMdTIRasOUxuHLFpdGJeD +C3v916kUL2kpuR072nQLYXUAaTCp8uVRM9oMgTAZPEgcmv3G168nzPb1QnqNRu72cwj+TsIc4Ih nQt7t9F9URq9xBxiR4EOzMSB4FMFsm3cFu2z+m2Gbal8cpLXn++ucFcmVfrvSZrkn5k0y7dEuSRu iarV05LU4m3x7XG0p+sYUP1cBhvQIashwWQzGzL0geR4xWzR5833Em9inJxN05lfs9l1AmsPbE9T ZAoylZoIKNOdaXWajWa/aViyT/AnW7NVTr96GPIHLFnZXf32qudab0yPFqqhRKdbmAlpX2RGvWHq C8dCstE4g/gMEIq5VU43ksHniRiiMTfE51Cya6EuQW92Y1d8ohu5E1Vxol/uxj6vTA7RmRu+SYXE obG5aUQW85BjB1XSaVVM6CV/GdXTmFtSt7eHZCAnJqPwf2MyEByfH38jesvaZ2wb6l/01NrhLR8d +ev9I0gH5xv27MzZ5cljFp8qnf3hp9+cFfBhPHZy1qRJ95YngaVPTK1+ZNt/r5/cPDSnckywItWi s2emlz/z1IUPd5G/g240Rb8hMm4yaIfxv4gLyE+qcBiXBL2ssdDE8Cq5xgr6F77USkEGlSGecTKE uWmEU66b7ll93mJvfeFpGq+rY7ozE2J4OGvoUfdekQ6BQB/HAqk+n9+XB/5Qbvuh/ft9huw4h945 wr988oYN3OTIe5t6ywt0CkzWy8RHZpEzmyTdDQEj8zWbicAGBAOl+AwmaBZqJs3MLH41u4bbi9qJ CF+zkXJ2JPc4u5Y7y57jxOrkRcn0NATU1iwq83CmE47O7wYnxMWG8WOHGWaeFk534KjosaCD5+dp YVdxPMtgzBGGZxB82yQX6cQ7yVFMLdPKg7iTt8TObD//vO/UFs5si+HUVivtHm2hUBNIU4+5UiPE srRR45YEvSRFyzAsSoGjG/CB7hgczjg7OfTDuIWFvYWFsfPg/pE5QZ0GfxCNgrsDR00yDEe6+GPs wGlnInNPRh5kM29uY5pvXAQOYXgHhbjdUFJiV3B5JdshA1biCqFasZppE1fJXyenmdeE8+Jr8vMK xUxhjtgkn61oFZaIrfIlilVCm0JO+5JKZjF6iGMmJRuTQU+zRbiIfQo/xfIyFjMKwnC8Et6eiXIF I8hVwCM4xdwhMuxpOZGdViC8Q2mJozy3QPAOB9zSpGJp/9TgoA24BtEn5ZCSA94I8FWiVqlUcKvV afAHy9Utg2/M5GH8RFCnhbBC4FmOduQFmSiTw8o+EVRpWZZRKGHa0q14NbB/tXrZaTNHT8jFZeoz UmH1MvXp/hp6NL5gwQJwHBNIbgLlpQLYeenNi6+//VF35Pyxy+8ci/wGWNrNjL55hKm8cZEZevPX wFDQc4ZIteTvUSv6evAnbYY15r1mRuBNfIG2SlurnSUsZhYL6/Tb4A3nNsNW41ZTO2o3qqvQKEOl 6byBLeNe48hqbg/ag/dy7SYuKZkzG0xG8HEMSkW8XVRRo2tMAIZSmTAZzJ3Kp4xge9+NSTCIXs0V 8x2MjDkPwOIcS6a5pLiYnulhYF1Qa4DDD+M8rclk5jCmwm2Goz7KGpqJkAMXsrMWQABWj3N5hghE UjB51InOHzwMDwbOMIz7rO+xaaU7V+z0pTgyU9U5mWpumCrS8gZ2YjZzVmRD5E+vRmZ28+KLcbzb LD6TxI4BUXyU8kr6RZvg29F/9PNCJSO9fVFK71DVYMeSkA/54YtYelKXDW5nPhoM39aWoXJUIX2r OhK+Rr0LvpUdD9+/TkT3oEmoDt7twjsxSeqx9BievosdUVk3vLYirappbmtTy+zpjVIPqRkSOGeF r4ARPe9G5wA+ALgK8D0MA++CsRkgGaAAoAqgFqAZ4CGANQDbANoBwgDnAD4AuArwPUxaBDADJAMU AFQB1AI0AzwEsAZgG0A7QBjgHMAH0b4f0ID6yxi5BuD+AXjyADxlAJ42AE8fgFOP+/bnBQbgwwfg IwbgZQNwcDTvGG/0ALxmAD5mAD52AD5hAH73AHziAJyu8u3zmTYAnz4AnzEAl+T0Nv7PGtA+ewA+ dwD+kwH4AwPw+QPwhQPwRQNw6X9qbqOndUD74gH4Eor/f03Ju4wKZW5kc3RyZWFtCmVuZG9iagox OCAwIG9iago4ODkwCmVuZG9iagoxMCAwIG9iago8PCAvVHlwZSAvRm9udCAvU3VidHlwZSAvVHJ1 ZVR5cGUgL0Jhc2VGb250IC9QVVdXQUYrSGVsdmV0aWNhLUJvbGQgL0ZvbnREZXNjcmlwdG9yCjE5 IDAgUiAvRW5jb2RpbmcgL01hY1JvbWFuRW5jb2RpbmcgL0ZpcnN0Q2hhciA3NyAvTGFzdENoYXIg NzcgL1dpZHRocyBbIDgzMwpdID4+CmVuZG9iagoxOSAwIG9iago8PCAvVHlwZSAvRm9udERlc2Ny aXB0b3IgL0ZvbnROYW1lIC9QVVdXQUYrSGVsdmV0aWNhLUJvbGQgL0ZsYWdzIDMyIC9Gb250QkJv eApbLTEwMTggLTQ4MSAxNDM2IDExNTldIC9JdGFsaWNBbmdsZSAwIC9Bc2NlbnQgNzcwIC9EZXNj ZW50IC0yMzAgL0NhcEhlaWdodAo3MjAgL1N0ZW1WIDE0OSAvWEhlaWdodCA1MzIgL1N0ZW1IIDEy NCAvQXZnV2lkdGggNDc5IC9NYXhXaWR0aCAxNTAwIC9Gb250RmlsZTIKMjAgMCBSID4+CmVuZG9i agoyMCAwIG9iago8PCAvTGVuZ3RoIDIxIDAgUiAvTGVuZ3RoMSA1NzM2IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+CnN0cmVhbQp4AcVYDXBTVRY+9/3kvbRAm1BK+hNfwkv6l4TyXwqlTUtSioVaWgoJ P5q0DRa2herWrpUFKz+rBNfBcQW2uososzo4uK8BIYXR6SA7uCozKsPqKoo4iwtil12HHxXo23Nf SqSMw3RmGffe3nfOPefce7733dv7Xl7bgw+FYDh0AgvVi4Kty0ArqUUonA0twdZYP2U+yvSG9jZL rM87AdgnlrXe3xLri/sAErfd39wxMD7lYQDS1hQKNsb8cA3llCY0xPpkEkpbU0sbxtGSMgcvYvOq hgF/Cs2rawk+PJAfTmLfsjLYEkKJJTUFLzmtq37ZpnVh1Dda/8HQQDzxIb7jQNDKwCOgh2YQUUvG igiFs4nbgEMv9WNLmp75zn1JRZfAIGrTvZg9tpMqx3oOHrhy8lp24lp9OcbptXjqwDG63P5cgGEE /Z8mro17qJcWJgpLHFGowVaBrRjbJGx5jm7RfZBsgZSlF916InGQKH2c9q83yVhcg6+0q0LGuocN B33D+iKpYf36itxSPamEAo6ARLxg06QnYntVipLiiE1GMSMmmEiBGXvg1hfYpOsF9dK1gqhI3BnS d7ZnpCvYLttKpEu28dIHGPd+wSzpWCn6I9K7eVEGxTu2KEfcSdLbtsek1wtypX0F06VINtoiUncp iv3SroLHpJc2aJYX8zSx0xYlXRHpBSr2Sztw/q3rNcezsYHrYqJ1g5Zo1V5NrNwbZV7dL7XYsqR6 HEjcidJSW7O0xFYozS+NEntEmkuH7ZfmZB+TKmnqiOSOJZoSm32yTUM8IZbWaTsk5cQyjKHR7pGS xTZHMuP8zhe2Sk7bvVJpXpS8cqAiJ89Wkb11SpRc1HJQgUCpWBkTDdlvkJdhFuSSRWAnv99bkYuY yZaItB5F196KnAJ7lD3rNkp7syuyN2Cbgs2OrS5K5rudwjahUagTJgoOIVfIEqzCXUKGkCIaxWRx hDhMTBBFUSdyIiOCmBJVv3A76E5K0SVToePoldP0ZIbqeMErMERk4G6I6mBjanuJqcRYbCgs9/zE JaAZAx7Hj8X0o+owEbOytbLWp+w2+5UJVFHN/pv8/4saKsPRlTUde2s6zi/whmRvQPaGsAWUze1N JqWz3mLpPt9BHRaFzQrUNzRRGQwpHXLIo5yXPZbuGm3cLe4F1F0je7phgXe+r3uBO+SJ1LhrvHLQ 499b7a2oGpRrUzxXhfcncnnpZBU0V7U27pZcVdRdTXNV0VxVNFe1u1rL5XB4l9eWAd8LBv4wuPht YObKwAygfoLtUyr7a9UL/PuQoF5X+1g83cgY2k5dJSnwZxDgAKzFE+dD2E30IEMfmQB/J2aSBx9D P3wKX0I6bIYX8OqFs+QynjTnSA7GTIF18EfYobZCK5RgPUt4GAVT4Zy6Wn1b/R7KIAxHiEBGErPa A/nwONYueJ4MY+rVbjDBHPgVnuzr4K/wiRpRv8b5p8AZYiD53HT1M9xgPFoKYRPshgPESmSSRxar Z9BuQoxLYLc6V23HcRcwKh+qYDVmO00kkkUcpIt8zvapnepTeG+Z6KuDBqwt8Bhsh+dhjxZVz2Xy o3B+D1Si7yl4D87Ct3jo5pIy8jBzgv2a/Tc3netSjyCOOswXgB2ERVZspI40klayh+wjb5HLTAET ZAvZE1wrtxOx1cETsBPegKNwHD6D89AHP8B1wiGmYnIPWU3+gOO+ZCYyS5k1zJPMJ8wFdjz7OSdw m/mN/CGVU0+oPyDmuyAPpuN/+jzwQQjrMlgJD8GjsIEIsA264S1EewpOkQSSTPLJeDKLzCeLyS9I BzxNdpGD5CT5B/mKnEN0IxmJkZl8ph3zrWM2MXuYCNPD9LEGto1dw/ayn7OXuVHcUq4X6ynexbfp MnWVwrz+3/WfUl3qFrUL1yUVqw1ywQXFhEMWW2ADruQm5Ox52AWvwmsQgYh6lRTCEfgAcZ2GC3AF VywTq5VMIFNJNZmHCJtJC3mUbEeEu8l+RHmIHIKPyEfkKtZ+SGP0jItZzASZDqxdsJ05rvEzjLWy OayLrWRr1f+we9hu9lvOzi3iHuBWc2FuO7eDz+Rn8Av5RXwr/yy/n3+X/xt/gb+oM+se1+3S7dMd F0RhkrBd6CdjEIuF2GEfvIm7bivbin0bzCQbcFUXwHu4e/vgL3AVvodeeJmYoZ+lq5ml7oSo+gSu 5hvwOvtrKIKnmWeYu9US9hVWTyaoV3Cucbhe8erOy83JzrLb5DFWi3SXOTMjPc00OnVUykijITlp xPBhiQl6UdDxHMsQcHrl8oBFyQooXJZcUeGifTmIhuBNhoBiQVP54BjFQscF0TUo0o2Ry26JdMci 3fFIkmwpgiKX0+KVLcoxj2yJkkXzfKj/1iP7LUqfps/V9C2aPhx1qxUHWLymJo9FIQGLVylvbwp7 Ax6Xk/S48WGQ4HJCD4AbEunECswMrsHDFWbSCK+SLnu8SpqMOvpYuzfYqFTP83k9GVar3+VUyMwG uV4BuUxJcgwMp+PwELTX+DC3y7lcQfyweVij3Lg56ob6ANWCS3wKG/QrTIDmMDiU0bJHGf3IGdOP 3Rua98mbnApjLw+GwuWKO7AZSafdAO0Fn8ReZa0Fp2U2+n0K2YjgKAgNe+wuYo8Je2CFRdHLZXJT eEUAOYdqXyTdne6VAx6/AjW+SJo7Teu4nD2mtdOtSEqPq9RVSuV0q2ltTP5zfcz+YS+VprVHvkBZ WRPnhdDc8myEqVgaMAlygVin0ktoKoQbpiJ9WPwE73I54pmpMLiVWLvC22cHlc7aARjBJs8AuBWe iD4tXXsulfkxPhBOnoYLiPHJsiV8CXBl5b5vBluCAxadPfkSUCdd//gWUkjwht5On592fCQ1meQm unzt2lJjXzZ5bzJgnz63XPjC6ayMgr7a103IU/4oUTdGwWPuwQcMe9+96HbQDbfcg+mw43SiIc+K GiIox0TldGdYwpbw7MawpdzShFuKs2sSHaGwPx8Jq/UhLTDfZ1Xc/oy4GvL7p+E8Y+k8OATDw36c YcXADCg1U/51DMp3VuJdZVX75vmUTk+G4vb4kXTcxL3VPqUX96/fj1Hj4kgR8ZrlpgHM4xHzuDz0 T4jNgq81nTiFPxymc9b6ZKvSGw5nhOl/XayPb8i3GtwDhijQEMpwlHRW41gUsjVDo9wqWxGWn3I6 ETfwjQ2Er/W3Z3hyHDeOnIJoJ2sMF9whhqcOheHCITE8LY50EMPTEfM0ynDRz8fwjEEMF9+e4ZI4 bgTpRrQlGsOld4jhsqEwPHNIDHviSAcx7EXMHspw+c/H8KxBDFfcnuHZcdwI8m5EO1tjuPIOMTxn KAzPHRLDVXGkgxi+BzFXUYarfz6G5w1iuOb2DNfGcSPI+Yi2VmO47g4xvGAoDC8cEsO+ONJBDPsR s48yvCjOsDtDgZvP4c5bjl244wfz4kGUL7k95UvjN4Ko70X4SzXK77tDlAeGQnlwSJTXx5EOorwB MddTyhv/j5SHbqIc+KPQpduNv58AP1zQb2v4gQx02ADmxi0Ak+AgWhj8pQr4u+IwfnkUoNht5XVm fF/nBDMLCTxnZlkmXa8TzATSRP1ua3MRfsyoulg093pRVfLlornJ14ugpOh6EW3jx000WA3Z2Lq4 l6LXjvGHfyiOcjVXX6MICMWjy8E8Ruh1b9GDIIp63pAqpulzIVt06G2GPGOBMFks0k81roCQoQMe MmyC3xi6YKvhFfiT4ShcEb/TZ/Jigj5VNOk5wZgupCeMNo4B2ZBvnCGUJJQYHzH26PcbjxpHJAlJ CUxCktGgF4EfITCsMUFgRxiAGSGyYsro0ekMx2YzxqThI7KT0kbWdJgcVckX8Z7Skk+eNF0vSsYv E56v8MbwvoyjC4nBWIjCUDh+HDywlOCfFW9y0pTJ+KsvJXUU6lbCtZBD/aeZ/nP9J/rPM/2nSS8Z Rglgzziey7vq4E7kPee4lsEfvtpBOdeKSn/x/lSh/nGagyBbsRXU4RcHqK5buLC03FERam4PtS1v CLrKVjU3Um5vFPxuBZnqQKHGuE5w7bH8F7MDIV0KZW5kc3RyZWFtCmVuZG9iagoyMSAwIG9iagoz MDMzCmVuZG9iagoyMiAwIG9iagooTWFjIE9TIFggMTAuOS4yIFF1YXJ0eiBQREZDb250ZXh0KQpl bmRvYmoKMjMgMCBvYmoKKEQ6MjAxNDA1MTIxODUyNTdaMDAnMDAnKQplbmRvYmoKMSAwIG9iago8 PCAvUHJvZHVjZXIgMjIgMCBSIC9DcmVhdGlvbkRhdGUgMjMgMCBSIC9Nb2REYXRlIDIzIDAgUiA+ PgplbmRvYmoKeHJlZgowIDI0CjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDAxNzY2MSAwMDAwMCBu IAowMDAwMDAxNDk2IDAwMDAwIG4gCjAwMDAwMDQxNzYgMDAwMDAgbiAKMDAwMDAwMDAyMiAwMDAw MCBuIAowMDAwMDAxNDc2IDAwMDAwIG4gCjAwMDAwMDE2MDAgMDAwMDAgbiAKMDAwMDAwMjkzMyAw MDAwMCBuIAowMDAwMDA0MTQwIDAwMDAwIG4gCjAwMDAwMDQzMDkgMDAwMDAgbiAKMDAwMDAxMzk4 NSAwMDAwMCBuIAowMDAwMDAxNzIwIDAwMDAwIG4gCjAwMDAwMDI5MTIgMDAwMDAgbiAKMDAwMDAw Mjk2OSAwMDAwMCBuIAowMDAwMDA0MTE5IDAwMDAwIG4gCjAwMDAwMDQyNTkgMDAwMDAgbiAKMDAw MDAwNDczMiAwMDAwMCBuIAowMDAwMDA0OTgzIDAwMDAwIG4gCjAwMDAwMTM5NjQgMDAwMDAgbiAK MDAwMDAxNDE2NSAwMDAwMCBuIAowMDAwMDE0NDIzIDAwMDAwIG4gCjAwMDAwMTc1NDYgMDAwMDAg biAKMDAwMDAxNzU2NyAwMDAwMCBuIAowMDAwMDE3NjE5IDAwMDAwIG4gCnRyYWlsZXIKPDwgL1Np emUgMjQgL1Jvb3QgMTUgMCBSIC9JbmZvIDEgMCBSIC9JRCBbIDw5NmI4MDFhNzRhYWJmNjY1NDJm MTk5NjI3NzA4YzFjMj4KPDk2YjgwMWE3NGFhYmY2NjU0MmYxOTk2Mjc3MDhjMWMyPiBdID4+CnN0 YXJ0eHJlZgoxNzczNgolJUVPRgoxIDAgb2JqCjw8L0F1dGhvciAoRGF2aWQgUm9zKS9DcmVhdGlv bkRhdGUgKEQ6MjAxNDA0MTYxNjI0MDBaKS9DcmVhdG9yIChPbW5pR3JhZmZsZSBQcm9mZXNzaW9u YWwgNC4yLjIpL01vZERhdGUgKEQ6MjAxNDA1MTIxODUyMDBaKS9Qcm9kdWNlciAyMiAwIFIgL1Rp dGxlIChub24tTkVBVC1hcHAtc3VwcG9ydC5ncmFmZmxlKT4+CmVuZG9iagp4cmVmCjEgMQowMDAw MDE4Mzc0IDAwMDAwIG4gCnRyYWlsZXIKPDwvSUQgWzw5NmI4MDFhNzRhYWJmNjY1NDJmMTk5NjI3 NzA4YzFjMj4gPDk2YjgwMWE3NGFhYmY2NjU0MmYxOTk2Mjc3MDhjMWMyPl0gL0luZm8gMSAwIFIg L1ByZXYgMTc3MzYgL1Jvb3QgMTUgMCBSIC9TaXplIDI0Pj4Kc3RhcnR4cmVmCjE4NTY5CiUlRU9G Cg== --Apple-Mail=_7B7F19D1-5FD2-4EE8-8D39-3E3A46EBC4F0-- From nobody Tue May 20 07:01: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 394791A06E3 for ; Tue, 20 May 2014 07:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nrdfsk76rjzl for ; Tue, 20 May 2014 07:01:49 -0700 (PDT) Received: from mail-qc0-f200.google.com (mail-qc0-f200.google.com [209.85.216.200]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A41291A0357 for ; Tue, 20 May 2014 07:01:49 -0700 (PDT) Received: by mail-qc0-f200.google.com with SMTP id x3so1402312qcv.7 for ; Tue, 20 May 2014 07:01:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bpPir7BiqmHN/eIet+QkN1T78KHoQiT4RUbTQsmpqXM=; b=Fnmm4+haUA/xWOtUdRAbPvmf31ncFX0Sa5KM8o+rSwWFGgr5Xe+Yxtv1dlOmwjzj9G GVdun6IYMQEqszyCv6g7TyXUzhtYd/2w0V+IWAtAFx07VmyAJlNCmvOuih01ZArrMya4 onC6XaWnrDtw+aubnVd5cOB+pES4i/dvPj92wBp87xNefNUZZVRcCJATwfqvH2PytO9E GmVuzEJvson2+ToO+YH0pkEP8tp522CRgwKXMS4wK3jwa7wgnKrBTxureHt8wuUawVNL sDgSLbi3Ms7Pa/Rn2dk4bonLTpfllrbnaZKK+besKd5Roe1wR2IPwCTl/YwEgQBxCq8u DHKw== X-Gm-Message-State: ALoCoQk1sHzKIj6op+ACoVTSvqd9gxtB5j2LKGYZ04F+0ltpg5EHnNGvz3Rmoy5N63Bi9Z/4pMhp X-Received: by 10.52.2.229 with SMTP id 5mr3325073vdx.24.1400594507362; Tue, 20 May 2014 07:01:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.84.35 with HTTP; Tue, 20 May 2014 07:01:26 -0700 (PDT) In-Reply-To: <3760DEA3-68BD-48CC-BB12-281F77F7E6F3@ifi.uio.no> References: <3760DEA3-68BD-48CC-BB12-281F77F7E6F3@ifi.uio.no> From: Aaron Falk Date: Tue, 20 May 2014 10:01:26 -0400 Message-ID: To: Michael Welzl Content-Type: multipart/alternative; boundary=20cf302d4ae0160a2d04f9d552ea Archived-At: http://mailarchive.ietf.org/arch/msg/taps/FYqN1ycGABtW5ihJ4_zzH-4Qhsc Cc: taps@ietf.org Subject: Re: [Taps] First draft of an article for the IETF journal 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, 20 May 2014 14:01:55 -0000 --20cf302d4ae0160a2d04f9d552ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Michael- This is a nice writeup and, while I wasn't at the BoF, it seems consistent with the minutes, drafts and presentations I've seen. I have a few comments: I think it would be more accessible to non-Transport folks if the first paragraph included a couple of descriptions of the capabilities of protocols other than TCP or UDP to give some motivation of why anyone would want to see TAPS succeed. The list of acronyms at the beginning of the article may be a turn-off to anyone who doesn't recognize them. I realize you have space constraints but consider most folks reading this will be non-experts - think managers. (The experts will read the minutes.) Second, the paragraph on debate is one of the most important since it highlights some of the open issues that may affect the success of the work. I'd suggest restructuring it to minimize the names of the individuals and expand on the core concerns: predictability, safety, binding mechanisms, layer vs. API. Maybe a bulleted list? Third, and this is sort of beyond the article although you did invoke the topic, I've been thinking about deployment for TAPS. It seems important to have a believable deployment story since it has been deployment issues that have hampered use off some of the transport protocols that TAPS intends to make more available. Seems to me like the deployment challenge may actually be harder if you are creating a new layer / api since you need both ends of the app to support it as well as both stacks. Has there been any discussion of this? Maybe I'm missing something obvious. If so, it's worth stating as part of the concept and if not it's worth listing as an open issue. Hope this is helpful, --aaron On Tue, May 20, 2014 at 3:52 AM, Michael Welzl wrote: > Dear all, > > I was invited to write an article about the TAPS BOF for the IETF journal= , > with deadline end of May ("exact due date TBD"). This is the information > they gave me: > > *** > For BoFs, most articles end up being an overview of the BoF, its goals, > and any next steps and/or ongoing work. Pictures and figures are welcome, > too, as separate high-resolution files. > > Articles can be anywhere from 500-1500 words, but we are pretty flexible > if you have more or less to say. > > We publish articles online to > http://www.internetsociety.org/publications/ietf-journal and our Twitter > account ( http://twitter.com/ietfjournal) as they are finalized, and then > package everything into a print version just in time for the next IETF. > *** > > > I produced the text below, with two figures attached to this email. Pleas= e > let me have any comments / suggestions by the end of this week latest, > thanks! > > > Cheers, > Michael > > ******************************************************** > > TAPS BOF > > SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion control mechanism > offer a large number of services to applications in addition to the > long-standing two services provided by TCP and UDP. For an application > programmer, using protocols other than TCP or UDP is hard: not all > protocols are available everywhere, hence a fall-back solution must be > implemented. Some protocols provide the same services in different ways. > Layering decisions must be made (e.g. should a protocol be used natively = or > over UDP?). Because of these complications, programmers often resort to > either using TCP or implementing their own customized solution over UDP, > and chances of benefiting from other transport protocols are lost. The > intention of the Transport Services (TAPS) initiative is to identify the > services provided by IETF transport protocols and congestion control > mechanisms as well as network requirements of applications and the APIs > they use to communicate. By finding a mapping between these lists, a > potential later WG could define services that a transport API should offe= r. > Then, it would specify how these transport services can be implemented > using native IETF transports and encapsulated transports, including the > definition of mechanisms to validate that a transport (or transports) can > be supported on a path. > > The TAPS initiative began in August 2013 with a mailing list and an > accompanying web page. We held a "Bar BOF" at IETF-88 in Vancouver, where > it was already clarified that TAPS should be careful to provide what > application programmers really need instead of being too focused on the > Berkeley Sockets API. Accordingly, several Internet-drafts were written, > including use cases and an overview of how higher level APIs could better > be supported by enhanced IETF transport services. By breaking the > dependency of applications on specific protocols, TAPS has the potential = to > make the currently rigid transport layer more flexible; this is > schematically shown in Figure 1. In December 2013, a presentation was giv= en > at the IAB Workshop on Internet Technology Adoption and Transition in > Cambridge, UK, explaining how the evolutionary benefit of TAPS is connect= ed > to its best-effort nature. These activities culminated in a > Birds-of-a-Feather (BoF) meeting at IETF-89. This BoF was designated > "non-WG-forming" to allow the IETF community to discuss the various angle= s > of this large problem space without having to spend time on charter > word-smithing. Discussion was indeed lively at this two-hour long session= , > with 129 attendees and a debate in which more than 6650 words were spoken > at the microphone. > > There were four presentations at the TAPS BoF: Jon Crowcroft outlined the > potential of this activity, calling it "socket science" and putting it in > relation to security. Then, Martin Sustrik presented how middleware such = as > his own ZeroMQ could benefit from transports other than TCP; notably, the > strict reliability of TCP is a poor match for pub/sub communication. As > shown in Figure 2, updating middleware offers an easy deployment path, > where applications could exploit some of the benefits of TAPS without > having to be changed (except for re-compiling with a new version of the > middleware). Gorry Fairhurst presented a possible implementation of TAPS, > and Margaret Wasserman presented the API of the Multiple Interfaces (MIF) > Working Group. This API is clearly related, and it seems obvious that a > TAPS API should be somehow connected to the MIF API. > > All presentations were accompanied by active debate. For example, not > everyone agreed with the particular way of providing transport services > that was presented. The flexibility shown in Figure 1 comes at a cost -- > application programmers may need a very predictable behavior, where a > certain way of using an API always leads to the exact same protocol choic= e > underneath. This point was made by Stuart Cheshire from Apple, who > suggested to make such decisions at development time, not at runtime; > Marie-Jos=C3=A9 Montpetit from MIT stressed the importance of testing. Ch= anging > the transport protocol must not break an application. Ran Atkinson and Da= ve > Thaler suggested to support name-based instead of IP-address-based > transports, at least as an option. Several participants stated that TAPS > should not be focusing on an API -- for example, Pete Resnick said that > TAPS should be thought about in terms of a layer, and we should leave it = to > OSes that interface with applications to do the work to build the API and > actually produce the layer that we want with all the information that we > want and whatever APIs are needed. > > There is an ongoing conversation between the TSV ADs who sponsored the > TAPS BOF, APPs and RAI ADs, and interested IAB members about next steps. > The group=E2=80=99s mailing list, taps@ietf.org, currently has 120 subscr= ibers, > and can be joined at https://www.ietf.org/mailman/listinfo/taps. The > accompanying webpage is at > https://sites.google.com/site/transportprotocolservices. > > Activities of some TAPS participants (Michael Welzl, Gorry Fairhurst) wer= e > part-funded by the European Community under its Seventh Framework Program= me > through the Reducing Internet Transport Latency (RITE) project > (ICT-317700). The views expressed are solely those of the author(s). > > > > Figure 1 caption text: Without TAPS (left), the application is tied to > protocol X. With TAPS (right), the application could benefit from protoco= l > Y that is supported by ISP B. > > Figure 2 caption text: Before (left) and after (right) applying TAPS belo= w > a non-TAPS-enabled application. Nothing changes in the application and th= e > middleware API that it uses. > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > > --20cf302d4ae0160a2d04f9d552ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Michael-

This is a nice writeup and,= while I wasn't at the BoF, it seems consistent with the minutes, draft= s and presentations I've seen. =C2=A0I have a few comments:
<= br>
I think it would be more accessible to non-Transport folks if the firs= t paragraph included a couple of descriptions of the capabilities of protoc= ols other than TCP or UDP to give some motivation of why anyone would want = to see TAPS succeed. =C2=A0The list of acronyms at the beginning of the art= icle may be a turn-off to anyone who doesn't recognize them. =C2=A0I re= alize you have space constraints but consider most folks reading this will = be non-experts - think managers. =C2=A0(The experts will read the minutes.)=

Second, the paragraph on debate is one of the most impo= rtant since it highlights some of the open issues that may affect the succe= ss of the work. =C2=A0I'd suggest restructuring it to minimize the name= s of the individuals and expand on the core concerns: predictability, safet= y, binding mechanisms, layer vs. API. =C2=A0Maybe a bulleted list?

Third, and this is sort of beyond the article although = you did invoke the topic, I've been thinking about deployment for TAPS.= =C2=A0It seems important to have a believable deployment story since it ha= s been deployment issues that have hampered use off some of the transport p= rotocols that TAPS intends to make more available. =C2=A0Seems to me like t= he deployment challenge may actually be harder if you are creating a new la= yer / api since you need both ends of the app to support it as well as both= stacks. =C2=A0Has there been any discussion of this? =C2=A0Maybe I'm m= issing something obvious. If so, it's worth stating as part of the conc= ept and if not it's worth listing as an open issue.

Hope this is helpful,

--aaron<= /div>


On= Tue, May 20, 2014 at 3:52 AM, Michael Welzl <michawe@ifi.uio.no>= wrote:
Dear all,

I was invited to write an article about the TAPS BOF for the IETF journal, = with deadline end of May ("exact due date TBD"). This is the info= rmation they gave me:

***
For BoFs, most articles end up being an overview of the BoF, its goals, and= any next steps and/or ongoing work. Pictures and figures are welcome, too,= as separate high-resolution files.

Articles can be anywhere from 500-1500 words, but we are pretty flexible if= you have more or less to say.

We publish articles online to http://www.internetsociety.org/pu= blications/ietf-journal and our Twitter account ( http://twitter.com/ietfjournal)= as they are finalized, and then package everything into a print version ju= st in time for the next IETF.
***


I produced the text below, with two figures attached to this email. Please = let me have any comments / suggestions by the end of this week latest, than= ks!


Cheers,
Michael

********************************************************

TAPS BOF

SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion control mechanism off= er a large number of services to applications in addition to the long-stand= ing two services provided by TCP and UDP. For an application programmer, us= ing protocols other than TCP or UDP is hard: not all protocols are availabl= e everywhere, hence a fall-back solution must be implemented. Some protocol= s provide the same services in different ways. Layering decisions must be m= ade (e.g. should a protocol be used natively or over UDP?). Because of thes= e complications, programmers often resort to either using TCP or implementi= ng their own customized solution over UDP, and chances of benefiting from o= ther transport protocols are lost. The intention of the Transport Services = (TAPS) initiative is to identify the services provided by IETF transport pr= otocols and congestion control mechanisms as well as network requirements o= f applications and the APIs they use to communicate. By finding a mapping b= etween these lists, a potential later WG could define services that a trans= port API should offer. Then, it would specify how these transport services = can be implemented using native IETF transports and encapsulated transports= , including the definition of mechanisms to validate that a transport (or t= ransports) can be supported on a path.

The TAPS initiative began in August 2013 with a mailing list and an accompa= nying web page. We held a "Bar BOF" at IETF-88 in Vancouver, wher= e it was already clarified that TAPS should be careful to provide what appl= ication programmers really need instead of being too focused on the Berkele= y Sockets API. Accordingly, several Internet-drafts were written, including= use cases and an overview of how higher level APIs could better be support= ed by enhanced IETF transport services. By breaking the dependency of appli= cations on specific protocols, TAPS has the potential to make the currently= rigid transport layer more flexible; this is schematically shown in Figure= 1. In December 2013, a presentation was given at the IAB Workshop on Inter= net Technology Adoption and Transition in Cambridge, UK, explaining how the= evolutionary benefit of TAPS is connected to its best-effort nature. These= activities culminated in a Birds-of-a-Feather (BoF) meeting at IETF-89. Th= is BoF was designated "non-WG-forming" to allow the IETF communit= y to discuss the various angles of this large problem space without having = to spend time on charter word-smithing. Discussion was indeed lively at thi= s two-hour long session, with 129 attendees and a debate in which more than= 6650 words were spoken at the microphone.

There were four presentations at the TAPS BoF: Jon Crowcroft outlined the p= otential of this activity, calling it "socket science" and puttin= g it in relation to security. Then, Martin Sustrik presented how middleware= such as his own ZeroMQ could benefit from transports other than TCP; notab= ly, the strict reliability of TCP is a poor match for pub/sub communication= . As shown in Figure 2, updating middleware offers an easy deployment path,= where applications could exploit some of the benefits of TAPS without havi= ng to be changed (except for re-compiling with a new version of the middlew= are). Gorry Fairhurst presented a possible implementation of TAPS, and Marg= aret Wasserman presented the API of the Multiple Interfaces (MIF) Working G= roup. This API is clearly related, and it seems obvious that a TAPS API sho= uld be somehow connected to the MIF API.

All presentations were accompanied by active debate. For example, not every= one agreed with the particular way of providing transport services that was= presented. The flexibility shown in Figure 1 comes at a cost -- applicatio= n programmers may need a very predictable behavior, where a certain way of = using an API always leads to the exact same protocol choice underneath. Thi= s point was made by Stuart Cheshire from Apple, who suggested to make such = decisions at development time, not at runtime; Marie-Jos=C3=A9 Montpetit fr= om MIT stressed the importance of testing. Changing the transport protocol = must not break an application. Ran Atkinson and Dave Thaler suggested to su= pport name-based instead of IP-address-based transports, at least as an opt= ion. Several participants stated that TAPS should not be focusing on an API= -- for example, Pete Resnick said that TAPS should be thought about in ter= ms of a layer, and we should leave it to OSes that interface with applicati= ons to do the work to build the API and actually produce the layer that we = want with all the information that we want and whatever APIs are needed.
There is an ongoing conversation between the TSV ADs who sponsored the TAPS= BOF, APPs and RAI ADs, and interested IAB members about next steps. The gr= oup=E2=80=99s mailing list, taps@ietf.org<= /a>, currently has 120 subscribers, and can be joined at https://www.ietf.org= /mailman/listinfo/taps. The accompanying webpage is at https= ://sites.google.com/site/transportprotocolservices.

Activities of some TAPS participants (Michael Welzl, Gorry Fairhurst) were = part-funded by the European Community under its Seventh Framework Programme= through the Reducing Internet Transport Latency (RITE) project (ICT-317700= ). The views expressed are solely those of the author(s).



Figure 1 caption text: Without TAPS (left), the application is tied to prot= ocol X. With TAPS (right), the application could benefit from protocol Y th= at is supported by ISP B.

Figure 2 caption text: Before (left) and after (right) applying TAPS below = a non-TAPS-enabled application. Nothing changes in the application and the = middleware API that it uses.


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


--20cf302d4ae0160a2d04f9d552ea-- From nobody Tue May 20 07:11:37 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E75B1A071C for ; Tue, 20 May 2014 07:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.005 X-Spam-Level: X-Spam-Status: No, score=0.005 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] 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 39hZvHscFrKf for ; Tue, 20 May 2014 07:11:26 -0700 (PDT) Received: from mail.moloch.sk (chrocht.moloch.sk [62.176.169.44]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 903DD1A0728 for ; Tue, 20 May 2014 07:11:26 -0700 (PDT) Received: from [192.168.0.101] (ip66.bbxnet.sk [91.219.133.66]) by mail.moloch.sk (Postfix) with ESMTPSA id 1035C1806EC4; Tue, 20 May 2014 16:11:24 +0200 (CEST) Message-ID: <537B628B.40002@250bpm.com> Date: Tue, 20 May 2014 16:11:23 +0200 From: Martin Sustrik User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Michael Welzl , taps@ietf.org References: <3760DEA3-68BD-48CC-BB12-281F77F7E6F3@ifi.uio.no> In-Reply-To: <3760DEA3-68BD-48CC-BB12-281F77F7E6F3@ifi.uio.no> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/2vQleG9CasJm5MKmiiICHxhK0Z8 Subject: Re: [Taps] First draft of an article for the IETF journal 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, 20 May 2014 14:11:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michael, I am sorry for not writing down the extract of my talk myself. I've been extremely busy in past few weeks. > Then, Martin Sustrik presented how middleware such as his own > ZeroMQ could benefit from transports Maother than TCP; notably, the > strict reliability of TCP is a poor match for pub/sub > communication. That very much wraps it. I would add one more sentence though: "Moreover, middleware layer often has enough information about what the user is trying to achieve to ask for specific transport services itself and not require the user to do so." Martin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTe2KLAAoJENTpVjxCNN9YvacH/R8P3qu1Xhwmqv9cdA1j4r49 qnhFfqQxk4lw0ZXH8+v5XOgkNXyGpOV1i2C1wsPuRpf6xG75T7ZFyj5rbrq0oHcs 5qbOTndP5gL6rIcFb5WVAHYkzszIiLKOOO5bghCO2LshDQ6d4jYEtjje0BWKgIyA 0Bk3+ReSlrNPSlrRKTm4zXM8OyJfGqhzO4zTqOyKRr3xOHhrP+Fhtee2kXcyiull n8p1Hns3wjmU8BsibSF0JVjm6RdjRL43S+xHrxQ7G3kpEP/+3MM/sA31sYNiLu58 +u+Mn+X+Ec8qfIztNrWvAtlL7Tm1YNZ7VJSj4J+pHuqbujqArAW9rtbG0rMyaZI= =ELHc -----END PGP SIGNATURE----- From nobody Tue May 20 07:16:17 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991881A0364 for ; Tue, 20 May 2014 07:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lig1ZOZc1bVJ for ; Tue, 20 May 2014 07:16:13 -0700 (PDT) Received: from ppsw-40.csi.cam.ac.uk (ppsw-40-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f40]) (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 1FC571A06DA for ; Tue, 20 May 2014 07:16:13 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ravage.cl.cam.ac.uk ([128.232.1.17]:51760) by ppsw-40.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1Wmkpu-0004aX-jY (Exim 4.82_3-c0e5623) (return-path ); Tue, 20 May 2014 15:16:10 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Toby Moncaster In-Reply-To: <537B628B.40002@250bpm.com> Date: Tue, 20 May 2014 15:16:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3760DEA3-68BD-48CC-BB12-281F77F7E6F3@ifi.uio.no> <537B628B.40002@250bpm.com> To: Martin Sustrik X-Mailer: Apple Mail (2.1874) Sender: "T. Moncaster" Archived-At: http://mailarchive.ietf.org/arch/msg/taps/Uo6jtA0FUHeP9qjum6M-5ZTschA Cc: Michael Welzl , taps@ietf.org Subject: Re: [Taps] First draft of an article for the IETF journal 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, 20 May 2014 14:16:15 -0000 Michael, I like Martin=92s addition because it closes off one of the arguments = people use against this work. I think I would word it slightly = differently to say =93Such middleware layers are increasingly common and = often have enough information about what the user is trying to achieve = to be able to make informed transport choices on their behalf." There are a few minor changes I might make to the text, but overall it = reads well, summarises what happened at the BoF and gives a good = oversight of the problem space. Toby On 20 May 2014, at 15:11, Martin Sustrik wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi Michael, >=20 > I am sorry for not writing down the extract of my talk myself. I've > been extremely busy in past few weeks. >=20 >> Then, Martin Sustrik presented how middleware such as his own >> ZeroMQ could benefit from transports Maother than TCP; notably, the >> strict reliability of TCP is a poor match for pub/sub >> communication. >=20 > That very much wraps it. I would add one more sentence though: > "Moreover, middleware layer often has enough information about what > the user is trying to achieve to ask for specific transport services > itself and not require the user to do so." >=20 > Martin > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >=20 > iQEcBAEBAgAGBQJTe2KLAAoJENTpVjxCNN9YvacH/R8P3qu1Xhwmqv9cdA1j4r49 > qnhFfqQxk4lw0ZXH8+v5XOgkNXyGpOV1i2C1wsPuRpf6xG75T7ZFyj5rbrq0oHcs > 5qbOTndP5gL6rIcFb5WVAHYkzszIiLKOOO5bghCO2LshDQ6d4jYEtjje0BWKgIyA > 0Bk3+ReSlrNPSlrRKTm4zXM8OyJfGqhzO4zTqOyKRr3xOHhrP+Fhtee2kXcyiull > n8p1Hns3wjmU8BsibSF0JVjm6RdjRL43S+xHrxQ7G3kpEP/+3MM/sA31sYNiLu58 > +u+Mn+X+Ec8qfIztNrWvAtlL7Tm1YNZ7VJSj4J+pHuqbujqArAW9rtbG0rMyaZI=3D > =3DELHc > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed May 21 01:29: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 972861A083A for ; Wed, 21 May 2014 01:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8Z80ZbodRzS for ; Wed, 21 May 2014 01:29:27 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D17BD1A028F for ; Wed, 21 May 2014 01:29:26 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Wn1tr-0001FB-4s; Wed, 21 May 2014 10:29:23 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Wn1tq-0005qF-QU; Wed, 21 May 2014 10:29:23 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Michael Welzl In-Reply-To: Date: Wed, 21 May 2014 10:29:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <20B0E02B-1983-406A-B4A0-30926B69F708@ifi.uio.no> References: <3760DEA3-68BD-48CC-BB12-281F77F7E6F3@ifi.uio.no> <537B628B.40002@250bpm.com> To: Toby Moncaster X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 23 msgs/h 8 sum rcpts/h 23 sum msgs/h 8 total rcpts 16513 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: B3A254ABEF246994C4DA80D73BCB63FEBC182751 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 7 total 5369 max/h 16 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/zIAKHg9V6Ln_eg3tF514Zc7bF4g Cc: Martin Sustrik , taps@ietf.org Subject: Re: [Taps] First draft of an article for the IETF journal 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, 21 May 2014 08:29:30 -0000 Hi, On 20. mai 2014, at 16:16, Toby Moncaster wrote: > Michael, >=20 > I like Martin=92s addition because it closes off one of the arguments = people use against this work. I think I would word it slightly = differently to say =93Such middleware layers are increasingly common and = often have enough information about what the user is trying to achieve = to be able to make informed transport choices on their behalf." Thanks, incorporated (I agree, I like his statement too, but your = wording is nicer). > There are a few minor changes I might make to the text, but overall it = reads well, summarises what happened at the BoF and gives a good = oversight of the problem space. Please, by all means, go ahead! (but note I'll send an update that has all the suggestions to the list = in a few mins) From nobody Wed May 21 02:11:14 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721541A049C for ; Wed, 21 May 2014 02:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKgnFQy25FZT for ; Wed, 21 May 2014 02:11:12 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99A971A031F for ; Wed, 21 May 2014 02:11:11 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Wn2YH-0001y4-C4; Wed, 21 May 2014 11:11:09 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Wn2YG-0002F1-Sv; Wed, 21 May 2014 11:11:09 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: Date: Wed, 21 May 2014 11:11:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <53D45CA0-8CDB-4F73-AC18-1FF7B8EFBDE6@ifi.uio.no> References: <3760DEA3-68BD-48CC-BB12-281F77F7E6F3@ifi.uio.no> To: Aaron Falk X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 15 sum msgs/h 6 total rcpts 16519 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: 7AF698FE446A93FAB08AACBF1FCBBBF47C42E643 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 5372 max/h 16 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/OBeOdBaxborIic1baa8yc8CfvRk Cc: taps@ietf.org Subject: Re: [Taps] First draft of an article for the IETF journal 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, 21 May 2014 09:11:13 -0000 Hi, On 20. mai 2014, at 16:01, Aaron Falk wrote: > Hi Michael- >=20 > This is a nice writeup and, while I wasn't at the BoF, it seems = consistent with the minutes, drafts and presentations I've seen. I have = a few comments: >=20 > I think it would be more accessible to non-Transport folks if the = first paragraph included a couple of descriptions of the capabilities of = protocols other than TCP or UDP to give some motivation of why anyone = would want to see TAPS succeed. The list of acronyms at the beginning = of the article may be a turn-off to anyone who doesn't recognize them. = I realize you have space constraints but consider most folks reading = this will be non-experts - think managers. (The experts will read the = minutes.) >=20 > Second, the paragraph on debate is one of the most important since it = highlights some of the open issues that may affect the success of the = work. I'd suggest restructuring it to minimize the names of the = individuals and expand on the core concerns: predictability, safety, = binding mechanisms, layer vs. API. Maybe a bulleted list? Thanks a lot for these suggestions! All incorporated. > Third, and this is sort of beyond the article although you did invoke = the topic, I've been thinking about deployment for TAPS. It seems = important to have a believable deployment story since it has been = deployment issues that have hampered use off some of the transport = protocols that TAPS intends to make more available. Seems to me like = the deployment challenge may actually be harder if you are creating a = new layer / api since you need both ends of the app to support it as = well as both stacks. Has there been any discussion of this? Maybe I'm = missing something obvious. If so, it's worth stating as part of the = concept and if not it's worth listing as an open issue. My opinion: at first, we should focus on things that can be installed = one-sided, on the sender side only. Yes it's limited, but a number of things are possible there. E.g., = pluggable congestion controls in TCP have always worked without = involving the receiver - but right now, pluggable congestion control = isn't an IETF matter. Happy Eyeballs can be done without coordinating = with a receiver, at least for the case that we're using well-known ports = and the receiver listens on more than one protocol. But yes, quite quickly one runs into limitations there; anyway, for = divide-and-conquer :-) reasons, I think we want to go with a = sender-side-only-installation assumption for now. Though, I'm not sure = if we have had enough discussions on this and if absolutely everyone is = on the same page (though, indirectly perhaps, as our draft charter = states that signaling is out of scope, and signaling would be needed to = align both ends). Cheers, Michael From nobody Wed May 21 02:13:03 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD461A0315 for ; Wed, 21 May 2014 02:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hg72RpUtMUzS for ; Wed, 21 May 2014 02:12:59 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC2561A0312 for ; Wed, 21 May 2014 02:12:58 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Wn2a0-00033m-LC for taps@ietf.org; Wed, 21 May 2014 11:12:56 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1Wn2Zz-0003UV-S0 for taps@ietf.org; Wed, 21 May 2014 11:12:56 +0200 From: Michael Welzl Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 21 May 2014 11:12:55 +0200 Message-Id: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> To: taps@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 2 sum rcpts/h 16 sum msgs/h 7 total rcpts 16520 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: CC57C12FA87A4F97642055AB937557B6C2BE69D2 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 5373 max/h 16 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/ig51hzrPYaC6iNYHuTLWu9THN9w Subject: [Taps] IETF journal article update 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, 21 May 2014 09:13:02 -0000 Hi, Here's an update of the text, incorporating the many comments I = received. Thanks a lot to all of you who made suggestions! Further = comments are very welcome, of course. Cheers, Michael TAPS BOF The protocols SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion = control mechanism offer a large number of services to applications in = addition to the long-standing two services provided by TCP and UDP. For = example, SCTP provides reliable and potentially faster-than-TCP delivery = of data chunks to applications that may be able to accept such chunks = out of order. DCCP provides various forms of congestion control for = applications that need it, but would rather have their packets dropped = than retransmitted, as the latter can lead to delay. LEDBAT provides a = scavenger-like background transfer mode, where LEDBAT traffic does not = get in the way of other transfers that use TCP, for instance. Useful as = these services may be, using them is hard for an application programmer: = not all protocols are available everywhere, hence a fall-back solution = must be implemented. Some protocols provide the same services in = different ways. Layering decisions must be made (e.g. should a protocol = be used natively or over UDP?). Because of these complications, = programmers often resort to either using TCP or implementing their own = customized solution over UDP (e.g., Google with QUIC [1] and Adobe with = RTMFP [2]), and chances of benefiting from other transport protocols are = lost. The intention of the Transport Services (TAPS) initiative is to = identify the services provided by IETF transport protocols and = congestion control mechanisms as well as network requirements of = applications and the APIs they use to communicate. By finding a mapping = between these lists, a potential later WG could define services that a = transport API should offer. Then, it would specify how these transport = services can be implemented using native IETF transports and = encapsulated transports, including the definition of mechanisms to = validate that a transport (or transports) can be supported on a path. The TAPS initiative began in August 2013 with a mailing list and an = accompanying web page. We held a "Bar BOF" at IETF-88 in Vancouver, = where it was already clarified that TAPS should be careful to provide = what application programmers really need instead of being too focused on = the Berkeley Sockets API. Accordingly, several Internet-drafts were = written, including use cases and an overview of how higher level APIs = could better be supported by enhanced IETF transport services. By = breaking the dependency of applications on specific protocols, TAPS has = the potential to make the currently rigid transport layer more flexible; = this is schematically shown in Figure 1. In December 2013, a = presentation was given at the IAB Workshop on Internet Technology = Adoption and Transition in Cambridge, UK, explaining how the = evolutionary benefit of TAPS is connected to its best-effort nature. = These activities culminated in a Birds-of-a-Feather (BoF) meeting at = IETF-89. This BoF was designated "non-WG-forming" to allow the IETF = community to discuss the various angles of this large problem space = without having to spend time on charter word-smithing. Discussion was = indeed lively at this two-hour long session, with 129 attendees and a = debate in which more than 6650 words were spoken at the microphone. There were four presentations at the TAPS BoF: Jon Crowcroft outlined = the potential of this activity, calling it "socket science" and putting = it in relation to security. Then, Martin Sustrik presented how = middleware such as his own ZeroMQ could benefit from transports other = than TCP; notably, the strict reliability of TCP is a poor match for = pub/sub communication. Such middleware layers are increasingly common = and often have enough information about what the user is trying to = achieve to be able to make informed transport choices on their behalf. = As shown in Figure 2, updating middleware offers an easy deployment = path, where applications could exploit some of the benefits of TAPS = without having to be changed (except for re-compiling with a new version = of the middleware). Gorry Fairhurst presented a possible implementation = of TAPS, and Margaret Wasserman presented the API of the Multiple = Interfaces (MIF) Working Group. This API is clearly related, and it = seems obvious that a TAPS API should be somehow connected to the MIF = API. predictability, safety, binding mechanisms, layer vs. API. All presentations were accompanied by active debate; for example, not = everyone agreed with the particular way of providing transport services = that was presented. The major concerns that were raised are: - Predictability: the flexibility shown in Figure 1 comes at a cost -- = application programmers may need a very predictable behavior, where a = certain way of using an API always leads to the exact same protocol = choice underneath. It was suggested that such decisions should be made = at development time, not at runtime. - Safety: the importance of testing was stressed; changing the transport = protocol must not break an application. - Binding mechanisms: going even beyond what TAPS proposes, it was = suggested to support name-based instead of IP-address-based transports, = at least as an option. - Layer vs. API: several participants stated that TAPS should not be = focusing on an API -- it was said that TAPS should be thought about in = terms of a layer, and we should leave it to OSes that interface with = applications to do the work to build the API and actually produce the = layer that we want with all the information that we want and whatever = APIs are needed. There is an ongoing conversation between the TSV ADs who sponsored the = TAPS BOF, APPs and RAI ADs, and interested IAB members about next steps. = The group=92s mailing list, taps@ietf.org, currently has 120 = subscribers, and can be joined at = https://www.ietf.org/mailman/listinfo/taps. The accompanying webpage is = at https://sites.google.com/site/transportprotocolservices. Activities of some TAPS participants (Michael Welzl, Gorry Fairhurst) = were part-funded by the European Community under its Seventh Framework = Programme through the Reducing Internet Transport Latency (RITE) project = (ICT-317700). The views expressed are solely those of the author(s). Figure 1 caption text: Without TAPS (left), the application is tied to = protocol X. With TAPS (right), the application could benefit from = protocol Y that is supported by ISP B. Figure 2 caption text: Before (left) and after (right) applying TAPS = below a non-TAPS-enabled application. Nothing changes in the application = and the middleware API that it uses. References: [1] http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf [2] RFC 7016, "Adobe's Secure Real-Time Media Flow Protocol" From nobody Wed May 21 03:58:09 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61ED1A04C2 for ; Wed, 21 May 2014 03:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxRhiYi7l6Yp for ; Wed, 21 May 2014 03:58:05 -0700 (PDT) Received: from mail3.nrl.navy.mil (mail3.nrl.navy.mil [IPv6:2001:480:20:404::465:27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52EFA1A04B4 for ; Wed, 21 May 2014 03:58:04 -0700 (PDT) Received: from [192.168.1.103] (c-76-21-150-94.hsd1.md.comcast.net [76.21.150.94]) (authenticated bits=0) by mail3.nrl.navy.mil (8.14.8/8.14.8) with ESMTP id s4LAvrA3019670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 May 2014 06:57:57 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Adamson In-Reply-To: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> Date: Wed, 21 May 2014 06:57:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1510) X-Scanned-By: MIMEDefang 2.72 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/-gs1OXBJuLobiNyymgrCLhnDO8w Cc: taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 21 May 2014 10:58:07 -0000 Hi Michael, Are there plans to also include multicast transport protocols under the = TAPS umbrella? For example, I recently ported our NORM (RFC 5740) = implementation into the ZeroMQ libzmq library to take advantage of API = it provides. However, there's quite a bit of added NORM features that = could be tapped (no pun intended) with additional API primitives beyond = what ZeroMQ currently provides to meet different multicast application = needs. It may be useful to mention if TAPS may address multicast = transport capabilities as well. best regards, Brian On May 21, 2014, at 5:12 AM, Michael Welzl wrote: > Hi, >=20 > Here's an update of the text, incorporating the many comments I = received. Thanks a lot to all of you who made suggestions! Further = comments are very welcome, of course. >=20 > Cheers, > Michael >=20 >=20 > TAPS BOF >=20 > The protocols SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion = control mechanism offer a large number of services to applications in = addition to the long-standing two services provided by TCP and UDP. For = example, SCTP provides reliable and potentially faster-than-TCP delivery = of data chunks to applications that may be able to accept such chunks = out of order. DCCP provides various forms of congestion control for = applications that need it, but would rather have their packets dropped = than retransmitted, as the latter can lead to delay. LEDBAT provides a = scavenger-like background transfer mode, where LEDBAT traffic does not = get in the way of other transfers that use TCP, for instance. Useful as = these services may be, using them is hard for an application programmer: = not all protocols are available everywhere, hence a fall-back solution = must be implemented. Some protocols provide the same services in = different ways. Layering decisions must be made (e.g. should a protocol = be used natively or over UDP?). Because of these complications, = programmers often resort to either using TCP or implementing their own = customized solution over UDP (e.g., Google with QUIC [1] and Adobe with = RTMFP [2]), and chances of benefiting from other transport protocols are = lost. The intention of the Transport Services (TAPS) initiative is to = identify the services provided by IETF transport protocols and = congestion control mechanisms as well as network requirements of = applications and the APIs they use to communicate. By finding a mapping = between these lists, a potential later WG could define services that a = transport API should offer. Then, it would specify how these transport = services can be implemented using native IETF transports and = encapsulated transports, including the definition of mechanisms to = validate that a transport (or transports) can be supported on a path. >=20 > The TAPS initiative began in August 2013 with a mailing list and an = accompanying web page. We held a "Bar BOF" at IETF-88 in Vancouver, = where it was already clarified that TAPS should be careful to provide = what application programmers really need instead of being too focused on = the Berkeley Sockets API. Accordingly, several Internet-drafts were = written, including use cases and an overview of how higher level APIs = could better be supported by enhanced IETF transport services. By = breaking the dependency of applications on specific protocols, TAPS has = the potential to make the currently rigid transport layer more flexible; = this is schematically shown in Figure 1. In December 2013, a = presentation was given at the IAB Workshop on Internet Technology = Adoption and Transition in Cambridge, UK, explaining how the = evolutionary benefit of TAPS is connected to its best-effort nature. = These activities culminated in a Birds-of-a-Feather (BoF) meeting at = IETF-89. This BoF was designated "non-WG-forming" to allow the IETF = community to discuss the various angles of this large problem space = without having to spend time on charter word-smithing. Discussion was = indeed lively at this two-hour long session, with 129 attendees and a = debate in which more than 6650 words were spoken at the microphone. >=20 > There were four presentations at the TAPS BoF: Jon Crowcroft outlined = the potential of this activity, calling it "socket science" and putting = it in relation to security. Then, Martin Sustrik presented how = middleware such as his own ZeroMQ could benefit from transports other = than TCP; notably, the strict reliability of TCP is a poor match for = pub/sub communication. Such middleware layers are increasingly common = and often have enough information about what the user is trying to = achieve to be able to make informed transport choices on their behalf. = As shown in Figure 2, updating middleware offers an easy deployment = path, where applications could exploit some of the benefits of TAPS = without having to be changed (except for re-compiling with a new version = of the middleware). Gorry Fairhurst presented a possible implementation = of TAPS, and Margaret Wasserman presented the API of the Multiple = Interfaces (MIF) Working Group. This API is clearly related, and it = seems obvious that a TAPS API should be somehow connected to the MIF = API. >=20 > predictability, safety, binding mechanisms, layer vs. API. > All presentations were accompanied by active debate; for example, not = everyone agreed with the particular way of providing transport services = that was presented. The major concerns that were raised are: > - Predictability: the flexibility shown in Figure 1 comes at a cost -- = application programmers may need a very predictable behavior, where a = certain way of using an API always leads to the exact same protocol = choice underneath. It was suggested that such decisions should be made = at development time, not at runtime. > - Safety: the importance of testing was stressed; changing the = transport protocol must not break an application. > - Binding mechanisms: going even beyond what TAPS proposes, it was = suggested to support name-based instead of IP-address-based transports, = at least as an option. > - Layer vs. API: several participants stated that TAPS should not be = focusing on an API -- it was said that TAPS should be thought about in = terms of a layer, and we should leave it to OSes that interface with = applications to do the work to build the API and actually produce the = layer that we want with all the information that we want and whatever = APIs are needed. >=20 > There is an ongoing conversation between the TSV ADs who sponsored the = TAPS BOF, APPs and RAI ADs, and interested IAB members about next steps. = The group=92s mailing list, taps@ietf.org, currently has 120 = subscribers, and can be joined at = https://www.ietf.org/mailman/listinfo/taps. The accompanying webpage is = at https://sites.google.com/site/transportprotocolservices. >=20 > Activities of some TAPS participants (Michael Welzl, Gorry Fairhurst) = were part-funded by the European Community under its Seventh Framework = Programme through the Reducing Internet Transport Latency (RITE) project = (ICT-317700). The views expressed are solely those of the author(s). >=20 >=20 >=20 > Figure 1 caption text: Without TAPS (left), the application is tied to = protocol X. With TAPS (right), the application could benefit from = protocol Y that is supported by ISP B. >=20 > Figure 2 caption text: Before (left) and after (right) applying TAPS = below a non-TAPS-enabled application. Nothing changes in the application = and the middleware API that it uses. >=20 >=20 > References: > [1] http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf > [2] RFC 7016, "Adobe's Secure Real-Time Media Flow Protocol" >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed May 21 04:25: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 CE3201A052E for ; Wed, 21 May 2014 04:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUNQi0ZyTCTt for ; Wed, 21 May 2014 04:25:18 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 249381A0515 for ; Wed, 21 May 2014 04:25:18 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Wn4e3-0000F0-SH; Wed, 21 May 2014 13:25:15 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Wn4e3-0002ul-33; Wed, 21 May 2014 13:25:15 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Michael Welzl In-Reply-To: <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> Date: Wed, 21 May 2014 13:25:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> To: Brian Adamson X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 6 sum rcpts/h 16 sum msgs/h 9 total rcpts 16536 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: 692BC5352E68FDC808AECAC403570140E8FE4B84 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 6 total 5383 max/h 16 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/NbRcUpgNGwnRp6N9n0MLdH3O514 Cc: taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 21 May 2014 11:25:22 -0000 Hi, Are there plans: I think it hasn't really been brought up yet. My personal opinion: yes, we should include multicast. Other opinions? Cheers, Michael On 21. mai 2014, at 12:57, Brian Adamson wrote: > Hi Michael, >=20 > Are there plans to also include multicast transport protocols under = the TAPS umbrella? For example, I recently ported our NORM (RFC 5740) = implementation into the ZeroMQ libzmq library to take advantage of API = it provides. However, there's quite a bit of added NORM features that = could be tapped (no pun intended) with additional API primitives beyond = what ZeroMQ currently provides to meet different multicast application = needs. It may be useful to mention if TAPS may address multicast = transport capabilities as well. >=20 > best regards, >=20 > Brian >=20 >=20 > On May 21, 2014, at 5:12 AM, Michael Welzl wrote: >=20 >> Hi, >>=20 >> Here's an update of the text, incorporating the many comments I = received. Thanks a lot to all of you who made suggestions! Further = comments are very welcome, of course. >>=20 >> Cheers, >> Michael >>=20 >>=20 >> TAPS BOF >>=20 >> The protocols SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion = control mechanism offer a large number of services to applications in = addition to the long-standing two services provided by TCP and UDP. For = example, SCTP provides reliable and potentially faster-than-TCP delivery = of data chunks to applications that may be able to accept such chunks = out of order. DCCP provides various forms of congestion control for = applications that need it, but would rather have their packets dropped = than retransmitted, as the latter can lead to delay. LEDBAT provides a = scavenger-like background transfer mode, where LEDBAT traffic does not = get in the way of other transfers that use TCP, for instance. Useful as = these services may be, using them is hard for an application programmer: = not all protocols are available everywhere, hence a fall-back solution = must be implemented. Some protocols provide the same services in = different ways. Layering decisions must be made (e.g. should a protocol = be used natively or over UDP?). Because of these complications, = programmers often resort to either using TCP or implementing their own = customized solution over UDP (e.g., Google with QUIC [1] and Adobe with = RTMFP [2]), and chances of benefiting from other transport protocols are = lost. The intention of the Transport Services (TAPS) initiative is to = identify the services provided by IETF transport protocols and = congestion control mechanisms as well as network requirements of = applications and the APIs they use to communicate. By finding a mapping = between these lists, a potential later WG could define services that a = transport API should offer. Then, it would specify how these transport = services can be implemented using native IETF transports and = encapsulated transports, including the definition of mechanisms to = validate that a transport (or transports) can be supported on a path. >>=20 >> The TAPS initiative began in August 2013 with a mailing list and an = accompanying web page. We held a "Bar BOF" at IETF-88 in Vancouver, = where it was already clarified that TAPS should be careful to provide = what application programmers really need instead of being too focused on = the Berkeley Sockets API. Accordingly, several Internet-drafts were = written, including use cases and an overview of how higher level APIs = could better be supported by enhanced IETF transport services. By = breaking the dependency of applications on specific protocols, TAPS has = the potential to make the currently rigid transport layer more flexible; = this is schematically shown in Figure 1. In December 2013, a = presentation was given at the IAB Workshop on Internet Technology = Adoption and Transition in Cambridge, UK, explaining how the = evolutionary benefit of TAPS is connected to its best-effort nature. = These activities culminated in a Birds-of-a-Feather (BoF) meeting at = IETF-89. This BoF was designated "non-WG-forming" to allow the IETF = community to discuss the various angles of this large problem space = without having to spend time on charter word-smithing. Discussion was = indeed lively at this two-hour long session, with 129 attendees and a = debate in which more than 6650 words were spoken at the microphone. >>=20 >> There were four presentations at the TAPS BoF: Jon Crowcroft outlined = the potential of this activity, calling it "socket science" and putting = it in relation to security. Then, Martin Sustrik presented how = middleware such as his own ZeroMQ could benefit from transports other = than TCP; notably, the strict reliability of TCP is a poor match for = pub/sub communication. Such middleware layers are increasingly common = and often have enough information about what the user is trying to = achieve to be able to make informed transport choices on their behalf. = As shown in Figure 2, updating middleware offers an easy deployment = path, where applications could exploit some of the benefits of TAPS = without having to be changed (except for re-compiling with a new version = of the middleware). Gorry Fairhurst presented a possible implementation = of TAPS, and Margaret Wasserman presented the API of the Multiple = Interfaces (MIF) Working Group. This API is clearly related, and it = seems obvious that a TAPS API should be somehow connected to the MIF = API. >>=20 >> predictability, safety, binding mechanisms, layer vs. API. >> All presentations were accompanied by active debate; for example, not = everyone agreed with the particular way of providing transport services = that was presented. The major concerns that were raised are: >> - Predictability: the flexibility shown in Figure 1 comes at a cost = -- application programmers may need a very predictable behavior, where a = certain way of using an API always leads to the exact same protocol = choice underneath. It was suggested that such decisions should be made = at development time, not at runtime. >> - Safety: the importance of testing was stressed; changing the = transport protocol must not break an application. >> - Binding mechanisms: going even beyond what TAPS proposes, it was = suggested to support name-based instead of IP-address-based transports, = at least as an option. >> - Layer vs. API: several participants stated that TAPS should not be = focusing on an API -- it was said that TAPS should be thought about in = terms of a layer, and we should leave it to OSes that interface with = applications to do the work to build the API and actually produce the = layer that we want with all the information that we want and whatever = APIs are needed. >>=20 >> There is an ongoing conversation between the TSV ADs who sponsored = the TAPS BOF, APPs and RAI ADs, and interested IAB members about next = steps. The group=92s mailing list, taps@ietf.org, currently has 120 = subscribers, and can be joined at = https://www.ietf.org/mailman/listinfo/taps. The accompanying webpage is = at https://sites.google.com/site/transportprotocolservices. >>=20 >> Activities of some TAPS participants (Michael Welzl, Gorry Fairhurst) = were part-funded by the European Community under its Seventh Framework = Programme through the Reducing Internet Transport Latency (RITE) project = (ICT-317700). The views expressed are solely those of the author(s). >>=20 >>=20 >>=20 >> Figure 1 caption text: Without TAPS (left), the application is tied = to protocol X. With TAPS (right), the application could benefit from = protocol Y that is supported by ISP B. >>=20 >> Figure 2 caption text: Before (left) and after (right) applying TAPS = below a non-TAPS-enabled application. Nothing changes in the application = and the middleware API that it uses. >>=20 >>=20 >> References: >> [1] = http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf >> [2] RFC 7016, "Adobe's Secure Real-Time Media Flow Protocol" >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed May 21 04:36:03 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669B81A052E for ; Wed, 21 May 2014 04:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Onu7Qq3s4dk for ; Wed, 21 May 2014 04:35:58 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id F00561A0341 for ; Wed, 21 May 2014 04:35:57 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 8BF9A2B456E; Wed, 21 May 2014 12:35:56 +0100 (BST) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 7798D2B4044; Wed, 21 May 2014 12:35:53 +0100 (BST) Message-ID: <537C8F99.8040308@erg.abdn.ac.uk> Date: Wed, 21 May 2014 12:35:53 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Michael Welzl , Brian Adamson References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/F57n0XiKPAeBoa4Ii7fJLCMJ_IE Cc: taps@ietf.org Subject: Re: [Taps] IETF journal article update X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 11:36:00 -0000 My thoughts at this moment: I'd be keen to see multicast supported in the architecture - but I am less sure we should initially open work items on multicast APIs and mechanisms, since this may be a wider set of behaviours and use-styles. I'd prefer to focus initial specification work on a few things for which we expect the most common use. gorry On 21/05/2014 12:25, Michael Welzl wrote: > Hi, > > Are there plans: I think it hasn't really been brought up yet. > My personal opinion: yes, we should include multicast. > > Other opinions? > > Cheers, > Michael > > > On 21. mai 2014, at 12:57, Brian Adamson wrote: > >> Hi Michael, >> >> Are there plans to also include multicast transport protocols under the TAPS umbrella? For example, I recently ported our NORM (RFC 5740) implementation into the ZeroMQ libzmq library to take advantage of API it provides. However, there's quite a bit of added NORM features that could be tapped (no pun intended) with additional API primitives beyond what ZeroMQ currently provides to meet different multicast application needs. It may be useful to mention if TAPS may address multicast transport capabilities as well. >> >> best regards, >> >> Brian >> >> >> On May 21, 2014, at 5:12 AM, Michael Welzl wrote: >> >>> Hi, >>> >>> Here's an update of the text, incorporating the many comments I received. Thanks a lot to all of you who made suggestions! Further comments are very welcome, of course. >>> >>> Cheers, >>> Michael >>> >>> >>> TAPS BOF >>> >>> The protocols SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion control mechanism offer a large number of services to applications in addition to the long-standing two services provided by TCP and UDP. For example, SCTP provides reliable and potentially faster-than-TCP delivery of data chunks to applications that may be able to accept such chunks out of order. DCCP provides various forms of congestion control for applications that need it, but would rather have their packets dropped than retransmitted, as the latter can lead to delay. LEDBAT provides a scavenger-like background transfer mode, where LEDBAT traffic does not get in the way of other transfers that use TCP, for instance. Useful as these services may be, using them is hard for an application programmer: not all protocols are available everywhere, hence a fall-back solution must be implemented. Some protocols provide the same services in different ways. Layering decisions must be made (e.g. should a protocol be used natively or over UDP?). Because of these complications, programmers often resort to either using TCP or implementing their own customized solution over UDP (e.g., Google with QUIC [1] and Adobe with RTMFP [2]), and chances of benefiting from other transport protocols are lost. The intention of the Transport Services (TAPS) initiative is to identify the services provided by IETF transport protocols and congestion control mechanisms as well as network requirements of applications and the APIs they use to communicate. By finding a mapping between these lists, a potential later WG could define services that a transport API should offer. Then, it would specify how these transport services can be implemented using native IETF transports and encapsulated transports, including the definition of mechanisms to validate that a transport (or transports) can be supported on a path. >>> >>> The TAPS initiative began in August 2013 with a mailing list and an accompanying web page. We held a "Bar BOF" at IETF-88 in Vancouver, where it was already clarified that TAPS should be careful to provide what application programmers really need instead of being too focused on the Berkeley Sockets API. Accordingly, several Internet-drafts were written, including use cases and an overview of how higher level APIs could better be supported by enhanced IETF transport services. By breaking the dependency of applications on specific protocols, TAPS has the potential to make the currently rigid transport layer more flexible; this is schematically shown in Figure 1. In December 2013, a presentation was given at the IAB Workshop on Internet Technology Adoption and Transition in Cambridge, UK, explaining how the evolutionary benefit of TAPS is connected to its best-effort nature. These activities culminated in a Birds-of-a-Feather (BoF) meeting at IETF-89. This BoF was designated "non-WG- forming" to allow the IETF community to discuss the various angles of this large problem space without having to spend time on charter word-smithing. Discussion was indeed lively at this two-hour long session, with 129 attendees and a debate in which more than 6650 words were spoken at the microphone. >>> >>> There were four presentations at the TAPS BoF: Jon Crowcroft outlined the potential of this activity, calling it "socket science" and putting it in relation to security. Then, Martin Sustrik presented how middleware such as his own ZeroMQ could benefit from transports other than TCP; notably, the strict reliability of TCP is a poor match for pub/sub communication. Such middleware layers are increasingly common and often have enough information about what the user is trying to achieve to be able to make informed transport choices on their behalf. As shown in Figure 2, updating middleware offers an easy deployment path, where applications could exploit some of the benefits of TAPS without having to be changed (except for re-compiling with a new version of the middleware). Gorry Fairhurst presented a possible implementation of TAPS, and Margaret Wasserman presented the API of the Multiple Interfaces (MIF) Working Group. This API is clearly related, and it seems obvious that a TAPS AP I should be somehow connected to the MIF API. >>> >>> predictability, safety, binding mechanisms, layer vs. API. >>> All presentations were accompanied by active debate; for example, not everyone agreed with the particular way of providing transport services that was presented. The major concerns that were raised are: >>> - Predictability: the flexibility shown in Figure 1 comes at a cost -- application programmers may need a very predictable behavior, where a certain way of using an API always leads to the exact same protocol choice underneath. It was suggested that such decisions should be made at development time, not at runtime. >>> - Safety: the importance of testing was stressed; changing the transport protocol must not break an application. >>> - Binding mechanisms: going even beyond what TAPS proposes, it was suggested to support name-based instead of IP-address-based transports, at least as an option. >>> - Layer vs. API: several participants stated that TAPS should not be focusing on an API -- it was said that TAPS should be thought about in terms of a layer, and we should leave it to OSes that interface with applications to do the work to build the API and actually produce the layer that we want with all the information that we want and whatever APIs are needed. >>> >>> There is an ongoing conversation between the TSV ADs who sponsored the TAPS BOF, APPs and RAI ADs, and interested IAB members about next steps. The group’s mailing list, taps@ietf.org, currently has 120 subscribers, and can be joined at https://www.ietf.org/mailman/listinfo/taps. The accompanying webpage is at https://sites.google.com/site/transportprotocolservices. >>> >>> Activities of some TAPS participants (Michael Welzl, Gorry Fairhurst) were part-funded by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700). The views expressed are solely those of the author(s). >>> >>> >>> >>> Figure 1 caption text: Without TAPS (left), the application is tied to protocol X. With TAPS (right), the application could benefit from protocol Y that is supported by ISP B. >>> >>> Figure 2 caption text: Before (left) and after (right) applying TAPS below a non-TAPS-enabled application. Nothing changes in the application and the middleware API that it uses. >>> >>> >>> References: >>> [1] http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf >>> [2] RFC 7016, "Adobe's Secure Real-Time Media Flow Protocol" >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Wed May 21 06:41:53 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEEC21A06A0 for ; Wed, 21 May 2014 06:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 320iMFJfogae for ; Wed, 21 May 2014 06:41:50 -0700 (PDT) Received: from mail-vc0-f198.google.com (mail-vc0-f198.google.com [209.85.220.198]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 429571A069D for ; Wed, 21 May 2014 06:41:50 -0700 (PDT) Received: by mail-vc0-f198.google.com with SMTP id ij19so6433843vcb.9 for ; Wed, 21 May 2014 06:41:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=YELWownT/bS68a4FtN9/M5sEUeVjn4HiQz46AzMNktQ=; b=E1ylNY3ptm0Fs1hTLuOo4uSZrtNxvW+McKnLHVcd9imVXlQ2S5it6id9teHzeJwxU8 93GDecKTjAXmkp/8XDnn3HwGfdQss77hse9quNne30HJL/nEHOOPev+XlsR0yQnVBcps uqf4RZYc5xPSC4waWExygZq6KActKhuwUaS89Ms8Gqhwt6CiyVc6r9k5VyD/F8iG0/GY 5kgQSd417EVene/2bfdKceKaFvWTRRN6pM8uTlVeZPJhmH7qTXz4PtlsDbLXQxShQGvX d1akMHQEM5Va1eaOSb13jW6XQJbMJH1mlW+phfqK5Ge+eg5CnT2MQyHmEdA68/vAbUTn lxqw== X-Gm-Message-State: ALoCoQmorRq3EmC6W+zLhNflB7jbcb9c1poxQlGzmD578SqKT2w+u8aTH54MTV+LSw6ZfJAhnCV5 X-Received: by 10.220.48.8 with SMTP id p8mr310552vcf.75.1400679708506; Wed, 21 May 2014 06:41:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.84.35 with HTTP; Wed, 21 May 2014 06:41:28 -0700 (PDT) From: Aaron Falk Date: Wed, 21 May 2014 09:41:28 -0400 Message-ID: To: Michael Welzl Content-Type: multipart/alternative; boundary=089e0158ab8a7886dc04f9e92811 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/Qo9rJ9JtbGIaYPAWOWVwzf3Jmn0 Cc: taps@ietf.org Subject: Re: [Taps] First draft of an article for the IETF journal 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, 21 May 2014 13:41:51 -0000 --089e0158ab8a7886dc04f9e92811 Content-Type: text/plain; charset=UTF-8 On Wed, May 21, 2014 at 5:11 AM, Michael Welzl wrote: > > My opinion: at first, we should focus on things that can be installed > one-sided, on the sender side only. Yes it's limited, but a number of > things are possible there. E.g., pluggable congestion controls in TCP have > always worked without involving the receiver - but right now, pluggable > congestion control isn't an IETF matter. Happy Eyeballs can be done without > coordinating with a receiver, at least for the case that we're using > well-known ports and the receiver listens on more than one protocol. I've forgotten the details of 'Happy Eyeballs'. Can you provide a cite? > > But yes, quite quickly one runs into limitations there; anyway, for > divide-and-conquer :-) reasons, I think we want to go with a > sender-side-only-installation assumption for now. Seems worth exploring the implications of such an approach where you have the same app sitting on top of very different APIs (e.g., Berkeley socket vs TAPS) at either end of the connection. That combined with an app where either endpoint might be a sender. > Though, I'm not sure if we have had enough discussions on this and if > absolutely everyone is on the same page (though, indirectly perhaps, as our > draft charter states that signaling is out of scope, and signaling would be > needed to align both ends). > yup cheers, --aaron --089e0158ab8a7886dc04f9e92811 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, May 21, 2014 at 5:11 AM, Michael Welzl <michawe@ifi.uio.no> wrote:

My opinion: at first, we should focus on things that can be installed= one-sided, on the sender side only. Yes it's limited, but a number of = things are possible there. E.g., pluggable congestion controls in TCP have = always worked without involving the receiver - but right now, pluggable con= gestion control isn't an IETF matter. Happy Eyeballs can be done withou= t coordinating with a receiver, at least for the case that we're using = well-known ports and the receiver listens on more than one protocol.

I've forgotten the details of 'Happy Eyeballs&#= 39;. =C2=A0Can you provide a cite?
=C2=A0

But yes, quite quickly one runs into limitations there; anyway, for divide-= and-conquer =C2=A0:-) =C2=A0 reasons, I think we want to go with a sender-s= ide-only-installation assumption for now.

= Seems worth exploring the implications of such an approach where you have t= he same app sitting on top of very different APIs (e.g., Berkeley socket vs= TAPS) at either end of the connection. =C2=A0That combined with an app whe= re either endpoint might be a sender.

=C2=A0
Though, I= 9;m not sure if we have had enough discussions on this and if absolutely ev= eryone is on the same page (though, indirectly perhaps, as our draft charte= r states that signaling is out of scope, and signaling would be needed to a= lign both ends).

yup

cheers,
=

--aaron
--089e0158ab8a7886dc04f9e92811-- From nobody Wed May 21 06:45:21 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA551A069D for ; Wed, 21 May 2014 06:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJptdWKzeFqL for ; Wed, 21 May 2014 06:45:09 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93851A06A3 for ; Wed, 21 May 2014 06:45:08 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id r20so2753113wiv.15 for ; Wed, 21 May 2014 06:45:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=27UUWpn7ZP+nhpKOQy8O0hDYdBIV8JmnXFBp0Z9pNCI=; b=lej9F9IWu9nS62cWIR2UW2/eIxVOCVE8iVHfORX6J62feOYBE5vPe/+86iOTWiduct TVBPiHXbxCDrIGJlHTZYk/tlNqV5DI2H8Dq8OQRmrPuzKfn+RSNd97MKSJkLlKiqSEhP kU5yomOxQUPODNlR1eVry0PB4K4LfY/jLqJLbDfPDjzmOt4I/yiLa/U8eaMFnTRJ2xU3 qVjzHa2x1U2ZRK68nowsw1BRzwrg6vYCfFW7vT6EgBOwefpLpYfUXO4eWSzw5GxDFrZi u2F7i/FIWmNPOD0NPbHvJ7Ff8mQ6pJoktmP2QgIFnGoIX9uhHzMSAfiyFWHEni/WboTJ 7R2w== X-Gm-Message-State: ALoCoQmI/7HFPPLp/qP0ENix5X1rzYxucDSW7QiHlQ3S5mukLMtlmMiN0gbNvbgSOSduppzxFQ1F X-Received: by 10.194.242.66 with SMTP id wo2mr43627809wjc.37.1400679906877; Wed, 21 May 2014 06:45:06 -0700 (PDT) Received: from [192.168.0.88] (ARennes-356-1-196-14.w2-13.abo.wanadoo.fr. [2.13.139.14]) by mx.google.com with ESMTPSA id by1sm22645107wjc.26.2014.05.21.06.45.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 May 2014 06:45:05 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_CD99EE2B-48C4-4CE6-B56C-C847EA354F20" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: David Ros In-Reply-To: Date: Wed, 21 May 2014 15:45:02 +0200 Message-Id: <800BC3A3-682D-4C15-A65D-660BA821E0DD@simula.no> References: To: Aaron Falk X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/p1OyenvGMYjEIRha7xRDsrtPyK4 Cc: Michael Welzl , taps@ietf.org Subject: Re: [Taps] First draft of an article for the IETF journal 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, 21 May 2014 13:45:13 -0000 --Apple-Mail=_CD99EE2B-48C4-4CE6-B56C-C847EA354F20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 21 May 2014, at 15:41, Aaron Falk wrote: > On Wed, May 21, 2014 at 5:11 AM, Michael Welzl = wrote: >=20 > My opinion: at first, we should focus on things that can be installed = one-sided, on the sender side only. Yes it's limited, but a number of = things are possible there. E.g., pluggable congestion controls in TCP = have always worked without involving the receiver - but right now, = pluggable congestion control isn't an IETF matter. Happy Eyeballs can be = done without coordinating with a receiver, at least for the case that = we're using well-known ports and the receiver listens on more than one = protocol. >=20 > I've forgotten the details of 'Happy Eyeballs'. Can you provide a = cite? > =20 Hi, http://tools.ietf.org/html/draft-wing-tsvwg-happy-eyeballs-sctp-02 Cheers, David >=20 > But yes, quite quickly one runs into limitations there; anyway, for = divide-and-conquer :-) reasons, I think we want to go with a = sender-side-only-installation assumption for now. >=20 > Seems worth exploring the implications of such an approach where you = have the same app sitting on top of very different APIs (e.g., Berkeley = socket vs TAPS) at either end of the connection. That combined with an = app where either endpoint might be a sender. >=20 > =20 > Though, I'm not sure if we have had enough discussions on this and if = absolutely everyone is on the same page (though, indirectly perhaps, as = our draft charter states that signaling is out of scope, and signaling = would be needed to align both ends). >=20 > yup >=20 > cheers, >=20 > --aaron > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_CD99EE2B-48C4-4CE6-B56C-C847EA354F20 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 21 May 2014, at 15:41, Aaron Falk <falk-ietf@dgftech.com> wrote:

On Wed, May 21, 2014 at 5:11 AM, Michael Welzl <michawe@ifi.uio.no> wrote:

My opinion: at first, we should focus on things that can be installed one-sided, on the sender side only. Yes it's limited, but a number of things are possible there. E.g., pluggable congestion controls in TCP have always worked without involving the receiver - but right now, pluggable congestion control isn't an IETF matter. Happy Eyeballs can be done without coordinating with a receiver, at least for the case that we're using well-known ports and the receiver listens on more than one protocol.

I've forgotten the details of 'Happy Eyeballs'.  Can you provide a cite?
 

Hi,


Cheers,

David



But yes, quite quickly one runs into limitations there; anyway, for divide-and-conquer  :-)   reasons, I think we want to go with a sender-side-only-installation assumption for now.

Seems worth exploring the implications of such an approach where you have the same app sitting on top of very different APIs (e.g., Berkeley socket vs TAPS) at either end of the connection.  That combined with an app where either endpoint might be a sender.

 
Though, I'm not sure if we have had enough discussions on this and if absolutely everyone is on the same page (though, indirectly perhaps, as our draft charter states that signaling is out of scope, and signaling would be needed to align both ends).

yup

cheers,

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

--Apple-Mail=_CD99EE2B-48C4-4CE6-B56C-C847EA354F20-- From nobody Wed May 21 06:46:38 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6621A069D for ; Wed, 21 May 2014 06:46:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4wjvNDNwnzp for ; Wed, 21 May 2014 06:46:32 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5CC11A035E for ; Wed, 21 May 2014 06:46:29 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Wn6qh-0005aA-Nq; Wed, 21 May 2014 15:46:27 +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 1Wn6qg-00071Z-Vg; Wed, 21 May 2014 15:46:27 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_C7437900-C70E-412E-8BDD-F58540AE180C" From: Michael Welzl In-Reply-To: Date: Wed, 21 May 2014 15:46:26 +0200 Message-Id: <86862DD3-5344-4B07-805C-2C3899A28C81@ifi.uio.no> References: To: Aaron Falk X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 5 sum msgs/h 3 total rcpts 16545 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5469CF3739FAE881F20408B1A387B3908F27CA00 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 5390 max/h 16 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/Le64V-mmGkLHWuVHPKinAk6iZvw Cc: taps@ietf.org Subject: Re: [Taps] First draft of an article for the IETF journal 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, 21 May 2014 13:46:34 -0000 --Apple-Mail=_C7437900-C70E-412E-8BDD-F58540AE180C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 21. mai 2014, at 15:41, Aaron Falk wrote: > On Wed, May 21, 2014 at 5:11 AM, Michael Welzl = wrote: >=20 > My opinion: at first, we should focus on things that can be installed = one-sided, on the sender side only. Yes it's limited, but a number of = things are possible there. E.g., pluggable congestion controls in TCP = have always worked without involving the receiver - but right now, = pluggable congestion control isn't an IETF matter. Happy Eyeballs can be = done without coordinating with a receiver, at least for the case that = we're using well-known ports and the receiver listens on more than one = protocol. >=20 > I've forgotten the details of 'Happy Eyeballs'. Can you provide a = cite? e.g. http://www.ipjforum.org/?p=3D378 it's just a term for "try all protocols and see what comes back". When that was last discussed in the IETF, the discussion went nowhere = because - in my opinion - everybody was too focused on the first round = trip. If you assume that you can just use something that comes back = *later*, for any later connection, and cache the information meanwhile, = things get easier. (this idea is actually Joe Touch's, he sent it to me in a private email = exchange, years ago) > But yes, quite quickly one runs into limitations there; anyway, for = divide-and-conquer :-) reasons, I think we want to go with a = sender-side-only-installation assumption for now. >=20 > Seems worth exploring the implications of such an approach where you = have the same app sitting on top of very different APIs (e.g., Berkeley = socket vs TAPS) at either end of the connection. That combined with an = app where either endpoint might be a sender. Yes. Anyway, clearly you run into limitations. Cheers, Michael --Apple-Mail=_C7437900-C70E-412E-8BDD-F58540AE180C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On = Wed, May 21, 2014 at 5:11 AM, Michael Welzl <michawe@ifi.uio.no> wrote:

My opinion: at first, we should focus on things that can be = installed one-sided, on the sender side only. Yes it's limited, but a = number of things are possible there. E.g., pluggable congestion controls = in TCP have always worked without involving the receiver - but right = now, pluggable congestion control isn't an IETF matter. Happy Eyeballs = can be done without coordinating with a receiver, at least for the case = that we're using well-known ports and the receiver listens on more than = one protocol.

I've forgotten the details of 'Happy Eyeballs'. =  Can you provide a = cite?

e.g. http://www.ipjforum.org/?p=3D378=

it's just a term for "try all protocols = and see what comes back".

When that was last = discussed in the IETF, the discussion went nowhere because - in my = opinion - everybody was too focused on the first round trip. If you = assume that you can just use something that comes back *later*, for any = later connection, and cache the information meanwhile, things get = easier.

(this idea is actually Joe Touch's, he = sent it to me in a private email exchange, years = ago)


But yes, quite quickly one runs into = limitations there; anyway, for divide-and-conquer  :-)   = reasons, I think we want to go with a sender-side-only-installation = assumption for now.

Seems worth = exploring the implications of such an approach where you have the same = app sitting on top of very different APIs (e.g., Berkeley socket vs = TAPS) at either end of the connection.  That combined with an app = where either endpoint might be a = sender.

Yes. = Anyway, clearly you run into = limitations.

Cheers,
Michael

<= /div>= --Apple-Mail=_C7437900-C70E-412E-8BDD-F58540AE180C-- From nobody Wed May 21 06:50:23 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7FF1A06AA for ; Wed, 21 May 2014 06:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uy6ajMrmuXDp for ; Wed, 21 May 2014 06:50:17 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id D66321A069D for ; Wed, 21 May 2014 06:50:16 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 91E932B454E; Wed, 21 May 2014 14:50:15 +0100 (BST) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 3A4D12B4044; Wed, 21 May 2014 14:50:13 +0100 (BST) Message-ID: <537CAF15.1090301@erg.abdn.ac.uk> Date: Wed, 21 May 2014 14:50:13 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: David Ros , Aaron Falk References: <800BC3A3-682D-4C15-A65D-660BA821E0DD@simula.no> In-Reply-To: <800BC3A3-682D-4C15-A65D-660BA821E0DD@simula.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/6Kisv9DjMlDm9tEozljkW8GqSeE Cc: Michael Welzl , taps@ietf.org Subject: Re: [Taps] First draft of an article for the IETF journal X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 13:50:21 -0000 Happy eyeballs... The non-reference: http://en.wikipedia.org/wiki/Happy_Eyeballs http://tools.ietf.org/html/rfc6555 Dan Wing and Andrew Yourtchenko. "Happy Eyeballs: Improving User Experiences with IPv6 and SCTP". Internet Protocol Journal, vol.13 n.3. Gorry On 21/05/2014 14:45, David Ros wrote: > > On 21 May 2014, at 15:41, Aaron Falk wrote: > >> On Wed, May 21, 2014 at 5:11 AM, Michael Welzl wrote: >> >> My opinion: at first, we should focus on things that can be installed one-sided, on the sender side only. Yes it's limited, but a number of things are possible there. E.g., pluggable congestion controls in TCP have always worked without involving the receiver - but right now, pluggable congestion control isn't an IETF matter. Happy Eyeballs can be done without coordinating with a receiver, at least for the case that we're using well-known ports and the receiver listens on more than one protocol. >> >> I've forgotten the details of 'Happy Eyeballs'. Can you provide a cite? >> > > Hi, > > http://tools.ietf.org/html/draft-wing-tsvwg-happy-eyeballs-sctp-02 > > Cheers, > > David > > >> >> But yes, quite quickly one runs into limitations there; anyway, for divide-and-conquer :-) reasons, I think we want to go with a sender-side-only-installation assumption for now. >> >> Seems worth exploring the implications of such an approach where you have the same app sitting on top of very different APIs (e.g., Berkeley socket vs TAPS) at either end of the connection. That combined with an app where either endpoint might be a sender. >> >> >> Though, I'm not sure if we have had enough discussions on this and if absolutely everyone is on the same page (though, indirectly perhaps, as our draft charter states that signaling is out of scope, and signaling would be needed to align both ends). >> >> yup >> >> cheers, >> >> --aaron >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Wed May 21 06:52:41 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89541A068F for ; Wed, 21 May 2014 06:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5_4Bu94NBok for ; Wed, 21 May 2014 06:52:31 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE5E1A067C for ; Wed, 21 May 2014 06:52:31 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id E86EA2B456E; Wed, 21 May 2014 14:52:29 +0100 (BST) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id A94E22B4044; Wed, 21 May 2014 14:52:27 +0100 (BST) Message-ID: <537CAF9B.9050402@erg.abdn.ac.uk> Date: Wed, 21 May 2014 14:52:27 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Michael Welzl , Aaron Falk References: <86862DD3-5344-4B07-805C-2C3899A28C81@ifi.uio.no> In-Reply-To: <86862DD3-5344-4B07-805C-2C3899A28C81@ifi.uio.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/05DGH85etF0iIEVqdi6wznuLImc Cc: taps@ietf.org Subject: Re: [Taps] First draft of an article for the IETF journal X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 13:52:38 -0000 On 21/05/2014 14:46, Michael Welzl wrote: > > On 21. mai 2014, at 15:41, Aaron Falk wrote: > >> On Wed, May 21, 2014 at 5:11 AM, Michael Welzl wrote: >> >> My opinion: at first, we should focus on things that can be installed one-sided, on the sender side only. Yes it's limited, but a number of things are possible there. E.g., pluggable congestion controls in TCP have always worked without involving the receiver - but right now, pluggable congestion control isn't an IETF matter. Happy Eyeballs can be done without coordinating with a receiver, at least for the case that we're using well-known ports and the receiver listens on more than one protocol. >> >> I've forgotten the details of 'Happy Eyeballs'. Can you provide a cite? > > e.g. http://www.ipjforum.org/?p=378 > > it's just a term for "try all protocols and see what comes back". > > When that was last discussed in the IETF, the discussion went nowhere because - in my opinion - everybody was too focused on the first round trip. If you assume that you can just use something that comes back *later*, for any later connection, and cache the information meanwhile, things get easier. > > (this idea is actually Joe Touch's, he sent it to me in a private email exchange, years ago) > > >> But yes, quite quickly one runs into limitations there; anyway, for divide-and-conquer :-) reasons, I think we want to go with a sender-side-only-installation assumption for now. >> >> Seems worth exploring the implications of such an approach where you have the same app sitting on top of very different APIs (e.g., Berkeley socket vs TAPS) at either end of the connection. That combined with an app where either endpoint might be a sender. > > Yes. Anyway, clearly you run into limitations. > > Cheers, > Michael > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > I was personally thinking about the sender/receiver having some side-information not communicated in the session, such as a cache as you suggest, or a hint from DNS, or something else. The point being that this wouldn't "tell" you what works, but would help answer what to try. gorry From nobody Wed May 21 08:01:21 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793111A06C3 for ; Wed, 21 May 2014 08:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTHXNF6RjZ0N for ; Wed, 21 May 2014 08:01:16 -0700 (PDT) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [132.250.118.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5A971A047B for ; Wed, 21 May 2014 08:01:15 -0700 (PDT) Received: from macsimus.itd.nrl.navy.mil (macsimus.itd.nrl.navy.mil [132.250.92.151]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id s4LF1BVO017541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 21 May 2014 11:01:12 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Brian Adamson In-Reply-To: <537C8F99.8040308@erg.abdn.ac.uk> Date: Wed, 21 May 2014 11:05:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.1878.2) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: http://mailarchive.ietf.org/arch/msg/taps/teVTTxKvpLOSY9D6A8bul6WLgF4 Cc: Michael Welzl , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 21 May 2014 15:01:20 -0000 I understand the need to keep the initial focus on higher priority parts = that may enjoy more common use. In some cases, depending how TAPS = manifests itself, could there be application-layer =93communication = patterns=94 that are invoked and the underlying system identifies what = mix of multicast (if applicable) and unicast makes sense given system = capabilities, the specified application needs, etc? For example, with = my recent experience with the ZeroMQ PUB/SUB, their APIs do currently = require the application to identify whether the PUB/SUB is done via = unicast or multicast, but I could envision middleware that might make = its own determination based on the underlying network topology and = capabilities. I.e, there would not necessarily be specific = differentiation of unicast versus multicast APIs, but more the general = means for the application to express its data transfer needs =85 cheers, Brian On May 21, 2014, at 7:35 AM, Gorry Fairhurst = wrote: > My thoughts at this moment: >=20 > I'd be keen to see multicast supported in the architecture - but I am = less sure we should initially open work items on multicast APIs and = mechanisms, since this may be a wider set of behaviours and use-styles. = I'd prefer to focus initial specification work on a few things for which = we expect the most common use. >=20 > gorry >=20 > On 21/05/2014 12:25, Michael Welzl wrote: >> Hi, >>=20 >> Are there plans: I think it hasn't really been brought up yet. >> My personal opinion: yes, we should include multicast. >>=20 >> Other opinions? >>=20 >> Cheers, >> Michael >>=20 >>=20 >> On 21. mai 2014, at 12:57, Brian Adamson wrote: >>=20 >>> Hi Michael, >>>=20 >>> Are there plans to also include multicast transport protocols under = the TAPS umbrella? For example, I recently ported our NORM (RFC 5740) = implementation into the ZeroMQ libzmq library to take advantage of API = it provides. However, there's quite a bit of added NORM features that = could be tapped (no pun intended) with additional API primitives beyond = what ZeroMQ currently provides to meet different multicast application = needs. It may be useful to mention if TAPS may address multicast = transport capabilities as well. >>>=20 >>> best regards, >>>=20 >>> Brian >>>=20 >>>=20 >>> On May 21, 2014, at 5:12 AM, Michael Welzl = wrote: >>>=20 >>>> Hi, >>>>=20 >>>> Here's an update of the text, incorporating the many comments I = received. Thanks a lot to all of you who made suggestions! Further = comments are very welcome, of course. >>>>=20 >>>> Cheers, >>>> Michael >>>>=20 >>>>=20 >>>> TAPS BOF >>>>=20 >>>> The protocols SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion = control mechanism offer a large number of services to applications in = addition to the long-standing two services provided by TCP and UDP. For = example, SCTP provides reliable and potentially faster-than-TCP delivery = of data chunks to applications that may be able to accept such chunks = out of order. DCCP provides various forms of congestion control for = applications that need it, but would rather have their packets dropped = than retransmitted, as the latter can lead to delay. LEDBAT provides a = scavenger-like background transfer mode, where LEDBAT traffic does not = get in the way of other transfers that use TCP, for instance. Useful as = these services may be, using them is hard for an application programmer: = not all protocols are available everywhere, hence a fall-back solution = must be implemented. Some protocols provide the same services in = different ways. Layering decisions must be made (e.g. should a protocol > be used natively or over UDP?). Because of these complications, = programmers often resort to either using TCP or implementing their own = customized solution over UDP (e.g., Google with QUIC [1] and Adobe with = RTMFP [2]), and chances of benefiting from other transport protocols are = lost. The intention of the Transport Services (TAPS) initiative is to = identify the services provided by IETF transport protocols and = congestion control mechanisms as well as network requirements of = applications and the APIs they use to communicate. By finding a mapping = between these lists, a potential later WG could define services that a = transport API should offer. Then, it would specify how these transport = services can be implemented using native IETF transports and = encapsulated transports, including the definition of mechanisms to = validate that a transport (or transports) can be supported on a path. >>>>=20 >>>> The TAPS initiative began in August 2013 with a mailing list and an = accompanying web page. We held a "Bar BOF" at IETF-88 in Vancouver, = where it was already clarified that TAPS should be careful to provide = what application programmers really need instead of being too focused on = the Berkeley Sockets API. Accordingly, several Internet-drafts were = written, including use cases and an overview of how higher level APIs = could better be supported by enhanced IETF transport services. By = breaking the dependency of applications on specific protocols, TAPS has = the potential to make the currently rigid transport layer more flexible; = this is schematically shown in Figure 1. In December 2013, a = presentation was given at the IAB Workshop on Internet Technology = Adoption and Transition in Cambridge, UK, explaining how the = evolutionary benefit of TAPS is connected to its best-effort nature. = These activities culminated in a Birds-of-a-Feather (BoF) meeting at = IETF-89. This BoF was designated > "non-WG- > forming" to allow the IETF community to discuss the various angles of = this large problem space without having to spend time on charter = word-smithing. Discussion was indeed lively at this two-hour long = session, with 129 attendees and a debate in which more than 6650 words = were spoken at the microphone. >>>>=20 >>>> There were four presentations at the TAPS BoF: Jon Crowcroft = outlined the potential of this activity, calling it "socket science" and = putting it in relation to security. Then, Martin Sustrik presented how = middleware such as his own ZeroMQ could benefit from transports other = than TCP; notably, the strict reliability of TCP is a poor match for = pub/sub communication. Such middleware layers are increasingly common = and often have enough information about what the user is trying to = achieve to be able to make informed transport choices on their behalf. = As shown in Figure 2, updating middleware offers an easy deployment = path, where applications could exploit some of the benefits of TAPS = without having to be changed (except for re-compiling with a new version = of the middleware). Gorry Fairhurst presented a possible implementation = of TAPS, and Margaret Wasserman presented the API of the Multiple = Interfaces (MIF) Working Group. This API is clearly related, and it = seems obvious that=20 > a TAPS AP > I should be somehow connected to the MIF API. >>>>=20 >>>> predictability, safety, binding mechanisms, layer vs. API. >>>> All presentations were accompanied by active debate; for example, = not everyone agreed with the particular way of providing transport = services that was presented. The major concerns that were raised are: >>>> - Predictability: the flexibility shown in Figure 1 comes at a cost = -- application programmers may need a very predictable behavior, where a = certain way of using an API always leads to the exact same protocol = choice underneath. It was suggested that such decisions should be made = at development time, not at runtime. >>>> - Safety: the importance of testing was stressed; changing the = transport protocol must not break an application. >>>> - Binding mechanisms: going even beyond what TAPS proposes, it was = suggested to support name-based instead of IP-address-based transports, = at least as an option. >>>> - Layer vs. API: several participants stated that TAPS should not = be focusing on an API -- it was said that TAPS should be thought about = in terms of a layer, and we should leave it to OSes that interface with = applications to do the work to build the API and actually produce the = layer that we want with all the information that we want and whatever = APIs are needed. >>>>=20 >>>> There is an ongoing conversation between the TSV ADs who sponsored = the TAPS BOF, APPs and RAI ADs, and interested IAB members about next = steps. The group=92s mailing list, taps@ietf.org, currently has 120 = subscribers, and can be joined at = https://www.ietf.org/mailman/listinfo/taps. The accompanying webpage is = at https://sites.google.com/site/transportprotocolservices. >>>>=20 >>>> Activities of some TAPS participants (Michael Welzl, Gorry = Fairhurst) were part-funded by the European Community under its Seventh = Framework Programme through the Reducing Internet Transport Latency = (RITE) project (ICT-317700). The views expressed are solely those of the = author(s). >>>>=20 >>>>=20 >>>>=20 >>>> Figure 1 caption text: Without TAPS (left), the application is tied = to protocol X. With TAPS (right), the application could benefit from = protocol Y that is supported by ISP B. >>>>=20 >>>> Figure 2 caption text: Before (left) and after (right) applying = TAPS below a non-TAPS-enabled application. Nothing changes in the = application and the middleware API that it uses. >>>>=20 >>>>=20 >>>> References: >>>> [1] = http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf >>>> [2] RFC 7016, "Adobe's Secure Real-Time Media Flow Protocol" >>>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >>=20 From nobody Wed May 21 08:12:47 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4A01A0845 for ; Wed, 21 May 2014 08:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJpbmivZVwWN for ; Wed, 21 May 2014 08:12:41 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3271A085E for ; Wed, 21 May 2014 08:12:40 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id D87622B454E; Wed, 21 May 2014 16:12:38 +0100 (BST) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 4848F2B4044; Wed, 21 May 2014 16:12:36 +0100 (BST) Message-ID: <537CC264.9050302@erg.abdn.ac.uk> Date: Wed, 21 May 2014 16:12:36 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brian Adamson References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/xYMD3eEW3Fd6QtANmTHon_d16Rk Cc: Michael Welzl , taps@ietf.org Subject: Re: [Taps] IETF journal article update X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 15:12:43 -0000 I agree with all this... Gorry On 21/05/2014 16:05, Brian Adamson wrote: > I understand the need to keep the initial focus on higher priority parts that may enjoy more common use. In some cases, depending how TAPS manifests itself, could there be application-layer “communication patterns” that are invoked and the underlying system identifies what mix of multicast (if applicable) and unicast makes sense given system capabilities, the specified application needs, etc? For example, with my recent experience with the ZeroMQ PUB/SUB, their APIs do currently require the application to identify whether the PUB/SUB is done via unicast or multicast, but I could envision middleware that might make its own determination based on the underlying network topology and capabilities. I.e, there would not necessarily be specific differentiation of unicast versus multicast APIs, but more the general means for the application to express its data transfer needs … > > cheers, > > Brian > > > On May 21, 2014, at 7:35 AM, Gorry Fairhurst wrote: > >> My thoughts at this moment: >> >> I'd be keen to see multicast supported in the architecture - but I am less sure we should initially open work items on multicast APIs and mechanisms, since this may be a wider set of behaviours and use-styles. I'd prefer to focus initial specification work on a few things for which we expect the most common use. >> >> gorry >> >> On 21/05/2014 12:25, Michael Welzl wrote: >>> Hi, >>> >>> Are there plans: I think it hasn't really been brought up yet. >>> My personal opinion: yes, we should include multicast. >>> >>> Other opinions? >>> >>> Cheers, >>> Michael >>> >>> >>> On 21. mai 2014, at 12:57, Brian Adamson wrote: >>> >>>> Hi Michael, >>>> >>>> Are there plans to also include multicast transport protocols under the TAPS umbrella? For example, I recently ported our NORM (RFC 5740) implementation into the ZeroMQ libzmq library to take advantage of API it provides. However, there's quite a bit of added NORM features that could be tapped (no pun intended) with additional API primitives beyond what ZeroMQ currently provides to meet different multicast application needs. It may be useful to mention if TAPS may address multicast transport capabilities as well. >>>> >>>> best regards, >>>> >>>> Brian >>>> >>>> >>>> On May 21, 2014, at 5:12 AM, Michael Welzl wrote: >>>> >>>>> Hi, >>>>> >>>>> Here's an update of the text, incorporating the many comments I received. Thanks a lot to all of you who made suggestions! Further comments are very welcome, of course. >>>>> >>>>> Cheers, >>>>> Michael >>>>> >>>>> >>>>> TAPS BOF >>>>> >>>>> The protocols SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion control mechanism offer a large number of services to applications in addition to the long-standing two services provided by TCP and UDP. For example, SCTP provides reliable and potentially faster-than-TCP delivery of data chunks to applications that may be able to accept such chunks out of order. DCCP provides various forms of congestion control for applications that need it, but would rather have their packets dropped than retransmitted, as the latter can lead to delay. LEDBAT provides a scavenger-like background transfer mode, where LEDBAT traffic does not get in the way of other transfers that use TCP, for instance. Useful as these services may be, using them is hard for an application programmer: not all protocols are available everywhere, hence a fall-back solution must be implemented. Some protocols provide the same services in different ways. Layering decisions must be made (e.g. should a protoc ol >> be used natively or over UDP?). Because of these complications, programmers often resort to either using TCP or implementing their own customized solution over UDP (e.g., Google with QUIC [1] and Adobe with RTMFP [2]), and chances of benefiting from other transport protocols are lost. The intention of the Transport Services (TAPS) initiative is to identify the services provided by IETF transport protocols and congestion control mechanisms as well as network requirements of applications and the APIs they use to communicate. By finding a mapping between these lists, a potential later WG could define services that a transport API should offer. Then, it would specify how these transport services can be implemented using native IETF transports and encapsulated transports, including the definition of mechanisms to validate that a transport (or transports) can be supported on a path. >>>>> >>>>> The TAPS initiative began in August 2013 with a mailing list and an accompanying web page. We held a "Bar BOF" at IETF-88 in Vancouver, where it was already clarified that TAPS should be careful to provide what application programmers really need instead of being too focused on the Berkeley Sockets API. Accordingly, several Internet-drafts were written, including use cases and an overview of how higher level APIs could better be supported by enhanced IETF transport services. By breaking the dependency of applications on specific protocols, TAPS has the potential to make the currently rigid transport layer more flexible; this is schematically shown in Figure 1. In December 2013, a presentation was given at the IAB Workshop on Internet Technology Adoption and Transition in Cambridge, UK, explaining how the evolutionary benefit of TAPS is connected to its best-effort nature. These activities culminated in a Birds-of-a-Feather (BoF) meeting at IETF-89. This BoF was designat ed >> "non-WG- >> forming" to allow the IETF community to discuss the various angles of this large problem space without having to spend time on charter word-smithing. Discussion was indeed lively at this two-hour long session, with 129 attendees and a debate in which more than 6650 words were spoken at the microphone. >>>>> >>>>> There were four presentations at the TAPS BoF: Jon Crowcroft outlined the potential of this activity, calling it "socket science" and putting it in relation to security. Then, Martin Sustrik presented how middleware such as his own ZeroMQ could benefit from transports other than TCP; notably, the strict reliability of TCP is a poor match for pub/sub communication. Such middleware layers are increasingly common and often have enough information about what the user is trying to achieve to be able to make informed transport choices on their behalf. As shown in Figure 2, updating middleware offers an easy deployment path, where applications could exploit some of the benefits of TAPS without having to be changed (except for re-compiling with a new version of the middleware). Gorry Fairhurst presented a possible implementation of TAPS, and Margaret Wasserman presented the API of the Multiple Interfaces (MIF) Working Group. This API is clearly related, and it seems obvious tha t >> a TAPS AP >> I should be somehow connected to the MIF API. >>>>> >>>>> predictability, safety, binding mechanisms, layer vs. API. >>>>> All presentations were accompanied by active debate; for example, not everyone agreed with the particular way of providing transport services that was presented. The major concerns that were raised are: >>>>> - Predictability: the flexibility shown in Figure 1 comes at a cost -- application programmers may need a very predictable behavior, where a certain way of using an API always leads to the exact same protocol choice underneath. It was suggested that such decisions should be made at development time, not at runtime. >>>>> - Safety: the importance of testing was stressed; changing the transport protocol must not break an application. >>>>> - Binding mechanisms: going even beyond what TAPS proposes, it was suggested to support name-based instead of IP-address-based transports, at least as an option. >>>>> - Layer vs. API: several participants stated that TAPS should not be focusing on an API -- it was said that TAPS should be thought about in terms of a layer, and we should leave it to OSes that interface with applications to do the work to build the API and actually produce the layer that we want with all the information that we want and whatever APIs are needed. >>>>> >>>>> There is an ongoing conversation between the TSV ADs who sponsored the TAPS BOF, APPs and RAI ADs, and interested IAB members about next steps. The group’s mailing list, taps@ietf.org, currently has 120 subscribers, and can be joined at https://www.ietf.org/mailman/listinfo/taps. The accompanying webpage is at https://sites.google.com/site/transportprotocolservices. >>>>> >>>>> Activities of some TAPS participants (Michael Welzl, Gorry Fairhurst) were part-funded by the European Community under its Seventh Framework Programme through the Reducing Internet Transport Latency (RITE) project (ICT-317700). The views expressed are solely those of the author(s). >>>>> >>>>> >>>>> >>>>> Figure 1 caption text: Without TAPS (left), the application is tied to protocol X. With TAPS (right), the application could benefit from protocol Y that is supported by ISP B. >>>>> >>>>> Figure 2 caption text: Before (left) and after (right) applying TAPS below a non-TAPS-enabled application. Nothing changes in the application and the middleware API that it uses. >>>>> >>>>> >>>>> References: >>>>> [1] http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf >>>>> [2] RFC 7016, "Adobe's Secure Real-Time Media Flow Protocol" >>>>> >>>>> _______________________________________________ >>>>> Taps mailing list >>>>> Taps@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/taps >>>> >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>> > From nobody Wed May 21 08:23:16 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1ED1A0891 for ; Wed, 21 May 2014 08:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.005 X-Spam-Level: X-Spam-Status: No, score=0.005 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] 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 JPBYn4rmFAbK for ; Wed, 21 May 2014 08:23:07 -0700 (PDT) Received: from mail.moloch.sk (chrocht.moloch.sk [62.176.169.44]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC8F81A06D6 for ; Wed, 21 May 2014 08:22:55 -0700 (PDT) Received: from [192.168.0.101] (ip66.bbxnet.sk [91.219.133.66]) by mail.moloch.sk (Postfix) with ESMTPSA id 31087180A6E6; Wed, 21 May 2014 17:22:53 +0200 (CEST) Message-ID: <537CC4CC.50007@250bpm.com> Date: Wed, 21 May 2014 17:22:52 +0200 From: Martin Sustrik User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Brian Adamson , gorry@erg.abdn.ac.uk References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/4TFQ-fkkdcMZpdNyotzEhaAbZtU Cc: Michael Welzl , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 21 May 2014 15:23:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Brian, > I understand the need to keep the initial focus on higher priority > parts that may enjoy more common use. In some cases, depending > how TAPS manifests itself, could there be application-layer > “communication patterns” that are invoked and the underlying > system identifies what mix of multicast (if applicable) and unicast > makes sense given system capabilities, the specified application > needs, etc? I believe this ("communication patterns") is a really hard problem as it encompasses the entire field of distributed computing. Too much of responsibility for a humble working group like this. > For example, with my recent experience with the ZeroMQ PUB/SUB, > their APIs do currently require the application to identify > whether the PUB/SUB is done via unicast or multicast, The difference is only when specifying an endpoint address, right? Other than that, PUB/SUB works conceptually the same for both multicast and unicast. > but I could envision middleware that might make its own > determination based on the underlying network topology and > capabilities. I.e, there would not necessarily be specific > differentiation of unicast versus multicast APIs, but more the > general means for the application to express its data transfer > needs … I've actually touched this topic in my TAPS presentation. The idea was that there is a clean separation of mechanism ("I want to do PUB/SUB") and policy ("I want this communication to happen on top of NORM"). The former is something that programmer specifies as it is integral part of the business logic. The latter is a just a policy that can be set by administrator, figured out automatically by a heuristic etc. Martin Martin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTfMTMAAoJENTpVjxCNN9YmRUH/iXRbqPPycyD+ZAXqwgXr3bT /hh/Ovu8scQ2bpA/Ds2pw+Xuncs1u3DNP8eX+5tasBRGhhuhXK/Yq7LBMWU9FPaa 5zzq/eiuzrS1DendtbTWT9Xbo36oINNXHs2zGrSYtbNJTwuU80nItaUwnsEl08q2 8GOnQNVdeglkY9Bon6aAGbqaZrxgBQsngNfbczWOvkSO662G/4Nzpr7xK3zyZSba Agpi2slCERImo2rmfiudFYxKiaEwuKFG2Ud3YRsOo3G0ju8p/bl1cwLVCRIaq5ev 6/bfc1XJMh+o5FrLXp+4z5mthygvX++z/4RyfDYNxmhxRnXQhDpnE8xtj/oHtus= =1M+M -----END PGP SIGNATURE----- From nobody Wed May 21 15:17:55 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97851A0389 for ; Wed, 21 May 2014 15:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGjsa7pluuYZ for ; Wed, 21 May 2014 15:17:51 -0700 (PDT) Received: from mail4.nrl.navy.mil (mail4.nrl.navy.mil [IPv6:2001:480:20:421::587:27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D73FF1A02C8 for ; Wed, 21 May 2014 15:17:49 -0700 (PDT) Received: from [192.168.1.103] (c-76-21-150-94.hsd1.md.comcast.net [76.21.150.94]) (authenticated bits=0) by mail4.nrl.navy.mil (8.14.5/8.14.5) with ESMTP id s4LMHR7i021036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 May 2014 18:17:28 -0400 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Adamson In-Reply-To: <537CC4CC.50007@250bpm.com> Date: Wed, 21 May 2014 18:17:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> To: Martin Sustrik X-Mailer: Apple Mail (2.1510) X-Scanned-By: MIMEDefang 2.72 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/UdQP6ReDcswCpbe30R_Y9G2uDSA Cc: gorry@erg.abdn.ac.uk, Michael Welzl , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 21 May 2014 22:17:53 -0000 Yes - definitely some need to put some scope limit on the thoughts here. = I wasn't able to make the London BoF as I hoped and still need to = review the presentations from that so I apologize if I'm speaking out of = turn. I just meant to ask about the lack of mention of multicast in = journal article ... I was using the ZeroMQ PUB/SUB pattern as an example. As you point out, = the only difference for multicast/unicast was changing the endpoint = address. It's quite nice that it's that simple and the nice API that = abstracts a useful base set of communication pattern primitives that can = be leveraged for multiple purposes is a big part of what motivated me to = dabble with it. There are some variations of those "patterns" or = different ways the patterns might be instantiated (e.g. using some of = the different protocols or mixes of those that Michael identified in his = writeup) that could be explored and may be relevant to TAPS goals if the = an appropriate scope is identified. I don't think there is an infinite = number of these and there might be some taxonomy supportable by TAPS? = Some examples of what I mean that come to mind include supporting live = media pub/sub, asymmetric communication models (e.g. pub/sub with = multicast pub and unicast subscription handling) and that's just for the = pub/sub pattern. Even if TAPS doesn't encompass all of this, at least = thinking about these sorts of use cases, as I'm sure _you_ have ;-), can = help identify what TAPS does do. Again, I apologize if this is = redundant to discussion already held. I need to do my homework and = catch up on what was discussed in London. cheers, Brian On May 21, 2014, at 11:22 AM, Martin Sustrik wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi Brian, >=20 >> I understand the need to keep the initial focus on higher priority=20 >> parts that may enjoy more common use. In some cases, depending >> how TAPS manifests itself, could there be application-layer=20 >> =93communication patterns=94 that are invoked and the underlying >> system identifies what mix of multicast (if applicable) and unicast >> makes sense given system capabilities, the specified application >> needs, etc? >=20 > I believe this ("communication patterns") is a really hard problem as > it encompasses the entire field of distributed computing. Too much of > responsibility for a humble working group like this. >=20 >> For example, with my recent experience with the ZeroMQ PUB/SUB,=20 >> their APIs do currently require the application to identify >> whether the PUB/SUB is done via unicast or multicast, >=20 > The difference is only when specifying an endpoint address, right? > Other than that, PUB/SUB works conceptually the same for both > multicast and unicast. >=20 >> but I could envision middleware that might make its own >> determination based on the underlying network topology and >> capabilities. I.e, there would not necessarily be specific >> differentiation of unicast versus multicast APIs, but more the >> general means for the application to express its data transfer >> needs =85 >=20 > I've actually touched this topic in my TAPS presentation. The idea was > that there is a clean separation of mechanism ("I want to do PUB/SUB") > and policy ("I want this communication to happen on top of NORM"). >=20 > The former is something that programmer specifies as it is integral > part of the business logic. >=20 > The latter is a just a policy that can be set by administrator, > figured out automatically by a heuristic etc. >=20 > Martin >=20 >=20 >=20 > Martin > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >=20 > iQEcBAEBAgAGBQJTfMTMAAoJENTpVjxCNN9YmRUH/iXRbqPPycyD+ZAXqwgXr3bT > /hh/Ovu8scQ2bpA/Ds2pw+Xuncs1u3DNP8eX+5tasBRGhhuhXK/Yq7LBMWU9FPaa > 5zzq/eiuzrS1DendtbTWT9Xbo36oINNXHs2zGrSYtbNJTwuU80nItaUwnsEl08q2 > 8GOnQNVdeglkY9Bon6aAGbqaZrxgBQsngNfbczWOvkSO662G/4Nzpr7xK3zyZSba > Agpi2slCERImo2rmfiudFYxKiaEwuKFG2Ud3YRsOo3G0ju8p/bl1cwLVCRIaq5ev > 6/bfc1XJMh+o5FrLXp+4z5mthygvX++z/4RyfDYNxmhxRnXQhDpnE8xtj/oHtus=3D > =3D1M+M > -----END PGP SIGNATURE----- From nobody Thu May 22 02:11: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 82EF81A015A for ; Thu, 22 May 2014 02:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCv4vdQkZoZw for ; Thu, 22 May 2014 02:11:43 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D820C1A0060 for ; Thu, 22 May 2014 02:11:42 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WnP2I-0002WI-KJ; Thu, 22 May 2014 11:11:38 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WnP2I-00006t-5l; Thu, 22 May 2014 11:11:38 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Michael Welzl In-Reply-To: Date: Thu, 22 May 2014 11:11:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5D39814A-E1BB-4048-9558-BF17341CE8B3@ifi.uio.no> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> To: Brian Adamson X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 16 sum msgs/h 7 total rcpts 16606 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: 832AAF0FD9AA52F40F0A6EC8C7A24614F403B540 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 5408 max/h 16 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/qONaUC47RlW8aFXfUZX5a6gV0dM Cc: gorry@erg.abdn.ac.uk, Martin Sustrik , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 22 May 2014 09:11:44 -0000 On 22. mai 2014, at 00:17, Brian Adamson wrote: > Yes - definitely some need to put some scope limit on the thoughts = here. I wasn't able to make the London BoF as I hoped and still need to = review the presentations from that so I apologize if I'm speaking out of = turn. I just meant to ask about the lack of mention of multicast in = journal article ... >=20 > I was using the ZeroMQ PUB/SUB pattern as an example. As you point = out, the only difference for multicast/unicast was changing the endpoint = address. It's quite nice that it's that simple and the nice API that = abstracts a useful base set of communication pattern primitives that can = be leveraged for multiple purposes is a big part of what motivated me to = dabble with it. There are some variations of those "patterns" or = different ways the patterns might be instantiated (e.g. using some of = the different protocols or mixes of those that Michael identified in his = writeup) that could be explored and may be relevant to TAPS goals if the = an appropriate scope is identified. I don't think there is an infinite = number of these and there might be some taxonomy supportable by TAPS? = Some examples of what I mean that come to mind include supporting live = media pub/sub, asymmetric communication models (e.g. pub/sub with = multicast pub and unicast subscription handling) and that's just for the = pub/sub pattern. Even if TAPS doesn't encompass all of this, at least = thinking about these sorts of use cases, as I'm sure _you_ have ;-), can = help identify what TAPS does do. Again, I apologize if this is = redundant to discussion already held. I need to do my homework and = catch up on what was discussed in London. Correct me if I'm wrong: you're arguing for having more abstract, = pattern-oriented text rather than just the list of APIs in = draft-hurtig-tsvwg-transport-apis-00 ? What about changing the title of this document to "Transport support for = APIs and Communication Patterns" and adding a section that identifies = how certain communication patterns, not just specific APIs, could = generally be better supported by different transports? Would that be = what you're thinking of? (careful, this is a trap: if your answer is yes, then obviously, my next = suggestion is for you to become a co-author of this draft and offer text = :-) ) Cheers, Michael From nobody Thu May 22 12:35:03 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DDE1A033D for ; Thu, 22 May 2014 12:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.005 X-Spam-Level: X-Spam-Status: No, score=0.005 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] 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 99iTp1qd5OqC for ; Thu, 22 May 2014 12:34:59 -0700 (PDT) Received: from mail.moloch.sk (chrocht.moloch.sk [62.176.169.44]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD34C1A032B for ; Thu, 22 May 2014 12:34:59 -0700 (PDT) Received: from [192.168.0.101] (ip66.bbxnet.sk [91.219.133.66]) by mail.moloch.sk (Postfix) with ESMTPSA id 7D344180A6EC; Thu, 22 May 2014 21:34:56 +0200 (CEST) Message-ID: <537E515F.1080305@250bpm.com> Date: Thu, 22 May 2014 21:34:55 +0200 From: Martin Sustrik User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Brian Adamson References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/0_EB3P3Xuu96Ukdo9HD_Gg10LJ4 Cc: gorry@erg.abdn.ac.uk, Michael Welzl , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 22 May 2014 19:35:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22/05/14 00:17, Brian Adamson wrote: > Yes - definitely some need to put some scope limit on the thoughts > here. I wasn't able to make the London BoF as I hoped and still > need to review the presentations from that so I apologize if I'm > speaking out of turn. I just meant to ask about the lack of > mention of multicast in journal article ... > > I was using the ZeroMQ PUB/SUB pattern as an example. As you > point out, the only difference for multicast/unicast was changing > the endpoint address. It's quite nice that it's that simple and > the nice API that abstracts a useful base set of communication > pattern primitives that can be leveraged for multiple purposes is a > big part of what motivated me to dabble with it. There are some > variations of those "patterns" or different ways the patterns might > be instantiated (e.g. using some of the different protocols or > mixes of those that Michael identified in his writeup) that could > be explored and may be relevant to TAPS goals if the an appropriate > scope is identified. I don't think there is an infinite number of > these and there might be some taxonomy supportable by TAPS? Some > examples of what I mean that come to mind include supporting live > media pub/sub, asymmetric communication models (e.g. pub/sub with > multicast pub and unicast subscription handling) and that's just > for the pub/sub pattern. Even if TAPS doesn't encompass all of > this, at least thinking about these sorts of use cases, as I'm sure > _you_ have ;-), can help identify what TAPS does do. Yes, I've been thinking about the patterns for nearly a decade now. And yes, I believe they should be formalised. I've even tried to write some experimental RFCs. Here's the one for REQ/REP pattern, for example: https://raw.githubusercontent.com/nanomsg/nanomsg/master/rfc/sp-request-reply-01.txt All that being said, I still believe that including such work into TAPS would be a serious case of mission creep. Still, if people are interested in discussing communication patters, I am happy to do so. I am not sure what the appropriate forum would be for that though. AFAIK IETF doesn't even have an area that would fit this "interaction protocols among many nodes" stuff. Martin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTflFfAAoJENTpVjxCNN9YfTMH/RhB8m9X4JPi2ykekLTsGY7m gMzr/4hi9dpWzjrD6m5dgxh3XiKl5heB2RH4nyX6JtH7fgD43a+LMLF3Y6z8KrXF cUmXu+kyhoCOOMS7oIRD8RMWXLQticHKZznNP9FYNH/LRLl2t8zmYJQgMdNGtYz4 sXSDIJz7zjZl2hvOxDatjLpel/R2xUXLhEp3MFwEJDjQsazCyDahXjReoTVPoXKY leAMl+smVgk0HqpZVt+UJ/iDYczmh/VFtwTulw2Ky1x+5rqKl1c2sxIy0VMeUsoU s51yWQLedEDQWGG/pyB8EMnw0UnIL3+Tv6zMWKX7rEfCavEoRLApS/zudyA1vY4= =Fgk+ -----END PGP SIGNATURE----- From nobody Mon May 26 19:51:34 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1F41A0329 for ; Mon, 26 May 2014 19:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXrXyBCKhcno for ; Mon, 26 May 2014 19:51:29 -0700 (PDT) Received: from mail-vc0-f197.google.com (mail-vc0-f197.google.com [209.85.220.197]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A4D1A0322 for ; Mon, 26 May 2014 19:51:29 -0700 (PDT) Received: by mail-vc0-f197.google.com with SMTP id id10so23865862vcb.4 for ; Mon, 26 May 2014 19:51:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=BihMtLBasqMc5WOJeYM1yMyiFRycbVb2EZteW9/vvXA=; b=IEhH4SpwGVjmXiVpP+6GKJH6dmgJnK56o1aqdrJDsKfufGthYZVsimp+A2qBdl5opr uvXv92UifIAkKu6MQ8gNPEc3pzHDNbiI+IC2Cws5Cig/h+e/+BiLa2lgLffhxLBvTtXF r85GRjFuX4GWZ4E2O3Op074U7YQ3pnIEvw4PIpFCP66NhHjI/5Nsh8Cwf8j5Myu54QnJ sJan+QCm57JjSvqqNEd6yoA3skqQ+cuAI7sfErBATs41BuW5vacoPpYUK+UurVsZZqFJ P3U2gyWuzqcgNw358M0j6PAuatUZ20K8E5xFjdYMZ79IKtEo6cKXcgs/H4bo/8GAZqsb y1vg== X-Gm-Message-State: ALoCoQnddIz+bYrR4w8BiK/dzP51mh9BijzY82/2cpyJDOoWf+ACNZEAS3POz28j3/WkRVYoeDnJ X-Received: by 10.220.69.72 with SMTP id y8mr24441126vci.21.1401159085694; Mon, 26 May 2014 19:51:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.84.35 with HTTP; Mon, 26 May 2014 19:51:05 -0700 (PDT) In-Reply-To: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> From: Aaron Falk Date: Mon, 26 May 2014 22:51:05 -0400 Message-ID: To: Michael Welzl Content-Type: multipart/alternative; boundary=047d7b3a925093a58604fa58c50e Archived-At: http://mailarchive.ietf.org/arch/msg/taps/ltfcCsxknTxSNbsiJqqsCgH3r1k Cc: taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 27 May 2014 02:51:32 -0000 --047d7b3a925093a58604fa58c50e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael- Much improved. One nit: the para about open issues starts with a sentence fragment. Thanks! --aaron On Wed, May 21, 2014 at 5:12 AM, Michael Welzl wrote: > Hi, > > Here's an update of the text, incorporating the many comments I received. > Thanks a lot to all of you who made suggestions! Further comments are ver= y > welcome, of course. > > Cheers, > Michael > > > TAPS BOF > > The protocols SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion > control mechanism offer a large number of services to applications in > addition to the long-standing two services provided by TCP and UDP. For > example, SCTP provides reliable and potentially faster-than-TCP delivery = of > data chunks to applications that may be able to accept such chunks out of > order. DCCP provides various forms of congestion control for applications > that need it, but would rather have their packets dropped than > retransmitted, as the latter can lead to delay. LEDBAT provides a > scavenger-like background transfer mode, where LEDBAT traffic does not ge= t > in the way of other transfers that use TCP, for instance. Useful as these > services may be, using them is hard for an application programmer: not al= l > protocols are available everywhere, hence a fall-back solution must be > implemented. Some protocols provide the same services in different ways. > Layering decisions must be made (e.g. should a protocol be used natively = or > over UDP?). Because of these complications, programmers often resort to > either using TCP or implementing their own customized solution over UDP > (e.g., Google with QUIC [1] and Adobe with RTMFP [2]), and chances of > benefiting from other transport protocols are lost. The intention of the > Transport Services (TAPS) initiative is to identify the services provided > by IETF transport protocols and congestion control mechanisms as well as > network requirements of applications and the APIs they use to communicate= . > By finding a mapping between these lists, a potential later WG could defi= ne > services that a transport API should offer. Then, it would specify how > these transport services can be implemented using native IETF transports > and encapsulated transports, including the definition of mechanisms to > validate that a transport (or transports) can be supported on a path. > > The TAPS initiative began in August 2013 with a mailing list and an > accompanying web page. We held a "Bar BOF" at IETF-88 in Vancouver, where > it was already clarified that TAPS should be careful to provide what > application programmers really need instead of being too focused on the > Berkeley Sockets API. Accordingly, several Internet-drafts were written, > including use cases and an overview of how higher level APIs could better > be supported by enhanced IETF transport services. By breaking the > dependency of applications on specific protocols, TAPS has the potential = to > make the currently rigid transport layer more flexible; this is > schematically shown in Figure 1. In December 2013, a presentation was giv= en > at the IAB Workshop on Internet Technology Adoption and Transition in > Cambridge, UK, explaining how the evolutionary benefit of TAPS is connect= ed > to its best-effort nature. These activities culminated in a > Birds-of-a-Feather (BoF) meeting at IETF-89. This BoF was designated > "non-WG-forming" to allow the IETF community to discuss the various angle= s > of this large problem space without having to spend time on charter > word-smithing. Discussion was indeed lively at this two-hour long session= , > with 129 attendees and a debate in which more than 6650 words were spoken > at the microphone. > > There were four presentations at the TAPS BoF: Jon Crowcroft outlined the > potential of this activity, calling it "socket science" and putting it in > relation to security. Then, Martin Sustrik presented how middleware such = as > his own ZeroMQ could benefit from transports other than TCP; notably, the > strict reliability of TCP is a poor match for pub/sub communication. Such > middleware layers are increasingly common and often have enough informati= on > about what the user is trying to achieve to be able to make informed > transport choices on their behalf. As shown in Figure 2, updating > middleware offers an easy deployment path, where applications could explo= it > some of the benefits of TAPS without having to be changed (except for > re-compiling with a new version of the middleware). Gorry Fairhurst > presented a possible implementation of TAPS, and Margaret Wasserman > presented the API of the Multiple Interfaces (MIF) Working Group. This AP= I > is clearly related, and it seems obvious that a TAPS API should be someho= w > connected to the MIF API. > > predictability, safety, binding mechanisms, layer vs. API. > All presentations were accompanied by active debate; for example, not > everyone agreed with the particular way of providing transport services > that was presented. The major concerns that were raised are: > - Predictability: the flexibility shown in Figure 1 comes at a cost -- > application programmers may need a very predictable behavior, where a > certain way of using an API always leads to the exact same protocol choic= e > underneath. It was suggested that such decisions should be made at > development time, not at runtime. > - Safety: the importance of testing was stressed; changing the transport > protocol must not break an application. > - Binding mechanisms: going even beyond what TAPS proposes, it was > suggested to support name-based instead of IP-address-based transports, a= t > least as an option. > - Layer vs. API: several participants stated that TAPS should not be > focusing on an API -- it was said that TAPS should be thought about in > terms of a layer, and we should leave it to OSes that interface with > applications to do the work to build the API and actually produce the lay= er > that we want with all the information that we want and whatever APIs are > needed. > > There is an ongoing conversation between the TSV ADs who sponsored the > TAPS BOF, APPs and RAI ADs, and interested IAB members about next steps. > The group=E2=80=99s mailing list, taps@ietf.org, currently has 120 subscr= ibers, > and can be joined at https://www.ietf.org/mailman/listinfo/taps. The > accompanying webpage is at > https://sites.google.com/site/transportprotocolservices. > > Activities of some TAPS participants (Michael Welzl, Gorry Fairhurst) wer= e > part-funded by the European Community under its Seventh Framework Program= me > through the Reducing Internet Transport Latency (RITE) project > (ICT-317700). The views expressed are solely those of the author(s). > > > > Figure 1 caption text: Without TAPS (left), the application is tied to > protocol X. With TAPS (right), the application could benefit from protoco= l > Y that is supported by ISP B. > > Figure 2 caption text: Before (left) and after (right) applying TAPS belo= w > a non-TAPS-enabled application. Nothing changes in the application and th= e > middleware API that it uses. > > > References: > [1] http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf > [2] RFC 7016, "Adobe's Secure Real-Time Media Flow Protocol" > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > --047d7b3a925093a58604fa58c50e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Michael-

Much improved. =C2=A0One nit: = the para about open issues starts with a sentence fragment.

<= /div>
Thanks!

--aaron


On Wed, May 21, 2014 at 5:12 AM, Michael= Welzl <michawe@ifi.uio.no> wrote:
Hi,

Here's an update of the text, incorporating the many comments I receive= d. Thanks a lot to all of you who made suggestions! Further comments are ve= ry welcome, of course.

Cheers,
Michael


TAPS BOF

The protocols SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion control= mechanism offer a large number of services to applications in addition to = the long-standing two services provided by TCP and UDP. For example, SCTP p= rovides reliable and potentially faster-than-TCP delivery of data chunks to= applications that may be able to accept such chunks out of order. DCCP pro= vides various forms of congestion control for applications that need it, bu= t would rather have their packets dropped than retransmitted, as the latter= can lead to delay. LEDBAT provides a scavenger-like background transfer mo= de, where LEDBAT traffic does not get in the way of other transfers that us= e TCP, for instance. Useful as these services may be, using them is hard fo= r an application programmer: not all protocols are available everywhere, he= nce a fall-back solution must be implemented. Some protocols provide the sa= me services in different ways. Layering decisions must be made (e.g. should= a protocol be used natively or over UDP?). Because of these complications,= programmers often resort to either using TCP or implementing their own cus= tomized solution over UDP (e.g., Google with QUIC [1] and Adobe with RTMFP = [2]), and chances of benefiting from other transport protocols are lost. Th= e intention of the Transport Services (TAPS) initiative is to identify the = services provided by IETF transport protocols and congestion control mechan= isms as well as network requirements of applications and the APIs they use = to communicate. By finding a mapping between these lists, a potential later= WG could define services that a transport API should offer. Then, it would= specify how these transport services can be implemented using native IETF = transports and encapsulated transports, including the definition of mechani= sms to validate that a transport (or transports) can be supported on a path= .

The TAPS initiative began in August 2013 with a mailing list and an accompa= nying web page. We held a "Bar BOF" at IETF-88 in Vancouver, wher= e it was already clarified that TAPS should be careful to provide what appl= ication programmers really need instead of being too focused on the Berkele= y Sockets API. Accordingly, several Internet-drafts were written, including= use cases and an overview of how higher level APIs could better be support= ed by enhanced IETF transport services. By breaking the dependency of appli= cations on specific protocols, TAPS has the potential to make the currently= rigid transport layer more flexible; this is schematically shown in Figure= 1. In December 2013, a presentation was given at the IAB Workshop on Inter= net Technology Adoption and Transition in Cambridge, UK, explaining how the= evolutionary benefit of TAPS is connected to its best-effort nature. These= activities culminated in a Birds-of-a-Feather (BoF) meeting at IETF-89. Th= is BoF was designated "non-WG-forming" to allow the IETF communit= y to discuss the various angles of this large problem space without having = to spend time on charter word-smithing. Discussion was indeed lively at thi= s two-hour long session, with 129 attendees and a debate in which more than= 6650 words were spoken at the microphone.

There were four presentations at the TAPS BoF: Jon Crowcroft outlined the p= otential of this activity, calling it "socket science" and puttin= g it in relation to security. Then, Martin Sustrik presented how middleware= such as his own ZeroMQ could benefit from transports other than TCP; notab= ly, the strict reliability of TCP is a poor match for pub/sub communication= . Such middleware layers are increasingly common and often have enough info= rmation about what the user is trying to achieve to be able to make informe= d transport choices on their behalf. As shown in Figure 2, updating middlew= are offers an easy deployment path, where applications could exploit some o= f the benefits of TAPS without having to be changed (except for re-compilin= g with a new version of the middleware). Gorry Fairhurst presented a possib= le implementation of TAPS, and Margaret Wasserman presented the API of the = Multiple Interfaces (MIF) Working Group. This API is clearly related, and i= t seems obvious that a TAPS API should be somehow connected to the MIF API.=

predictability, safety, binding mechanisms, layer vs. API.
All presentations were accompanied by active debate; for example, not every= one agreed with the particular way of providing transport services that was= presented. The major concerns that were raised are:
- Predictability: the flexibility shown in Figure 1 comes at a cost -- appl= ication programmers may need a very predictable behavior, where a certain w= ay of using an API always leads to the exact same protocol choice underneat= h. It was =C2=A0suggested that such decisions should be made at development= time, not at runtime.
- Safety: the importance of testing was stressed; changing the transport pr= otocol must not break an application.
- Binding mechanisms: going even beyond what TAPS proposes, it was suggeste= d to support name-based instead of IP-address-based transports, at least as= an option.
- Layer vs. API: several participants stated that TAPS should not be focusi= ng on an API -- it was said that TAPS should be thought about in terms of a= layer, and we should leave it to OSes that interface with applications to = do the work to build the API and actually produce the layer that we want wi= th all the information that we want and whatever APIs are needed.

There is an ongoing conversation between the TSV ADs who sponsored the TAPS= BOF, APPs and RAI ADs, and interested IAB members about next steps. The gr= oup=E2=80=99s mailing list, taps@ietf.org<= /a>, currently has 120 subscribers, and can be joined at https://www.ietf.org= /mailman/listinfo/taps. The accompanying webpage is at https= ://sites.google.com/site/transportprotocolservices.

Activities of some TAPS participants (Michael Welzl, Gorry Fairhurst) were = part-funded by the European Community under its Seventh Framework Programme= through the Reducing Internet Transport Latency (RITE) project (ICT-317700= ). The views expressed are solely those of the author(s).



Figure 1 caption text: Without TAPS (left), the application is tied to prot= ocol X. With TAPS (right), the application could benefit from protocol Y th= at is supported by ISP B.

Figure 2 caption text: Before (left) and after (right) applying TAPS below = a non-TAPS-enabled application. Nothing changes in the application and the = middleware API that it uses.


References:
[1] http://www.ietf.org/proceedings/88/slides/slides-= 88-tsvarea-10.pdf
[2] RFC 7016, "Adobe's Secure Real-Time Media Flow Protocol"<= br>
_______________________________________________
Taps mailing list
Taps@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/taps

--047d7b3a925093a58604fa58c50e-- From nobody Mon May 26 19:54: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 417CE1A0337 for ; Mon, 26 May 2014 19:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 6BXGnc4zjpsu for ; Mon, 26 May 2014 19:54:53 -0700 (PDT) Received: from mail-qg0-f69.google.com (mail-qg0-f69.google.com [209.85.192.69]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C47A1A0329 for ; Mon, 26 May 2014 19:54:53 -0700 (PDT) Received: by mail-qg0-f69.google.com with SMTP id f51so21267971qge.4 for ; Mon, 26 May 2014 19:54:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=/QWN3zprOIlTykeNrUWRFqQcQROVxTh5apGhuuAN6XM=; b=fzwB5a4VG4fjHrgoDGAALie+xxgWdoEZqOKxn86j4h1YnGBpI2vfzS8YReZPsSmZmK IzAKdKO4Y6CnT9PFmZpkgFD8md8sOq6pQsbMGV3I/Am4VoBtrDxjXil3Il6VFV+R39a8 8aj0/+sTYl4KYnv+zQZqHGTmNn0+pTVfhxsI8L+zAa2Xc+69YdbTGGhZUXp1sBVeNcug fsFotLEmUqiis4NBXRvVz8XGiLa0h19GvWs0LnFKBTSxCvLzTYvKzoYn2wziUv7pnAg3 mYZLRUZvroga9uEJ/wZ1qzTpexRaY8z+tRw7y0qDXRDEl5cGr7n72YTZINhM9DQepbvC 6CdQ== X-Gm-Message-State: ALoCoQmyQ0DcgUfAUntuZ8HhJQp12nCdtru4YWDJ4+J5DkiZipdgrJDosw/tJUsPiHYJMylvngQR X-Received: by 10.220.98.143 with SMTP id q15mr10668392vcn.38.1401159289628; Mon, 26 May 2014 19:54:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.84.35 with HTTP; Mon, 26 May 2014 19:54:29 -0700 (PDT) In-Reply-To: <5D39814A-E1BB-4048-9558-BF17341CE8B3@ifi.uio.no> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <5D39814A-E1BB-4048-9558-BF17341CE8B3@ifi.uio.no> From: Aaron Falk Date: Mon, 26 May 2014 22:54:29 -0400 Message-ID: To: Michael Welzl Content-Type: multipart/alternative; boundary=001a11c1da06bb7eaa04fa58d1cd Archived-At: http://mailarchive.ietf.org/arch/msg/taps/JTUN5sv1Alw4jcCp-BlQa1zoOB8 Cc: gorry@erg.abdn.ac.uk, taps@ietf.org, Martin Sustrik , Brian Adamson Subject: Re: [Taps] IETF journal article update 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, 27 May 2014 02:54:54 -0000 --001a11c1da06bb7eaa04fa58d1cd Content-Type: text/plain; charset=UTF-8 On Thu, May 22, 2014 at 5:11 AM, Michael Welzl wrote: > > What about changing the title of this document to "Transport support for > APIs and Communication Patterns" and adding a section that identifies how > certain communication patterns, not just specific APIs, could generally be > better supported by different transports? Would that be what you're > thinking of? > > (careful, this is a trap: if your answer is yes, then obviously, my next > suggestion is for you to become a co-author of this draft and offer text > :-) ) > > Yikes, this seems like pretty significant scope creep and an attractive topic for discussion and debate, a bad combination for working group chartering. :-/ Nevertheless, I agree it is interesting and relevant. Maybe it would be worthwhile to have a draft proposing how communication patterns could be included in an API framework to see if there's rapid consensus? I would love to be pleasantly surprised... --aaron --001a11c1da06bb7eaa04fa58d1cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, May 22, 2014 at 5:11 AM, Michael Welzl <michawe@ifi.uio.no> wrote:

What about changing the title of this document to "Transport support f= or APIs and Communication Patterns" and adding a section that identifi= es how certain communication patterns, not just specific APIs, could genera= lly be better supported by different transports? Would that be what you'= ;re thinking of?

(careful, this is a trap: if your answer is yes, then obviously, my next su= ggestion is for you to become a co-author of this draft and offer text =C2= =A0:-) =C2=A0 )


Yikes, this seems like pretty signific= ant scope creep and an attractive topic for discussion and debate, a bad co= mbination for working group chartering. =C2=A0:-/ =C2=A0Nevertheless, I agr= ee it is interesting and relevant. =C2=A0Maybe it would be worthwhile to ha= ve a draft proposing how communication patterns could be included in an API= framework to see if there's rapid consensus? =C2=A0I would love to be = pleasantly surprised...

--aaron=C2=A0
--001a11c1da06bb7eaa04fa58d1cd-- From nobody Mon May 26 23:44:50 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 3C8721A03A0 for ; Mon, 26 May 2014 23:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qT5fPOx2IUGo for ; Mon, 26 May 2014 23:44:44 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5909C1A03A1 for ; Mon, 26 May 2014 23:44:43 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WpB7m-0007Ev-FO; Tue, 27 May 2014 08:44:38 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WpB7l-0004Ib-HP; Tue, 27 May 2014 08:44:38 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_2331FDE7-09F1-4EBF-82AB-0BDE168AD6DA" From: Michael Welzl In-Reply-To: Date: Tue, 27 May 2014 08:44:36 +0200 Message-Id: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> To: Aaron Falk X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 2 sum msgs/h 1 total rcpts 16790 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-6.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: EE1A8BCC09CE4B394376A89C91471875672770B3 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -59 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 5483 max/h 16 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/BuJpIZVt1M1-GWNNDvPXapVdIMI Cc: taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 27 May 2014 06:44:48 -0000 --Apple-Mail=_2331FDE7-09F1-4EBF-82AB-0BDE168AD6DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, Thanks a lot! I sent it on yesterday, but luckily discovered exactly = that one mistake too as I did so. Thanks again for your inputs!! Michael On 27. mai 2014, at 04:51, Aaron Falk wrote: > Michael- >=20 > Much improved. One nit: the para about open issues starts with a = sentence fragment. >=20 > Thanks! >=20 > --aaron >=20 >=20 > On Wed, May 21, 2014 at 5:12 AM, Michael Welzl = wrote: > Hi, >=20 > Here's an update of the text, incorporating the many comments I = received. Thanks a lot to all of you who made suggestions! Further = comments are very welcome, of course. >=20 > Cheers, > Michael >=20 >=20 > TAPS BOF >=20 > The protocols SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion = control mechanism offer a large number of services to applications in = addition to the long-standing two services provided by TCP and UDP. For = example, SCTP provides reliable and potentially faster-than-TCP delivery = of data chunks to applications that may be able to accept such chunks = out of order. DCCP provides various forms of congestion control for = applications that need it, but would rather have their packets dropped = than retransmitted, as the latter can lead to delay. LEDBAT provides a = scavenger-like background transfer mode, where LEDBAT traffic does not = get in the way of other transfers that use TCP, for instance. Useful as = these services may be, using them is hard for an application programmer: = not all protocols are available everywhere, hence a fall-back solution = must be implemented. Some protocols provide the same services in = different ways. Layering decisions must be made (e.g. should a protocol = be used natively or over UDP?). Because of these complications, = programmers often resort to either using TCP or implementing their own = customized solution over UDP (e.g., Google with QUIC [1] and Adobe with = RTMFP [2]), and chances of benefiting from other transport protocols are = lost. The intention of the Transport Services (TAPS) initiative is to = identify the services provided by IETF transport protocols and = congestion control mechanisms as well as network requirements of = applications and the APIs they use to communicate. By finding a mapping = between these lists, a potential later WG could define services that a = transport API should offer. Then, it would specify how these transport = services can be implemented using native IETF transports and = encapsulated transports, including the definition of mechanisms to = validate that a transport (or transports) can be supported on a path. >=20 > The TAPS initiative began in August 2013 with a mailing list and an = accompanying web page. We held a "Bar BOF" at IETF-88 in Vancouver, = where it was already clarified that TAPS should be careful to provide = what application programmers really need instead of being too focused on = the Berkeley Sockets API. Accordingly, several Internet-drafts were = written, including use cases and an overview of how higher level APIs = could better be supported by enhanced IETF transport services. By = breaking the dependency of applications on specific protocols, TAPS has = the potential to make the currently rigid transport layer more flexible; = this is schematically shown in Figure 1. In December 2013, a = presentation was given at the IAB Workshop on Internet Technology = Adoption and Transition in Cambridge, UK, explaining how the = evolutionary benefit of TAPS is connected to its best-effort nature. = These activities culminated in a Birds-of-a-Feather (BoF) meeting at = IETF-89. This BoF was designated "non-WG-forming" to allow the IETF = community to discuss the various angles of this large problem space = without having to spend time on charter word-smithing. Discussion was = indeed lively at this two-hour long session, with 129 attendees and a = debate in which more than 6650 words were spoken at the microphone. >=20 > There were four presentations at the TAPS BoF: Jon Crowcroft outlined = the potential of this activity, calling it "socket science" and putting = it in relation to security. Then, Martin Sustrik presented how = middleware such as his own ZeroMQ could benefit from transports other = than TCP; notably, the strict reliability of TCP is a poor match for = pub/sub communication. Such middleware layers are increasingly common = and often have enough information about what the user is trying to = achieve to be able to make informed transport choices on their behalf. = As shown in Figure 2, updating middleware offers an easy deployment = path, where applications could exploit some of the benefits of TAPS = without having to be changed (except for re-compiling with a new version = of the middleware). Gorry Fairhurst presented a possible implementation = of TAPS, and Margaret Wasserman presented the API of the Multiple = Interfaces (MIF) Working Group. This API is clearly related, and it = seems obvious that a TAPS API should be somehow connected to the MIF = API. >=20 > predictability, safety, binding mechanisms, layer vs. API. > All presentations were accompanied by active debate; for example, not = everyone agreed with the particular way of providing transport services = that was presented. The major concerns that were raised are: > - Predictability: the flexibility shown in Figure 1 comes at a cost -- = application programmers may need a very predictable behavior, where a = certain way of using an API always leads to the exact same protocol = choice underneath. It was suggested that such decisions should be made = at development time, not at runtime. > - Safety: the importance of testing was stressed; changing the = transport protocol must not break an application. > - Binding mechanisms: going even beyond what TAPS proposes, it was = suggested to support name-based instead of IP-address-based transports, = at least as an option. > - Layer vs. API: several participants stated that TAPS should not be = focusing on an API -- it was said that TAPS should be thought about in = terms of a layer, and we should leave it to OSes that interface with = applications to do the work to build the API and actually produce the = layer that we want with all the information that we want and whatever = APIs are needed. >=20 > There is an ongoing conversation between the TSV ADs who sponsored the = TAPS BOF, APPs and RAI ADs, and interested IAB members about next steps. = The group=92s mailing list, taps@ietf.org, currently has 120 = subscribers, and can be joined at = https://www.ietf.org/mailman/listinfo/taps. The accompanying webpage is = at https://sites.google.com/site/transportprotocolservices. >=20 > Activities of some TAPS participants (Michael Welzl, Gorry Fairhurst) = were part-funded by the European Community under its Seventh Framework = Programme through the Reducing Internet Transport Latency (RITE) project = (ICT-317700). The views expressed are solely those of the author(s). >=20 >=20 >=20 > Figure 1 caption text: Without TAPS (left), the application is tied to = protocol X. With TAPS (right), the application could benefit from = protocol Y that is supported by ISP B. >=20 > Figure 2 caption text: Before (left) and after (right) applying TAPS = below a non-TAPS-enabled application. Nothing changes in the application = and the middleware API that it uses. >=20 >=20 > References: > [1] http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf > [2] RFC 7016, "Adobe's Secure Real-Time Media Flow Protocol" >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps >=20 --Apple-Mail=_2331FDE7-09F1-4EBF-82AB-0BDE168AD6DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Michael-

Much improved.  One nit: = the para about open issues starts with a sentence = fragment.

Thanks!

--aaro= n


On Wed, May 21, 2014 at 5:12 AM, = Michael Welzl <michawe@ifi.uio.no> = wrote:
Hi,

Here's an update of the text, incorporating the many comments I = received. Thanks a lot to all of you who made suggestions! Further = comments are very welcome, of course.

Cheers,
Michael


TAPS BOF

The protocols SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion = control mechanism offer a large number of services to applications in = addition to the long-standing two services provided by TCP and UDP. For = example, SCTP provides reliable and potentially faster-than-TCP delivery = of data chunks to applications that may be able to accept such chunks = out of order. DCCP provides various forms of congestion control for = applications that need it, but would rather have their packets dropped = than retransmitted, as the latter can lead to delay. LEDBAT provides a = scavenger-like background transfer mode, where LEDBAT traffic does not = get in the way of other transfers that use TCP, for instance. Useful as = these services may be, using them is hard for an application programmer: = not all protocols are available everywhere, hence a fall-back solution = must be implemented. Some protocols provide the same services in = different ways. Layering decisions must be made (e.g. should a protocol = be used natively or over UDP?). Because of these complications, = programmers often resort to either using TCP or implementing their own = customized solution over UDP (e.g., Google with QUIC [1] and Adobe with = RTMFP [2]), and chances of benefiting from other transport protocols are = lost. The intention of the Transport Services (TAPS) initiative is to = identify the services provided by IETF transport protocols and = congestion control mechanisms as well as network requirements of = applications and the APIs they use to communicate. By finding a mapping = between these lists, a potential later WG could define services that a = transport API should offer. Then, it would specify how these transport = services can be implemented using native IETF transports and = encapsulated transports, including the definition of mechanisms to = validate that a transport (or transports) can be supported on a = path.

The TAPS initiative began in August 2013 with a mailing list and an = accompanying web page. We held a "Bar BOF" at IETF-88 in Vancouver, = where it was already clarified that TAPS should be careful to provide = what application programmers really need instead of being too focused on = the Berkeley Sockets API. Accordingly, several Internet-drafts were = written, including use cases and an overview of how higher level APIs = could better be supported by enhanced IETF transport services. By = breaking the dependency of applications on specific protocols, TAPS has = the potential to make the currently rigid transport layer more flexible; = this is schematically shown in Figure 1. In December 2013, a = presentation was given at the IAB Workshop on Internet Technology = Adoption and Transition in Cambridge, UK, explaining how the = evolutionary benefit of TAPS is connected to its best-effort nature. = These activities culminated in a Birds-of-a-Feather (BoF) meeting at = IETF-89. This BoF was designated "non-WG-forming" to allow the IETF = community to discuss the various angles of this large problem space = without having to spend time on charter word-smithing. Discussion was = indeed lively at this two-hour long session, with 129 attendees and a = debate in which more than 6650 words were spoken at the microphone.

There were four presentations at the TAPS BoF: Jon Crowcroft outlined = the potential of this activity, calling it "socket science" and putting = it in relation to security. Then, Martin Sustrik presented how = middleware such as his own ZeroMQ could benefit from transports other = than TCP; notably, the strict reliability of TCP is a poor match for = pub/sub communication. Such middleware layers are increasingly common = and often have enough information about what the user is trying to = achieve to be able to make informed transport choices on their behalf. = As shown in Figure 2, updating middleware offers an easy deployment = path, where applications could exploit some of the benefits of TAPS = without having to be changed (except for re-compiling with a new version = of the middleware). Gorry Fairhurst presented a possible implementation = of TAPS, and Margaret Wasserman presented the API of the Multiple = Interfaces (MIF) Working Group. This API is clearly related, and it = seems obvious that a TAPS API should be somehow connected to the MIF = API.

predictability, safety, binding mechanisms, layer vs. API.
All presentations were accompanied by active debate; for example, not = everyone agreed with the particular way of providing transport services = that was presented. The major concerns that were raised are:
- Predictability: the flexibility shown in Figure 1 comes at a cost -- = application programmers may need a very predictable behavior, where a = certain way of using an API always leads to the exact same protocol = choice underneath. It was  suggested that such decisions should be = made at development time, not at runtime.
- Safety: the importance of testing was stressed; changing the transport = protocol must not break an application.
- Binding mechanisms: going even beyond what TAPS proposes, it was = suggested to support name-based instead of IP-address-based transports, = at least as an option.
- Layer vs. API: several participants stated that TAPS should not be = focusing on an API -- it was said that TAPS should be thought about in = terms of a layer, and we should leave it to OSes that interface with = applications to do the work to build the API and actually produce the = layer that we want with all the information that we want and whatever = APIs are needed.

There is an ongoing conversation between the TSV ADs who sponsored the = TAPS BOF, APPs and RAI ADs, and interested IAB members about next steps. = The group=92s mailing list, taps@ietf.org, currently has 120 = subscribers, and can be joined at https://www.ietf.org/mailman/listinfo/taps. The = accompanying webpage is at https://sites.google.com/site/transportprotocolservices<= /a>.

Activities of some TAPS participants (Michael Welzl, Gorry Fairhurst) = were part-funded by the European Community under its Seventh Framework = Programme through the Reducing Internet Transport Latency (RITE) project = (ICT-317700). The views expressed are solely those of the author(s).



Figure 1 caption text: Without TAPS (left), the application is tied to = protocol X. With TAPS (right), the application could benefit from = protocol Y that is supported by ISP B.

Figure 2 caption text: Before (left) and after (right) applying TAPS = below a non-TAPS-enabled application. Nothing changes in the application = and the middleware API that it uses.


References:
[1] http://www.ietf.org/proceedings/88/slides/slides-88-tsva= rea-10.pdf
[2] RFC 7016, "Adobe's Secure Real-Time Media Flow Protocol"

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


= --Apple-Mail=_2331FDE7-09F1-4EBF-82AB-0BDE168AD6DA-- From nobody Mon May 26 23:49:43 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 5446D1A03A0 for ; Mon, 26 May 2014 23:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkXGCCaCLmjv for ; Mon, 26 May 2014 23:49:37 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5BA1A0392 for ; Mon, 26 May 2014 23:49:37 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id AFCF92B4258; Tue, 27 May 2014 07:49:33 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Tue, 27 May 2014 07:49:33 +0100 Message-ID: In-Reply-To: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> Date: Tue, 27 May 2014 07:49:33 +0100 From: gorry@erg.abdn.ac.uk To: "Aaron Falk" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/taps/i95XwE3fz_kd7MiXE1sAMqcV1eI Cc: Michael Welzl , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 27 May 2014 06:49:41 -0000 Yes, I agree - this looks good to me, Gorry > Michael- > > Much improved. One nit: the para about open issues starts with a sentence > fragment. > > Thanks! > > --aaron > > > On Wed, May 21, 2014 at 5:12 AM, Michael Welzl wrote: > >> Hi, >> >> Here's an update of the text, incorporating the many comments I >> received. >> Thanks a lot to all of you who made suggestions! Further comments are >> very >> welcome, of course. >> >> Cheers, >> Michael >> >> >> TAPS BOF >> >> The protocols SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion >> control mechanism offer a large number of services to applications in >> addition to the long-standing two services provided by TCP and UDP. For >> example, SCTP provides reliable and potentially faster-than-TCP delivery >> of >> data chunks to applications that may be able to accept such chunks out >> of >> order. DCCP provides various forms of congestion control for >> applications >> that need it, but would rather have their packets dropped than >> retransmitted, as the latter can lead to delay. LEDBAT provides a >> scavenger-like background transfer mode, where LEDBAT traffic does not >> get >> in the way of other transfers that use TCP, for instance. Useful as >> these >> services may be, using them is hard for an application programmer: not >> all >> protocols are available everywhere, hence a fall-back solution must be >> implemented. Some protocols provide the same services in different ways. >> Layering decisions must be made (e.g. should a protocol be used natively >> or >> over UDP?). Because of these complications, programmers often resort to >> either using TCP or implementing their own customized solution over UDP >> (e.g., Google with QUIC [1] and Adobe with RTMFP [2]), and chances of >> benefiting from other transport protocols are lost. The intention of the >> Transport Services (TAPS) initiative is to identify the services >> provided >> by IETF transport protocols and congestion control mechanisms as well as >> network requirements of applications and the APIs they use to >> communicate. >> By finding a mapping between these lists, a potential later WG could >> define >> services that a transport API should offer. Then, it would specify how >> these transport services can be implemented using native IETF transports >> and encapsulated transports, including the definition of mechanisms to >> validate that a transport (or transports) can be supported on a path. >> >> The TAPS initiative began in August 2013 with a mailing list and an >> accompanying web page. We held a "Bar BOF" at IETF-88 in Vancouver, >> where >> it was already clarified that TAPS should be careful to provide what >> application programmers really need instead of being too focused on the >> Berkeley Sockets API. Accordingly, several Internet-drafts were written, >> including use cases and an overview of how higher level APIs could >> better >> be supported by enhanced IETF transport services. By breaking the >> dependency of applications on specific protocols, TAPS has the potential >> to >> make the currently rigid transport layer more flexible; this is >> schematically shown in Figure 1. In December 2013, a presentation was >> given >> at the IAB Workshop on Internet Technology Adoption and Transition in >> Cambridge, UK, explaining how the evolutionary benefit of TAPS is >> connected >> to its best-effort nature. These activities culminated in a >> Birds-of-a-Feather (BoF) meeting at IETF-89. This BoF was designated >> "non-WG-forming" to allow the IETF community to discuss the various >> angles >> of this large problem space without having to spend time on charter >> word-smithing. Discussion was indeed lively at this two-hour long >> session, >> with 129 attendees and a debate in which more than 6650 words were >> spoken >> at the microphone. >> >> There were four presentations at the TAPS BoF: Jon Crowcroft outlined >> the >> potential of this activity, calling it "socket science" and putting it >> in >> relation to security. Then, Martin Sustrik presented how middleware such >> as >> his own ZeroMQ could benefit from transports other than TCP; notably, >> the >> strict reliability of TCP is a poor match for pub/sub communication. >> Such >> middleware layers are increasingly common and often have enough >> information >> about what the user is trying to achieve to be able to make informed >> transport choices on their behalf. As shown in Figure 2, updating >> middleware offers an easy deployment path, where applications could >> exploit >> some of the benefits of TAPS without having to be changed (except for >> re-compiling with a new version of the middleware). Gorry Fairhurst >> presented a possible implementation of TAPS, and Margaret Wasserman >> presented the API of the Multiple Interfaces (MIF) Working Group. This >> API >> is clearly related, and it seems obvious that a TAPS API should be >> somehow >> connected to the MIF API. >> >> predictability, safety, binding mechanisms, layer vs. API. >> All presentations were accompanied by active debate; for example, not >> everyone agreed with the particular way of providing transport services >> that was presented. The major concerns that were raised are: >> - Predictability: the flexibility shown in Figure 1 comes at a cost -- >> application programmers may need a very predictable behavior, where a >> certain way of using an API always leads to the exact same protocol >> choice >> underneath. It was suggested that such decisions should be made at >> development time, not at runtime. >> - Safety: the importance of testing was stressed; changing the transport >> protocol must not break an application. >> - Binding mechanisms: going even beyond what TAPS proposes, it was >> suggested to support name-based instead of IP-address-based transports, >> at >> least as an option. >> - Layer vs. API: several participants stated that TAPS should not be >> focusing on an API -- it was said that TAPS should be thought about in >> terms of a layer, and we should leave it to OSes that interface with >> applications to do the work to build the API and actually produce the >> layer >> that we want with all the information that we want and whatever APIs are >> needed. >> >> There is an ongoing conversation between the TSV ADs who sponsored the >> TAPS BOF, APPs and RAI ADs, and interested IAB members about next steps. >> The group’s mailing list, taps@ietf.org, currently has 120 >> subscribers, >> and can be joined at https://www.ietf.org/mailman/listinfo/taps. The >> accompanying webpage is at >> https://sites.google.com/site/transportprotocolservices. >> >> Activities of some TAPS participants (Michael Welzl, Gorry Fairhurst) >> were >> part-funded by the European Community under its Seventh Framework >> Programme >> through the Reducing Internet Transport Latency (RITE) project >> (ICT-317700). The views expressed are solely those of the author(s). >> >> >> >> Figure 1 caption text: Without TAPS (left), the application is tied to >> protocol X. With TAPS (right), the application could benefit from >> protocol >> Y that is supported by ISP B. >> >> Figure 2 caption text: Before (left) and after (right) applying TAPS >> below >> a non-TAPS-enabled application. Nothing changes in the application and >> the >> middleware API that it uses. >> >> >> References: >> [1] http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf >> [2] RFC 7016, "Adobe's Secure Real-Time Media Flow Protocol" >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >> > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Tue May 27 00:33:03 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0BFA1A01D2 for ; Tue, 27 May 2014 00:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 oAFqtWUmbuw2 for ; Tue, 27 May 2014 00:33:00 -0700 (PDT) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD0801A000B for ; Tue, 27 May 2014 00:32:59 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id i8so13728201qcq.1 for ; Tue, 27 May 2014 00:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cu5RzFjE09Xw36pw4LXCiogBOSwnz+e2fCjNKWBLR5w=; b=LcA3f7cVKjvSO4OD5EFYQDLptuwHnIdGco6RtEXdz77+O1Qe1S9jNaHdvx+5hJOPsV 3XCqWfkrtJkHm2G4/l4IqJe9AnH12/N9D+AnBYOyjhQrUh5dZfpSZFjYLr/anva8E1xj nKwDicvczBphIlVTipPGWchTgbRpbLP6o7Edm0sVt/sI4OM02F8Or0nnixC5YDngKK11 CNoir5ReJKbGh7HRP8P40WVamJuGb46ArVK4z3YcFcf0KF8D0DWSg06gs77o3VGYQT67 L40iH8CvVj7V9JgpxBBGP9MtdNTW0OCnuGRs4ZO55HXgxu0Y5RDXZW0tbTQp23QqNLPj 8ZMA== MIME-Version: 1.0 X-Received: by 10.140.37.135 with SMTP id r7mr37272078qgr.61.1401175976301; Tue, 27 May 2014 00:32:56 -0700 (PDT) Sender: crowcroft@gmail.com Received: by 10.140.48.14 with HTTP; Tue, 27 May 2014 00:32:56 -0700 (PDT) In-Reply-To: <537E515F.1080305@250bpm.com> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> Date: Tue, 27 May 2014 08:32:56 +0100 X-Google-Sender-Auth: UGZW9NgT4_sMzn02IgImjqsnSS8 Message-ID: From: Jon Crowcroft To: Martin Sustrik Content-Type: multipart/alternative; boundary=001a11c146d055dac404fa5cb4a5 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/22iveo5yf-eWLAeqgCzoDP7NrkI Cc: Gorry Fairhurst , taps@ietf.org, Michael Welzl , Brian Adamson Subject: Re: [Taps] IETF journal article update 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, 27 May 2014 07:33:02 -0000 --001a11c146d055dac404fa5cb4a5 Content-Type: text/plain; charset=UTF-8 totally agree - I think generalized pattern approach is really nice, and we tried using it in the "building blocks" structure that was used in the RMT group - i think quite successfully however, patterns (and RMT consierations too) are over-reach for TAPS, in my opinion....life's too short to get something done that new, big, and complex (and contentious in some quarters) On Thu, May 22, 2014 at 8:34 PM, Martin Sustrik wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 22/05/14 00:17, Brian Adamson wrote: > > Yes - definitely some need to put some scope limit on the thoughts > > here. I wasn't able to make the London BoF as I hoped and still > > need to review the presentations from that so I apologize if I'm > > speaking out of turn. I just meant to ask about the lack of > > mention of multicast in journal article ... > > > > I was using the ZeroMQ PUB/SUB pattern as an example. As you > > point out, the only difference for multicast/unicast was changing > > the endpoint address. It's quite nice that it's that simple and > > the nice API that abstracts a useful base set of communication > > pattern primitives that can be leveraged for multiple purposes is a > > big part of what motivated me to dabble with it. There are some > > variations of those "patterns" or different ways the patterns might > > be instantiated (e.g. using some of the different protocols or > > mixes of those that Michael identified in his writeup) that could > > be explored and may be relevant to TAPS goals if the an appropriate > > scope is identified. I don't think there is an infinite number of > > these and there might be some taxonomy supportable by TAPS? Some > > examples of what I mean that come to mind include supporting live > > media pub/sub, asymmetric communication models (e.g. pub/sub with > > multicast pub and unicast subscription handling) and that's just > > for the pub/sub pattern. Even if TAPS doesn't encompass all of > > this, at least thinking about these sorts of use cases, as I'm sure > > _you_ have ;-), can help identify what TAPS does do. > > Yes, I've been thinking about the patterns for nearly a decade now. > And yes, I believe they should be formalised. I've even tried to write > some experimental RFCs. Here's the one for REQ/REP pattern, for example: > > > https://raw.githubusercontent.com/nanomsg/nanomsg/master/rfc/sp-request-reply-01.txt > > All that being said, I still believe that including such work into > TAPS would be a serious case of mission creep. > > Still, if people are interested in discussing communication patters, I > am happy to do so. I am not sure what the appropriate forum would be > for that though. AFAIK IETF doesn't even have an area that would fit > this "interaction protocols among many nodes" stuff. > > Martin > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJTflFfAAoJENTpVjxCNN9YfTMH/RhB8m9X4JPi2ykekLTsGY7m > gMzr/4hi9dpWzjrD6m5dgxh3XiKl5heB2RH4nyX6JtH7fgD43a+LMLF3Y6z8KrXF > cUmXu+kyhoCOOMS7oIRD8RMWXLQticHKZznNP9FYNH/LRLl2t8zmYJQgMdNGtYz4 > sXSDIJz7zjZl2hvOxDatjLpel/R2xUXLhEp3MFwEJDjQsazCyDahXjReoTVPoXKY > leAMl+smVgk0HqpZVt+UJ/iDYczmh/VFtwTulw2Ky1x+5rqKl1c2sxIy0VMeUsoU > s51yWQLedEDQWGG/pyB8EMnw0UnIL3+Tv6zMWKX7rEfCavEoRLApS/zudyA1vY4= > =Fgk+ > -----END PGP SIGNATURE----- > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > --001a11c146d055dac404fa5cb4a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
totally agree - I think generalized pattern approach is re= ally nice, and we tried using it in the "building blocks" structu= re that was used in the RMT group - i think quite successfully

however, patterns (and RMT consierations too) are over-reach for TAPS,= in my opinion....life's too short to get something done that new, big,= and complex (and contentious in some quarters)


On Thu, May 22, 2014 at 8:34 PM, Martin = Sustrik <sustrik@250bpm.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22/05/14 00:17, Brian Adamson wrote:
> Yes - definitely some need to put some scope limit on the thoughts
> here. =C2=A0I wasn't able to make the London BoF as I hoped and st= ill
> need to review the presentations from that so I apologize if I'm > speaking out of turn. =C2=A0I just meant to ask about the lack of
> mention of multicast in journal article ...
>
> I was using the ZeroMQ PUB/SUB pattern as an example. =C2=A0As you
> point out, the only difference for multicast/unicast was changing
> the endpoint address. =C2=A0It's quite nice that it's that sim= ple and
> the nice API that abstracts a useful base set of communication
> pattern primitives that can be leveraged for multiple purposes is a > big part of what motivated me to dabble with it. =C2=A0There are some<= br> > variations of those "patterns" or different ways the pattern= s might
> be instantiated (e.g. using some of the different protocols or
> mixes of those that Michael identified in his writeup) that could
> be explored and may be relevant to TAPS goals if the an appropriate > scope is identified. =C2=A0I don't think there is an infinite numb= er of
> these and there might be some taxonomy supportable by TAPS? =C2=A0Some=
> examples of what I mean that come to mind include supporting live
> media pub/sub, asymmetric communication models (e.g. pub/sub with
> multicast pub and unicast subscription handling) and that's just > for the pub/sub pattern. =C2=A0Even if TAPS doesn't encompass all = of
> this, at least thinking about these sorts of use cases, as I'm sur= e
> _you_ have ;-), can help identify what TAPS does do.

Yes, I've been thinking about the patterns for nearly a decade no= w.
And yes, I believe they should be formalised. I've even tried to write<= br> some experimental RFCs. Here's the one for REQ/REP pattern, for example= :

https://raw.githubusercontent.com/n= anomsg/nanomsg/master/rfc/sp-request-reply-01.txt

All that being said, I still believe that including such work into
TAPS would be a serious case of mission creep.

Still, if people are interested in discussing communication patters, I
am happy to do so. I am not sure what the appropriate forum would be
for that though. AFAIK IETF doesn't even have an area that would fit this "interaction protocols among many nodes" stuff.

Martin


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTflFfAAoJENTpVjxCNN9YfTMH/RhB8m9X4JPi2ykekLTsGY7m
gMzr/4hi9dpWzjrD6m5dgxh3XiKl5heB2RH4nyX6JtH7fgD43a+LMLF3Y6z8KrXF
cUmXu+kyhoCOOMS7oIRD8RMWXLQticHKZznNP9FYNH/LRLl2t8zmYJQgMdNGtYz4
sXSDIJz7zjZl2hvOxDatjLpel/R2xUXLhEp3MFwEJDjQsazCyDahXjReoTVPoXKY
leAMl+smVgk0HqpZVt+UJ/iDYczmh/VFtwTulw2Ky1x+5rqKl1c2sxIy0VMeUsoU
s51yWQLedEDQWGG/pyB8EMnw0UnIL3+Tv6zMWKX7rEfCavEoRLApS/zudyA1vY4=3D
=3DFgk+
-----END PGP SIGNATURE-----

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

--001a11c146d055dac404fa5cb4a5-- From nobody Tue May 27 00:34:19 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CFE1A01F2 for ; Tue, 27 May 2014 00:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Zki92gHEdb5 for ; Tue, 27 May 2014 00:34:16 -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 F1A101A01D2 for ; Tue, 27 May 2014 00:34:15 -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 1WpBtg-0005ez-K1; Tue, 27 May 2014 09:34:08 +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 1WpBtg-0006fv-4Z; Tue, 27 May 2014 09:34:08 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_6085D741-3B3F-446C-BA2A-F4CA26934DA0" From: Michael Welzl In-Reply-To: Date: Tue, 27 May 2014 09:34:05 +0200 Message-Id: <7AF4A249-164B-442B-B8D8-8A96A9267E78@ifi.uio.no> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> To: Jon Crowcroft X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 4 sum rcpts/h 12 sum msgs/h 6 total rcpts 16803 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-9.1, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, UIO_PGP_SIGNED=-3, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5E9236495BDC072FBD0AC001843D1A9F78EB93E4 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -90 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 5490 max/h 16 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/kAXyHOKdrXexeycBwrlkzxbFKO0 Cc: Gorry Fairhurst , taps@ietf.org, Martin Sustrik , Brian Adamson Subject: Re: [Taps] IETF journal article update 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, 27 May 2014 07:34:18 -0000 --Apple-Mail=_6085D741-3B3F-446C-BA2A-F4CA26934DA0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 =3D> very interesting but beyond. On 27. mai 2014, at 09:32, Jon Crowcroft wrote: > totally agree - I think generalized pattern approach is really nice, = and we tried using it in the "building blocks" structure that was used = in the RMT group - i think quite successfully >=20 > however, patterns (and RMT consierations too) are over-reach for TAPS, = in my opinion....life's too short to get something done that new, big, = and complex (and contentious in some quarters) >=20 >=20 > On Thu, May 22, 2014 at 8:34 PM, Martin Sustrik = wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 22/05/14 00:17, Brian Adamson wrote: > > Yes - definitely some need to put some scope limit on the thoughts > > here. I wasn't able to make the London BoF as I hoped and still > > need to review the presentations from that so I apologize if I'm > > speaking out of turn. I just meant to ask about the lack of > > mention of multicast in journal article ... > > > > I was using the ZeroMQ PUB/SUB pattern as an example. As you > > point out, the only difference for multicast/unicast was changing > > the endpoint address. It's quite nice that it's that simple and > > the nice API that abstracts a useful base set of communication > > pattern primitives that can be leveraged for multiple purposes is a > > big part of what motivated me to dabble with it. There are some > > variations of those "patterns" or different ways the patterns might > > be instantiated (e.g. using some of the different protocols or > > mixes of those that Michael identified in his writeup) that could > > be explored and may be relevant to TAPS goals if the an appropriate > > scope is identified. I don't think there is an infinite number of > > these and there might be some taxonomy supportable by TAPS? Some > > examples of what I mean that come to mind include supporting live > > media pub/sub, asymmetric communication models (e.g. pub/sub with > > multicast pub and unicast subscription handling) and that's just > > for the pub/sub pattern. Even if TAPS doesn't encompass all of > > this, at least thinking about these sorts of use cases, as I'm sure > > _you_ have ;-), can help identify what TAPS does do. >=20 > Yes, I've been thinking about the patterns for nearly a decade now. > And yes, I believe they should be formalised. I've even tried to write > some experimental RFCs. Here's the one for REQ/REP pattern, for = example: >=20 > = https://raw.githubusercontent.com/nanomsg/nanomsg/master/rfc/sp-request-re= ply-01.txt >=20 > All that being said, I still believe that including such work into > TAPS would be a serious case of mission creep. >=20 > Still, if people are interested in discussing communication patters, I > am happy to do so. I am not sure what the appropriate forum would be > for that though. AFAIK IETF doesn't even have an area that would fit > this "interaction protocols among many nodes" stuff. >=20 > Martin >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >=20 > iQEcBAEBAgAGBQJTflFfAAoJENTpVjxCNN9YfTMH/RhB8m9X4JPi2ykekLTsGY7m > gMzr/4hi9dpWzjrD6m5dgxh3XiKl5heB2RH4nyX6JtH7fgD43a+LMLF3Y6z8KrXF > cUmXu+kyhoCOOMS7oIRD8RMWXLQticHKZznNP9FYNH/LRLl2t8zmYJQgMdNGtYz4 > sXSDIJz7zjZl2hvOxDatjLpel/R2xUXLhEp3MFwEJDjQsazCyDahXjReoTVPoXKY > leAMl+smVgk0HqpZVt+UJ/iDYczmh/VFtwTulw2Ky1x+5rqKl1c2sxIy0VMeUsoU > s51yWQLedEDQWGG/pyB8EMnw0UnIL3+Tv6zMWKX7rEfCavEoRLApS/zudyA1vY4=3D > =3DFgk+ > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps >=20 --Apple-Mail=_6085D741-3B3F-446C-BA2A-F4CA26934DA0 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii +1

=> very interesting but beyond.


On 27. mai 2014, at 09:32, Jon Crowcroft wrote:

totally agree - I think generalized pattern approach is really nice, and we tried using it in the "building blocks" structure that was used in the RMT group - i think quite successfully

however, patterns (and RMT consierations too) are over-reach for TAPS, in my opinion....life's too short to get something done that new, big, and complex (and contentious in some quarters)


On Thu, May 22, 2014 at 8:34 PM, Martin Sustrik <sustrik@250bpm.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 22/05/14 00:17, Brian Adamson wrote:
> Yes - definitely some need to put some scope limit on the thoughts
> here.  I wasn't able to make the London BoF as I hoped and still
> need to review the presentations from that so I apologize if I'm
> speaking out of turn.  I just meant to ask about the lack of
> mention of multicast in journal article ...
>
> I was using the ZeroMQ PUB/SUB pattern as an example.  As you
> point out, the only difference for multicast/unicast was changing
> the endpoint address.  It's quite nice that it's that simple and
> the nice API that abstracts a useful base set of communication
> pattern primitives that can be leveraged for multiple purposes is a
> big part of what motivated me to dabble with it.  There are some
> variations of those "patterns" or different ways the patterns might
> be instantiated (e.g. using some of the different protocols or
> mixes of those that Michael identified in his writeup) that could
> be explored and may be relevant to TAPS goals if the an appropriate
> scope is identified.  I don't think there is an infinite number of
> these and there might be some taxonomy supportable by TAPS?  Some
> examples of what I mean that come to mind include supporting live
> media pub/sub, asymmetric communication models (e.g. pub/sub with
> multicast pub and unicast subscription handling) and that's just
> for the pub/sub pattern.  Even if TAPS doesn't encompass all of
> this, at least thinking about these sorts of use cases, as I'm sure
> _you_ have ;-), can help identify what TAPS does do.

Yes, I've been thinking about the patterns for nearly a decade now.
And yes, I believe they should be formalised. I've even tried to write
some experimental RFCs. Here's the one for REQ/REP pattern, for example:

https://raw.githubusercontent.com/nanomsg/nanomsg/master/rfc/sp-request-reply-01.txt

All that being said, I still believe that including such work into
TAPS would be a serious case of mission creep.

Still, if people are interested in discussing communication patters, I
am happy to do so. I am not sure what the appropriate forum would be
for that though. AFAIK IETF doesn't even have an area that would fit
this "interaction protocols among many nodes" stuff.

Martin


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTflFfAAoJENTpVjxCNN9YfTMH/RhB8m9X4JPi2ykekLTsGY7m
gMzr/4hi9dpWzjrD6m5dgxh3XiKl5heB2RH4nyX6JtH7fgD43a+LMLF3Y6z8KrXF
cUmXu+kyhoCOOMS7oIRD8RMWXLQticHKZznNP9FYNH/LRLl2t8zmYJQgMdNGtYz4
sXSDIJz7zjZl2hvOxDatjLpel/R2xUXLhEp3MFwEJDjQsazCyDahXjReoTVPoXKY
leAMl+smVgk0HqpZVt+UJ/iDYczmh/VFtwTulw2Ky1x+5rqKl1c2sxIy0VMeUsoU
s51yWQLedEDQWGG/pyB8EMnw0UnIL3+Tv6zMWKX7rEfCavEoRLApS/zudyA1vY4=
=Fgk+
-----END PGP SIGNATURE-----

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


--Apple-Mail=_6085D741-3B3F-446C-BA2A-F4CA26934DA0-- From nobody Tue May 27 01:20:09 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2721A03ED for ; Tue, 27 May 2014 01:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.005 X-Spam-Level: X-Spam-Status: No, score=0.005 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] 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 C6_aHyNT2Ths for ; Tue, 27 May 2014 01:20:04 -0700 (PDT) Received: from mail.moloch.sk (chrocht.moloch.sk [62.176.169.44]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DA131A03E4 for ; Tue, 27 May 2014 01:20:04 -0700 (PDT) Received: from [192.168.0.101] (ip66.bbxnet.sk [91.219.133.66]) by mail.moloch.sk (Postfix) with ESMTPSA id E85E01806ECB; Tue, 27 May 2014 10:19:58 +0200 (CEST) Message-ID: <53844AAE.2000607@250bpm.com> Date: Tue, 27 May 2014 10:19:58 +0200 From: Martin Sustrik User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Jon Crowcroft References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/Pzi4f4_GB3Y6k_LocYKpT0ntNiI Cc: Gorry Fairhurst , Brian Adamson , Michael Welzl , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 27 May 2014 08:20:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27/05/14 09:32, Jon Crowcroft wrote: > totally agree - I think generalized pattern approach is really > nice, and we tried using it in the "building blocks" structure that > was used in the RMT group - i think quite successfully > > however, patterns (and RMT consierations too) are over-reach for > TAPS, in my opinion....life's too short to get something done that > new, big, and complex (and contentious in some quarters) Still, do you know whether there's a place where that kind of stuff is discussed? I wanted to create such working group within IETF once, even spoke to Peter Saint-Andre who was directort of application area back then, but nothing have materialised in the end. Martin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJThEquAAoJENTpVjxCNN9YUlYH/jotPSYDIVE8I4FPjduzwrQx L4KAgFvREKG9QiaTL0alnKdBQHm+pA3eq7Es1FwMjw5SleCt54ZffwyggjqNXHiN jBLBa8/XzBmpoXPpm8fG9FlM4c2GLLgU+itxTp3kvM4jL6ZxUJW7bf/lde/EWogF IA9SAR63hqvUIOB1BrW5poGP7N1UKPsD2DPohGUkMnlJVRpM6iTk5s4iId8BqTsc ub8tpL4QnEWkihxYJd90bJI48RDaNu819bRzDYIVcKDiByRw2ErqfPI0q761awuQ Y60gzy7/4Ejw/1tRWLW0NVUMqcwd3FVmPIWdlZ9qdhJebWEcFD/1SsAzMc5/bzI= =qpyn -----END PGP SIGNATURE----- From nobody Tue May 27 01:32:59 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE1C1A007F for ; Tue, 27 May 2014 01:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2J2TbGgViaON for ; Tue, 27 May 2014 01:32:53 -0700 (PDT) Received: from ppsw-40.csi.cam.ac.uk (ppsw-40-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f40]) (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 389FF1A0064 for ; Tue, 27 May 2014 01:32:53 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from s235i161.wolfson.cam.ac.uk ([128.232.235.161]:47264 helo=[10.0.1.2]) by ppsw-40.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1WpCoM-0007ZR-l2 (Exim 4.82_3-c0e5623) (return-path ); Tue, 27 May 2014 09:32:42 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Toby Moncaster In-Reply-To: <53844AAE.2000607@250bpm.com> Date: Tue, 27 May 2014 09:32:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <098D758E-8A80-4D37-B5E5-4F66380C9BDE@cl.cam.ac.uk> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <53844AAE.2000607@250bpm.com> To: Martin Sustrik X-Mailer: Apple Mail (2.1874) Sender: "T. Moncaster" Archived-At: http://mailarchive.ietf.org/arch/msg/taps/0l5x0DPaiX3fY6nfqzZd7EwpFKQ Cc: Gorry Fairhurst , taps@ietf.org, Jon Crowcroft , Michael Welzl , Brian Adamson Subject: Re: [Taps] IETF journal article update 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, 27 May 2014 08:32:55 -0000 Would this be the sort of thing that could live in the IRTF? It would = give it more freedom=85 Toby On 27 May 2014, at 09:19, Martin Sustrik wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 27/05/14 09:32, Jon Crowcroft wrote: >> totally agree - I think generalized pattern approach is really >> nice, and we tried using it in the "building blocks" structure that >> was used in the RMT group - i think quite successfully >>=20 >> however, patterns (and RMT consierations too) are over-reach for >> TAPS, in my opinion....life's too short to get something done that >> new, big, and complex (and contentious in some quarters) >=20 > Still, do you know whether there's a place where that kind of stuff is > discussed? I wanted to create such working group within IETF once, > even spoke to Peter Saint-Andre who was directort of application area > back then, but nothing have materialised in the end. >=20 > Martin > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >=20 > iQEcBAEBAgAGBQJThEquAAoJENTpVjxCNN9YUlYH/jotPSYDIVE8I4FPjduzwrQx > L4KAgFvREKG9QiaTL0alnKdBQHm+pA3eq7Es1FwMjw5SleCt54ZffwyggjqNXHiN > jBLBa8/XzBmpoXPpm8fG9FlM4c2GLLgU+itxTp3kvM4jL6ZxUJW7bf/lde/EWogF > IA9SAR63hqvUIOB1BrW5poGP7N1UKPsD2DPohGUkMnlJVRpM6iTk5s4iId8BqTsc > ub8tpL4QnEWkihxYJd90bJI48RDaNu819bRzDYIVcKDiByRw2ErqfPI0q761awuQ > Y60gzy7/4Ejw/1tRWLW0NVUMqcwd3FVmPIWdlZ9qdhJebWEcFD/1SsAzMc5/bzI=3D > =3Dqpyn > -----END PGP SIGNATURE----- >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue May 27 02:35:58 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1391E1A006D for ; Tue, 27 May 2014 02:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.851 X-Spam-Level: X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpTco-4Aq6id for ; Tue, 27 May 2014 02:35:51 -0700 (PDT) Received: from mta0.cl.cam.ac.uk (mta0.cl.cam.ac.uk [128.232.25.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D35741A0049 for ; Tue, 27 May 2014 02:35:50 -0700 (PDT) Received: from ssh-remote-0.cl.cam.ac.uk ([128.232.0.69] helo=cl.cam.ac.uk) by mta0.cl.cam.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1WpDnO-0001ei-Ca; Tue, 27 May 2014 10:35:46 +0100 To: Martin Sustrik In-reply-to: <53844AAE.2000607@250bpm.com> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <53844AAE.2000607@250bpm.com> Comments: In-reply-to Martin Sustrik message dated "Tue, 27 May 2014 10:19:58 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1811.1401183346.1@cl.cam.ac.uk> Date: Tue, 27 May 2014 10:35:46 +0100 From: Jon Crowcroft Message-Id: Archived-At: http://mailarchive.ietf.org/arch/msg/taps/BpiK7eOXzmk8HdqZLynn4lPh1go Cc: taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 27 May 2014 09:35:57 -0000 In missive <53844AAE.2000607@250bpm.com>, Martin Sustrik typed: >>Still, do you know whether there's a place where that kind of stuff is >>discussed? I wanted to create such working group within IETF once, >>even spoke to Peter Saint-Andre who was directort of application area >>back then, but nothing have materialised in the end. Martin I think the ietf (and even to some extent the irtf) is inimicable to computer science:) >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.4.11 (GNU/Linux) >>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >>iQEcBAEBAgAGBQJThEquAAoJENTpVjxCNN9YUlYH/jotPSYDIVE8I4FPjduzwrQx >>L4KAgFvREKG9QiaTL0alnKdBQHm+pA3eq7Es1FwMjw5SleCt54ZffwyggjqNXHiN >>jBLBa8/XzBmpoXPpm8fG9FlM4c2GLLgU+itxTp3kvM4jL6ZxUJW7bf/lde/EWogF >>IA9SAR63hqvUIOB1BrW5poGP7N1UKPsD2DPohGUkMnlJVRpM6iTk5s4iId8BqTsc >>ub8tpL4QnEWkihxYJd90bJI48RDaNu819bRzDYIVcKDiByRw2ErqfPI0q761awuQ >>Y60gzy7/4Ejw/1tRWLW0NVUMqcwd3FVmPIWdlZ9qdhJebWEcFD/1SsAzMc5/bzI= >>=qpyn >>-----END PGP SIGNATURE----- cheers jon From nobody Tue May 27 06:53:44 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8121A038E for ; Tue, 27 May 2014 06:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLUK3XZ8X_FY for ; Tue, 27 May 2014 06:53:40 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 857A11A034E for ; Tue, 27 May 2014 06:53:39 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id uz6so9209738obc.19 for ; Tue, 27 May 2014 06:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Jd6S/Q577mEPLBtsKL3wpzJfYL5Ehj3ZeL/f3R83/8Y=; b=zAzUzBYgRlVMks11eHIfAv7GeeuCplNFcbistqOckmMu4w8ZP0tz9s7sHxhM4FFXq3 icaMZyXrhTMSPCrAX7SMuQDtPgM0TwKmlJ9PmFgbjOaeSB3xCaEWyDO+mJGm/KUVsY8E mntRYSaBuTkdri8O7YGZ1OnZX9ukO6kZ+Kk0ag5FvBMMF0v6SwrMhjHa6qjfKvyf5xf2 BxzV2wbU5P7TozUDMD/+tFPgNtKAxLlPK8SeyAjWQyXTJJyM762B6yFSd6ppSs9fjdgK zgZBnvFFh++PsLG4rhdhgqjAGOa/+prvpWN1i9Hw4XLGU2xAu6RKwRi2Z9PC1NwHWybq 2vpw== X-Received: by 10.182.42.136 with SMTP id o8mr3660518obl.80.1401198816181; Tue, 27 May 2014 06:53:36 -0700 (PDT) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id bh9sm28539877obb.7.2014.05.27.06.53.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 06:53:35 -0700 (PDT) Message-ID: <538498DE.20806@gmail.com> Date: Tue, 27 May 2014 08:53:34 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: taps@ietf.org References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/bJe6JgylSFnj7KrmBPxxwI8Sad4 Cc: Martin Stiemerling Subject: Re: [Taps] IETF journal article update 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, 27 May 2014 13:53:43 -0000 So, it may be useful for me to chime in here. I'm speaking only as 1/16th of the IESG, of course. I thought the TAPS BoF in London was very helpful, and the IESG and IAB spent a significant amount of time talking about what happened at the BoF (thanks to Michael and Murray for capable chairing, and to Michael for producing near-verbatim minutes from the recorded audio), both at the "week in review" session on Friday afternoon after IETF 89, and at the joint IESG/IAB retreat a couple of weeks ago. There's a lot to talk about, and the folks who observed that IETF working groups are a lousy place to talk about things, especially at charter time, are dead-on. So what I'm asking, is that people take a shot at proposing a minimal charter that we could approve quickly (and maybe without a BOF - they aren't required, and we're trying to make it easier for people to start work). We'll find venues for work that needs to happen, whether in IETF working groups, in IRTF research groups, or as Independent Submissions, and I'm happy to sponsor mailing lists for various chunks of this work as you identify them, so you don't have to have one big conversation about the Answer to Life, the Universe, and Everything (c). So please, talk amongst yourselves, and see what you can agree on :-) Spencer On 05/27/2014 02:32 AM, Jon Crowcroft wrote: > totally agree - I think generalized pattern approach is really nice, > and we tried using it in the "building blocks" structure that was used > in the RMT group - i think quite successfully > > however, patterns (and RMT consierations too) are over-reach for TAPS, > in my opinion....life's too short to get something done that new, big, > and complex (and contentious in some quarters) From nobody Tue May 27 07:12: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 B69101A011D for ; Tue, 27 May 2014 07:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTvu-BWOLxdD for ; Tue, 27 May 2014 07:11:56 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF521A03C6 for ; Tue, 27 May 2014 07:11:56 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WpI6Z-0004FI-SM; Tue, 27 May 2014 16:11:51 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WpI6Z-0004ju-EN; Tue, 27 May 2014 16:11:51 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Welzl In-Reply-To: <538498DE.20806@gmail.com> Date: Tue, 27 May 2014 16:11:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.1283) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 6 sum msgs/h 2 total rcpts 16841 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: D0DF4D338CD8DEF3247914DF0E65716C3987919E X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 5511 max/h 16 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/znErtfSdd9g_wSDwXrAa5_b6i48 Cc: Martin Stiemerling , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 27 May 2014 14:12:03 -0000 Thanks a lot Spencer! TAPS: please stay tuned for a first proposal coming from me very soon - = this incorporates some prior discussion that we probably don't want to = re-iterate and wouldn't want to incorporate in the current charter - you = heard the man: "a minimal charter that we could approve quickly", so = this is about removing things that we wanted to do from *this* charter, = and hoping / expecting that they will be dealt with elsewhere. Cheers Michael On 27. mai 2014, at 15:53, Spencer Dawkins wrote: > So, it may be useful for me to chime in here. I'm speaking only as = 1/16th of the IESG, of course. >=20 > I thought the TAPS BoF in London was very helpful, and the IESG and = IAB spent a significant amount of time talking about what happened at = the BoF (thanks to Michael and Murray for capable chairing, and to = Michael for producing near-verbatim minutes from the recorded audio), = both at the "week in review" session on Friday afternoon after IETF 89, = and at the joint IESG/IAB retreat a couple of weeks ago. >=20 > There's a lot to talk about, and the folks who observed that IETF = working groups are a lousy place to talk about things, especially at = charter time, are dead-on. >=20 > So what I'm asking, is that people take a shot at proposing a minimal = charter that we could approve quickly (and maybe without a BOF - they = aren't required, and we're trying to make it easier for people to start = work). >=20 > We'll find venues for work that needs to happen, whether in IETF = working groups, in IRTF research groups, or as Independent Submissions, = and I'm happy to sponsor mailing lists for various chunks of this work = as you identify them, so you don't have to have one big conversation = about the Answer to Life, the Universe, and Everything (c). >=20 > So please, talk amongst yourselves, and see what you can agree on :-) >=20 > Spencer >=20 > On 05/27/2014 02:32 AM, Jon Crowcroft wrote: >> totally agree - I think generalized pattern approach is really nice, = and we tried using it in the "building blocks" structure that was used = in the RMT group - i think quite successfully >>=20 >> however, patterns (and RMT consierations too) are over-reach for = TAPS, in my opinion....life's too short to get something done that new, = big, and complex (and contentious in some quarters) >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue May 27 12:38:20 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869EF1A0220 for ; Tue, 27 May 2014 12:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrgIg99K5t5E for ; Tue, 27 May 2014 12:38:13 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2122C1A022A for ; Tue, 27 May 2014 12:38:13 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WpNCJ-0006lk-CC for taps@ietf.org; Tue, 27 May 2014 21:38:07 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WpNCI-0003km-Po for taps@ietf.org; Tue, 27 May 2014 21:38:07 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: Date: Tue, 27 May 2014 21:38:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> To: taps@ietf.org X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 2 sum rcpts/h 4 sum msgs/h 4 total rcpts 16849 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A17F02D3FCBD7C3EDD9A8B38011780A05A8A09C6 X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1517 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/rgbG1vSJy6w0c_R8bRWWDHOwkNc Subject: Re: [Taps] IETF journal article update 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, 27 May 2014 19:38:19 -0000 Hi all, Following up on this, please take a look at: https://sites.google.com/site/transportprotocolservices/charter-proposal I'd like to suggest this as a way forward to the group; could you = support this as a Charter for forming a WG? I think it's clear to all of us that there should be more work beyond = this, but it is important that the initial goals are clear and = attainable. Work beyond could take various forms, in various places - = note how Spencer wrote "We'll find venues for work that needs to = happen". This new proposed charter is about having a common starting = point that we all can agree on. Cheers, Michael On 27. mai 2014, at 16:11, Michael Welzl wrote: > Thanks a lot Spencer! >=20 > TAPS: please stay tuned for a first proposal coming from me very soon = - this incorporates some prior discussion that we probably don't want to = re-iterate and wouldn't want to incorporate in the current charter - you = heard the man: "a minimal charter that we could approve quickly", so = this is about removing things that we wanted to do from *this* charter, = and hoping / expecting that they will be dealt with elsewhere. >=20 > Cheers > Michael >=20 >=20 >=20 > On 27. mai 2014, at 15:53, Spencer Dawkins wrote: >=20 >> So, it may be useful for me to chime in here. I'm speaking only as = 1/16th of the IESG, of course. >>=20 >> I thought the TAPS BoF in London was very helpful, and the IESG and = IAB spent a significant amount of time talking about what happened at = the BoF (thanks to Michael and Murray for capable chairing, and to = Michael for producing near-verbatim minutes from the recorded audio), = both at the "week in review" session on Friday afternoon after IETF 89, = and at the joint IESG/IAB retreat a couple of weeks ago. >>=20 >> There's a lot to talk about, and the folks who observed that IETF = working groups are a lousy place to talk about things, especially at = charter time, are dead-on. >>=20 >> So what I'm asking, is that people take a shot at proposing a minimal = charter that we could approve quickly (and maybe without a BOF - they = aren't required, and we're trying to make it easier for people to start = work). >>=20 >> We'll find venues for work that needs to happen, whether in IETF = working groups, in IRTF research groups, or as Independent Submissions, = and I'm happy to sponsor mailing lists for various chunks of this work = as you identify them, so you don't have to have one big conversation = about the Answer to Life, the Universe, and Everything (c). >>=20 >> So please, talk amongst yourselves, and see what you can agree on :-) >>=20 >> Spencer >>=20 >> On 05/27/2014 02:32 AM, Jon Crowcroft wrote: >>> totally agree - I think generalized pattern approach is really nice, = and we tried using it in the "building blocks" structure that was used = in the RMT group - i think quite successfully >>>=20 >>> however, patterns (and RMT consierations too) are over-reach for = TAPS, in my opinion....life's too short to get something done that new, = big, and complex (and contentious in some quarters) >>=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 Tue May 27 13:14:13 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741EC1A072B for ; Tue, 27 May 2014 13:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1AafV9sJy-M for ; Tue, 27 May 2014 13:14:07 -0700 (PDT) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD3C1A06E1 for ; Tue, 27 May 2014 13:14:06 -0700 (PDT) X-Spam-Processed: mail.kau.se, Tue, 27 May 2014 22:13:51 +0200 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: annabrun@kau.se X-MDRemoteIP: 213.113.183.193 X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se X-MDaemon-Deliver-To: taps@ietf.org Message-ID: <5384F201.3050508@kau.se> Date: Tue, 27 May 2014 22:13:53 +0200 From: Anna Brunstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: taps@ietf.org References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010406080509060407000102" Archived-At: http://mailarchive.ietf.org/arch/msg/taps/x1_U-KoaZkvKojgqXlv6qwawTTQ Subject: Re: [Taps] IETF journal article update 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, 27 May 2014 20:14:10 -0000 This is a multi-part message in MIME format. --------------010406080509060407000102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Michael, I agree with your proposal as a good common starting point. One detail on the deliverables: In the first bullet identifying available services it says "IETF transport protocols and congestion control mechanisms" in the third bullet on providing services it says "IETF transports". Should the third bullet not also be "IETF transports and congestion control mechanisms" to be consistent? (Alternatively the first bullet should be revised.) Also, you lost some text (or missed to remove): "The Working Group will coordinate closely with groups." Cheers, Anna On 2014-05-27 21:38, Michael Welzl wrote: > Hi all, > > Following up on this, please take a look at: > https://sites.google.com/site/transportprotocolservices/charter-proposal > > I'd like to suggest this as a way forward to the group; could you support this as a Charter for forming a WG? > > I think it's clear to all of us that there should be more work beyond this, but it is important that the initial goals are clear and attainable. Work beyond could take various forms, in various places - note how Spencer wrote "We'll find venues for work that needs to happen". This new proposed charter is about having a common starting point that we all can agree on. > > Cheers, > Michael > > > > On 27. mai 2014, at 16:11, Michael Welzl wrote: > >> Thanks a lot Spencer! >> >> TAPS: please stay tuned for a first proposal coming from me very soon - this incorporates some prior discussion that we probably don't want to re-iterate and wouldn't want to incorporate in the current charter - you heard the man: "a minimal charter that we could approve quickly", so this is about removing things that we wanted to do from *this* charter, and hoping / expecting that they will be dealt with elsewhere. >> >> Cheers >> Michael >> >> >> >> On 27. mai 2014, at 15:53, Spencer Dawkins wrote: >> >>> So, it may be useful for me to chime in here. I'm speaking only as 1/16th of the IESG, of course. >>> >>> I thought the TAPS BoF in London was very helpful, and the IESG and IAB spent a significant amount of time talking about what happened at the BoF (thanks to Michael and Murray for capable chairing, and to Michael for producing near-verbatim minutes from the recorded audio), both at the "week in review" session on Friday afternoon after IETF 89, and at the joint IESG/IAB retreat a couple of weeks ago. >>> >>> There's a lot to talk about, and the folks who observed that IETF working groups are a lousy place to talk about things, especially at charter time, are dead-on. >>> >>> So what I'm asking, is that people take a shot at proposing a minimal charter that we could approve quickly (and maybe without a BOF - they aren't required, and we're trying to make it easier for people to start work). >>> >>> We'll find venues for work that needs to happen, whether in IETF working groups, in IRTF research groups, or as Independent Submissions, and I'm happy to sponsor mailing lists for various chunks of this work as you identify them, so you don't have to have one big conversation about the Answer to Life, the Universe, and Everything (c). >>> >>> So please, talk amongst yourselves, and see what you can agree on :-) >>> >>> Spencer >>> >>> On 05/27/2014 02:32 AM, Jon Crowcroft wrote: >>>> totally agree - I think generalized pattern approach is really nice, and we tried using it in the "building blocks" structure that was used in the RMT group - i think quite successfully >>>> >>>> however, patterns (and RMT consierations too) are over-reach for TAPS, in my opinion....life's too short to get something done that new, big, and complex (and contentious in some quarters) >>> _______________________________________________ >>> 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 --------------010406080509060407000102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Michael,

I agree with your proposal as a good common starting point.

One detail on the deliverables: In the first bullet identifying available services it says "IETF transport protocols and congestion control mechanisms" in the third bullet on providing services it says "IETF transports". Should the third bullet not also be "IETF transports and congestion control mechanisms" to be consistent? (Alternatively the first bullet should be revised.)

Also, you lost some text (or missed to remove): "The Working Group will coordinate closely with groups."

Cheers,
Anna


On 2014-05-27 21:38, Michael Welzl wrote:
Hi all,

Following up on this, please take a look at:
https://sites.google.com/site/transportprotocolservices/charter-proposal

I'd like to suggest this as a way forward to the group; could you support this as a Charter for forming a WG?

I think it's clear to all of us that there should be more work beyond this, but it is important that the initial goals are clear and attainable. Work beyond could take various forms, in various places - note how Spencer wrote "We'll find venues for work that needs to happen". This new proposed charter is about having a common starting point that we all can agree on.

Cheers,
Michael



On 27. mai 2014, at 16:11, Michael Welzl <michawe@ifi.uio.no> wrote:


Thanks a lot Spencer!

TAPS: please stay tuned for a first proposal coming from me very soon - this incorporates some prior discussion that we probably don't want to re-iterate and wouldn't want to incorporate in the current charter - you heard the man: "a minimal charter that we could approve quickly", so this is about removing things that we wanted to do from *this* charter, and hoping / expecting that they will be dealt with elsewhere.

Cheers
Michael



On 27. mai 2014, at 15:53, Spencer Dawkins wrote:


So, it may be useful for me to chime in here. I'm speaking only as 1/16th of the IESG, of course.

I thought the TAPS BoF in London was very helpful, and the IESG and IAB spent a significant amount of time talking about what happened at the BoF (thanks to Michael and Murray for capable chairing, and to Michael for producing near-verbatim minutes from the recorded audio), both at the "week in review" session on Friday afternoon after IETF 89, and at the joint IESG/IAB retreat a couple of weeks ago.

There's a lot to talk about, and the folks who observed that IETF working groups are a lousy place to talk about things, especially at charter time, are dead-on.

So what I'm asking, is that people take a shot at proposing a minimal charter that we could approve quickly (and maybe without a BOF - they aren't required, and we're trying to make it easier for people to start work).

We'll find venues for work that needs to happen, whether in IETF working groups, in IRTF research groups, or as Independent Submissions, and I'm happy to sponsor mailing lists for various chunks of this work as you identify them, so you don't have to have one big conversation about the Answer to Life, the Universe, and Everything (c).

So please, talk amongst yourselves, and see what you can agree on :-)

Spencer

On 05/27/2014 02:32 AM, Jon Crowcroft wrote:

totally agree - I think generalized pattern approach is really nice, and we tried using it in the "building blocks" structure that was used in the RMT group - i think quite successfully

however, patterns (and RMT consierations too) are over-reach for TAPS, in my opinion....life's too short to get something done that new, big, and complex (and contentious in some quarters)

_______________________________________________
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

--------------010406080509060407000102-- From nobody Tue May 27 23:35:57 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA3D1A084B for ; Tue, 27 May 2014 23:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rM3uUjbW2GW for ; Tue, 27 May 2014 23:35:52 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AD771A0546 for ; Tue, 27 May 2014 23:35:52 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WpXSl-0006mu-UA; Wed, 28 May 2014 08:35:47 +0200 Received: from [195.69.7.6] (helo=[10.190.12.195]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WpXSe-0007m7-Qz; Wed, 28 May 2014 08:35:47 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_02CD5483-A9C2-4848-9F57-D035195EFD90" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <5384F201.3050508@kau.se> Date: Wed, 28 May 2014 08:35:38 +0200 Message-Id: <6435044C-C17F-4B37-937C-73E1B8C0DE9D@ifi.uio.no> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <5384F201.3050508@kau.se> To: Anna Brunstrom X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 3 sum msgs/h 2 total rcpts 16855 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B65C7CBF26199CBB956AFBBE09F57AFBE80893F8 X-UiO-SPAM-Test: remote_host: 195.69.7.6 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1647 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/tZkIneQhbTRIn6dEef8AIIOa184 Cc: taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 06:35:55 -0000 --Apple-Mail=_02CD5483-A9C2-4848-9F57-D035195EFD90 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On 27. mai 2014, at 22:13, Anna Brunstrom wrote: > Hi Michael, >=20 > I agree with your proposal as a good common starting point.=20 Great! Others - in case you also agree, please say it out loud too - I = think we want to get a general idea of the group's perception as soon as = possible now. > One detail on the deliverables: In the first bullet identifying = available services it says "IETF transport protocols and congestion = control mechanisms" in the third bullet on providing services it says = "IETF transports". Should the third bullet not also be "IETF transports = and congestion control mechanisms" to be consistent? = (Alternatively the first bullet should be revised.) Not 100% sure which bullet you mean, but I think anyway the answer is = no: the first is about identifying services, the third (deliverable / = milestone) is about how to provide them. You need a protocol to provide = a service. > Also, you lost some text (or missed to remove): "The Working Group = will coordinate closely with groups." Fixed Cheers, Michael --Apple-Mail=_02CD5483-A9C2-4848-9F57-D035195EFD90 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Hi,


On 27. mai 2014, at 22:13, Anna Brunstrom <anna.brunstrom@kau.se> wrote:

Hi Michael,

I agree with your proposal as a good common starting point.

Great!  Others - in case you also agree, please say it out loud too - I think we want to get a general idea of the group's perception as soon as possible now.


One detail on the deliverables: In the first bullet identifying available services it says "IETF transport protocols and congestion control mechanisms" in the third bullet on providing services it says "IETF transports". Should the third bullet not also be "IETF transports and congestion control mechanisms" to be consistent? (Alternatively the first bullet should be revised.)

Not 100% sure which bullet you mean, but I think anyway the answer is no: the first is about identifying services, the third (deliverable / milestone) is about how to provide them. You need a protocol to provide a service.


Also, you lost some text (or missed to remove): "The Working Group will coordinate closely with groups."

Fixed

Cheers,
Michael

--Apple-Mail=_02CD5483-A9C2-4848-9F57-D035195EFD90-- From nobody Tue May 27 23:56:09 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA811A0377 for ; Tue, 27 May 2014 23:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKN7u_sB8M4t for ; Tue, 27 May 2014 23:56:05 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1F11A023F for ; Tue, 27 May 2014 23:56:05 -0700 (PDT) Received: from [10.0.27.102] (cust-integra-122-165.antanet.ch [80.75.122.165]) by trammell.ch (Postfix) with ESMTPSA id AD0F41A07EE; Wed, 28 May 2014 08:55:30 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_8BB0D832-E1B6-4FD9-BB12-376C058577DC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Brian Trammell In-Reply-To: <6435044C-C17F-4B37-937C-73E1B8C0DE9D@ifi.uio.no> Date: Wed, 28 May 2014 08:55:30 +0200 Message-Id: <23240F18-975F-48DF-959B-9CD84D4BB43A@trammell.ch> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <5384F201.3050508@kau.se> <6435044C-C17F-4B37-937C-73E1B8C0DE9D@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/42Drqv73_0UlxJl-qyyW177KMQY Cc: Anna Brunstrom , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 06:56:07 -0000 --Apple-Mail=_8BB0D832-E1B6-4FD9-BB12-376C058577DC Content-Type: multipart/alternative; boundary="Apple-Mail=_681437B3-7ECA-40DE-8E77-62958C68D020" --Apple-Mail=_681437B3-7ECA-40DE-8E77-62958C68D020 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 hi Michael, +1 to everything Anna said; the present proposal strikes a good balance = between what can be immediately useful in this space and what we already = know how to do. I would make one point on your edit, though... On 28 May 2014, at 08:35, Michael Welzl wrote: > Hi, >=20 >=20 > On 27. mai 2014, at 22:13, Anna Brunstrom = wrote: >=20 >> Hi Michael, >>=20 >> I agree with your proposal as a good common starting point.=20 >=20 > Great! Others - in case you also agree, please say it out loud too - = I think we want to get a general idea of the group's perception as soon = as possible now. >=20 >=20 >> One detail on the deliverables: In the first bullet identifying = available services it says "IETF transport protocols and congestion = control mechanisms" in the third bullet on providing services it says = "IETF transports". Should the third bullet not also be "IETF transports = and congestion control mechanisms" to be consistent? (Alternatively the = first bullet should be revised.) >=20 > Not 100% sure which bullet you mean, but I think anyway the answer is = no: the first is about identifying services, the third (deliverable / = milestone) is about how to provide them. You need a protocol to provide = a service. >=20 >=20 >> Also, you lost some text (or missed to remove): "The Working Group = will coordinate closely with groups." >=20 > Fixed Coordination is not just important with other Working Groups, but with = possible Research Groups in the IRTF as well, since lots of things we = suspect we want to do but which aren't cooked enough to do engineering = on yet could be referred to a future RG. Cheers, Brian > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_681437B3-7ECA-40DE-8E77-62958C68D020 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 hi = Michael,

+1 to everything Anna said; the present = proposal strikes a good balance between what can be immediately useful = in this space and what we already know how to do. I would make one point = on your edit, though...

On 28 May = 2014, at 08:35, Michael Welzl <michawe@ifi.uio.no> = wrote:

Hi,


On 27. mai = 2014, at 22:13, Anna Brunstrom <anna.brunstrom@kau.se> = wrote:

=20 =20
Hi Michael,

I agree with your proposal as a good common starting point. =

Great!  Others - in case you = also agree, please say it out loud too - I think we want to get a = general idea of the group's perception as soon as possible = now.


=20 One detail on the deliverables: In the first bullet identifying available services it says "IETF transport = protocols and congestion control mechanisms" in the third bullet on providing services it says "IETF transports". Should the third bullet not also be = "IETF transports and congestion control mechanisms" to be consistent? (Alternatively the first bullet should be = revised.)

Not 100% sure = which bullet you mean, but I think anyway the answer is no: the first is = about identifying services, the third (deliverable / milestone) is about = how to provide them. You need a protocol to provide a = service.


=20 Also, you lost some text (or missed to remove): "The Working Group will coordinate closely with = groups."

Fixed

Coordination is not = just important with other Working Groups, but with possible Research = Groups in the IRTF as well, since lots of things we suspect we want to = do but which aren't cooked enough to do engineering on yet could be = referred to a future = RG.

Cheers,

Brian
<= div>

Cheers,
Michael

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

= --Apple-Mail=_681437B3-7ECA-40DE-8E77-62958C68D020-- --Apple-Mail=_8BB0D832-E1B6-4FD9-BB12-376C058577DC 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 iQEcBAEBCgAGBQJThYhiAAoJENt3nsOmbNJck88H/RHuhAYY23Hz4vEPa1HidzKf kMTAQg+Dy6HgJKbJecWi919ZK7dCWIM3FMjn7S2x2+WiFros6bAcP5X+J0fGpRMP Td1CxtnaXyxbl6p+dm/7AHe6utkvZHHTbpqIc9lYbvufeNyOUFQWM10hJOrUYkQP RRDCa6aWsau8msAWQGEf7PVKFKqYr0+hPlSGt+ra6fgB9dEkJ1dc+wGS2tcDLZhc dOIsNTnq4zxlVDMheElY5khLxsK9ttdhqThTLRunwHjZ3kbyujv4w1bFmnRYzDdV hQ1kdFI4zFsNfI7gGOf66KzLC5Z88OA/RpdeyNCaypzQBPk1EbX0ZQTAcbT7FCo= =agqa -----END PGP SIGNATURE----- --Apple-Mail=_8BB0D832-E1B6-4FD9-BB12-376C058577DC-- From nobody Wed May 28 00:59:05 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFF11A07D2 for ; Wed, 28 May 2014 00:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 fS6YjNOdNQmj for ; Wed, 28 May 2014 00:59:02 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6051B1A03B1 for ; Wed, 28 May 2014 00:59:02 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id z60so16469346qgd.37 for ; Wed, 28 May 2014 00:58:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=15832dUGd8VujcwwlS1ZWmNG0UJWrZLvhnD/SUERaB0=; b=KNG9D6RB3JaSeRRvULLKvaaweAqTbaqGqLmF4bg09p5eXgfmBfea0JB8LnO/sJDYjh 30+8ZFj7B6/hfGEOENo8LzHkiFSbAER60y0f5s6VPWE4ZT0UdVgzR9DK4nlDcaa65jpB aE9hOAWkYUfW9QUAQBxUBLd1Salt8Em5X6xcw6OeSFs/RAPj3js2YwCG1oCa9aJ6L198 Gwd7SB0XZfYyc/bwsd/2TqJIpF7G2E/2ZWRY5HoHenLHOK3WfYJwVbOkt2uRJfsTxTK2 m3m4XghzudWTkwNZFkcJmrPsoz8HgacntlO9hG3IteHmoxdVmRwiYxKm4wDVKcdG5Bz5 gjFA== MIME-Version: 1.0 X-Received: by 10.224.66.193 with SMTP id o1mr51357209qai.43.1401263938426; Wed, 28 May 2014 00:58:58 -0700 (PDT) Sender: crowcroft@gmail.com Received: by 10.140.48.14 with HTTP; Wed, 28 May 2014 00:58:58 -0700 (PDT) In-Reply-To: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> Date: Wed, 28 May 2014 08:58:58 +0100 X-Google-Sender-Auth: M3L6gNKYfBcYIG-uQKLHvdFQ8Uc Message-ID: From: Jon Crowcroft To: Michael Welzl Content-Type: multipart/alternative; boundary=001a11c2c0d4495ae704fa712ff8 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/WYO7MxsK7lGlRJ1XKpj2bH2yYJQ Cc: taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 07:59:04 -0000 --001a11c2c0d4495ae704fa712ff8 Content-Type: text/plain; charset=UTF-8 so good in general & +1 to Anna's comments, but also the "work" is all about discovering what protocol services might be available - shouldn't there be at least a stab at how to "select or engage" one (or more) appropriately? I mean knowing how to speak 3 languages is fine, but not being able to choose which one to speak when trying to talk to someone is a bit, err, dumbing down:) my 3 zlotys On Tue, May 27, 2014 at 8:38 PM, Michael Welzl wrote: > Hi all, > > Following up on this, please take a look at: > https://sites.google.com/site/transportprotocolservices/charter-proposal > > I'd like to suggest this as a way forward to the group; could you support > this as a Charter for forming a WG? > > I think it's clear to all of us that there should be more work beyond > this, but it is important that the initial goals are clear and attainable. > Work beyond could take various forms, in various places - note how Spencer > wrote "We'll find venues for work that needs to happen". This new proposed > charter is about having a common starting point that we all can agree on. > > Cheers, > Michael > > > > On 27. mai 2014, at 16:11, Michael Welzl wrote: > > > Thanks a lot Spencer! > > > > TAPS: please stay tuned for a first proposal coming from me very soon - > this incorporates some prior discussion that we probably don't want to > re-iterate and wouldn't want to incorporate in the current charter - you > heard the man: "a minimal charter that we could approve quickly", so this > is about removing things that we wanted to do from *this* charter, and > hoping / expecting that they will be dealt with elsewhere. > > > > Cheers > > Michael > > > > > > > > On 27. mai 2014, at 15:53, Spencer Dawkins wrote: > > > >> So, it may be useful for me to chime in here. I'm speaking only as > 1/16th of the IESG, of course. > >> > >> I thought the TAPS BoF in London was very helpful, and the IESG and IAB > spent a significant amount of time talking about what happened at the BoF > (thanks to Michael and Murray for capable chairing, and to Michael for > producing near-verbatim minutes from the recorded audio), both at the "week > in review" session on Friday afternoon after IETF 89, and at the joint > IESG/IAB retreat a couple of weeks ago. > >> > >> There's a lot to talk about, and the folks who observed that IETF > working groups are a lousy place to talk about things, especially at > charter time, are dead-on. > >> > >> So what I'm asking, is that people take a shot at proposing a minimal > charter that we could approve quickly (and maybe without a BOF - they > aren't required, and we're trying to make it easier for people to start > work). > >> > >> We'll find venues for work that needs to happen, whether in IETF > working groups, in IRTF research groups, or as Independent Submissions, and > I'm happy to sponsor mailing lists for various chunks of this work as you > identify them, so you don't have to have one big conversation about the > Answer to Life, the Universe, and Everything (c). > >> > >> So please, talk amongst yourselves, and see what you can agree on :-) > >> > >> Spencer > >> > >> On 05/27/2014 02:32 AM, Jon Crowcroft wrote: > >>> totally agree - I think generalized pattern approach is really nice, > and we tried using it in the "building blocks" structure that was used in > the RMT group - i think quite successfully > >>> > >>> however, patterns (and RMT consierations too) are over-reach for TAPS, > in my opinion....life's too short to get something done that new, big, and > complex (and contentious in some quarters) > >> > >> _______________________________________________ > >> 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 > --001a11c2c0d4495ae704fa712ff8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
so good in general & +1 to Anna's comments, but al= so
the "work" is all about discovering what protocol services= might be available - shouldn't there be at least a stab at how to &quo= t;select or engage" one (or more) appropriately? I mean knowing how to= speak 3 languages is fine, but not being able to choose which one to speak= when trying to talk to someone is a bit, err, dumbing down:)

my 3 zlotys

<= br>
On Tue, May 27, 2014 at 8:38 PM, Michael Welz= l <michawe@ifi.uio.no> wrote:
Hi all,

Following up on this, please take a look at:
https://sites.google.com/site/transportprotocol= services/charter-proposal

I'd like to suggest this as a way forward to the group; could you suppo= rt this as a Charter for forming a WG?

I think it's clear to all of us that there should be more work beyond t= his, but it is important that the initial goals are clear and attainable. W= ork beyond could take various forms, in various places - note how Spencer w= rote "We'll find venues for work that needs to happen". This = new proposed charter is about having a common starting point that we all ca= n agree on.

Cheers,
Michael



On 27. mai 2014, at 16:11, Michael Welzl <michawe@ifi.uio.no> wrote:

> Thanks a lot Spencer!
>
> TAPS: please stay tuned for a first proposal coming from me very soon = - this incorporates some prior discussion that we probably don't want t= o re-iterate and wouldn't want to incorporate in the current charter - = you heard the man: "a minimal charter that we could approve quickly&qu= ot;, so this is about removing things that we wanted to do from *this* char= ter, and hoping / expecting that they will be dealt with elsewhere.
>
> Cheers
> Michael
>
>
>
> On 27. mai 2014, at 15:53, Spencer Dawkins wrote:
>
>> So, it may be useful for me to chime in here. I'm speaking onl= y as 1/16th of the IESG, of course.
>>
>> I thought the TAPS BoF in London was very helpful, and the IESG an= d IAB spent a significant amount of time talking about what happened at the= BoF (thanks to Michael and Murray for capable chairing, and to Michael for= producing near-verbatim minutes from the recorded audio), both at the &quo= t;week in review" session on Friday afternoon after IETF 89, and at th= e joint IESG/IAB retreat a couple of weeks ago.
>>
>> There's a lot to talk about, and the folks who observed that I= ETF working groups are a lousy place to talk about things, especially at ch= arter time, are dead-on.
>>
>> So what I'm asking, is that people take a shot at proposing a = minimal charter that we could approve quickly (and maybe without a BOF - th= ey aren't required, and we're trying to make it easier for people t= o start work).
>>
>> We'll find venues for work that needs to happen, whether in IE= TF working groups, in IRTF research groups, or as Independent Submissions, = and I'm happy to sponsor mailing lists for various chunks of this work = as you identify them, so you don't have to have one big conversation ab= out the Answer to Life, the Universe, and Everything (c).
>>
>> So please, talk amongst yourselves, and see what you can agree on = :-)
>>
>> Spencer
>>
>> On 05/27/2014 02:32 AM, Jon Crowcroft wrote:
>>> totally agree - I think generalized pattern approach is really= nice, and we tried using it in the "building blocks" structure t= hat was used in the RMT group - i think quite successfully
>>>
>>> however, patterns (and RMT consierations too) are over-reach f= or TAPS, in my opinion....life's too short to get something done that n= ew, big, and complex (and contentious in some quarters)
>>
>> _______________________________________________
>> 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

--001a11c2c0d4495ae704fa712ff8-- From nobody Wed May 28 01:12: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 208DE1A081A for ; Wed, 28 May 2014 01:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fi6cmgKRZXNN for ; Wed, 28 May 2014 01:12:31 -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 B037D1A01D2 for ; Wed, 28 May 2014 01:12:30 -0700 (PDT) X-AuditID: 1209190f-f790b6d000000c38-00-53859a6acc02 Received: from mailhub-1.mit.edu ( [18.9.21.34]) (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 A9.53.03128.A6A95835; Wed, 28 May 2014 04:12:26 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-1.mit.edu [18.9.28.12]) by mailhub-1.mit.edu (8.13.8/8.9.2) with ESMTP id s4S8CONP018796; Wed, 28 May 2014 04:12:25 -0400 Received: from webmail-10.mit.edu (webmail-10.mit.edu [18.9.23.20]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s4S8CM28015236; Wed, 28 May 2014 04:12:23 -0400 Received: from webmail-10.mit.edu (webmail-10.mit.edu [127.0.0.1]) by webmail-10.mit.edu (8.13.8) with ESMTP id s4S8CMtH025168; Wed, 28 May 2014 04:12:22 -0400 Received: (from nobody@localhost) by webmail-10.mit.edu (8.13.8/8.13.8/Submit) id s4S8CKO5025152; Wed, 28 May 2014 04:12:20 -0400 X-Authentication-Warning: webmail-10.mit.edu: nobody set sender to mariejo@mit.edu using -f Received: from hakea3.isae.fr (hakea3.isae.fr [193.54.120.34]) (User authenticated as mariejo@ATHENA.MIT.EDU) by webmail.mit.edu (Horde MIME library) with HTTP; Wed, 28 May 2014 04:12:20 -0400 Message-ID: <20140528041220.jwx96kmu8gwg44sc@webmail.mit.edu> Date: Wed, 28 May 2014 04:12:20 -0400 From: Marie-Jose Montpetit To: Jon Crowcroft References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJKsWRmVeSWpSXmKPExsUixCmqpJs1qzXY4MB0eYsHF58wWfw4u5PV 4k6MA7PH1tbjLB5Llvxk8li9+iFzAHMUl01Kak5mWWqRvl0CV8b3U8eYCh4qVSx+1crWwHhH uouRk0NCwETi3IIZbBC2mMSFe+uBbC4OIYFpTBJvzuxmgnCWM0pc3NfAClIlJLCWUeL7Ty4I eyGjxJnbwRBFrYwSR7tnM0GMipZYP30dC0TiGKPE0msXwBK8ArYSG5d8ZASxWQRUJU5u3wcW ZxPQkfh0aCrYHSICehJPNr9mB7GZBUwl9p44CRYXFtCXmHVkPtR9HawSW369ATuJUyBI4uGd JVALBCVOznzCAtHsKPG3txmogQPIlpZY/o8DIiwvsf3tHGYQW1TAXOLB3h2MExjFZiHpnoWk exZC9ywk3QsYWVYxyqbkVunmJmbmFKcm6xYnJ+blpRbpmujlZpbopaaUbmIEx5gk/w7GbweV DjEKcDAq8fBKLGsJFmJNLCuuzD3EKMnBpCTK+7ilNViILyk/pTIjsTgjvqg0J7X4EKMEB7OS CG9zJ1CONyWxsiq1KB8mJc3BoiTO+9baKlhIID2xJDU7NbUgtQgmK8PBoSTB6zQTqFGwKDU9 tSItM6cEIc3EwQkynAdo+N0ZIMOLCxJzizPTIfKnGBWlxHlPgSQEQBIZpXlwvbAU+IpRHOgV Yd5UkBU8wPQJ1/0KaDAT0OAnYFcXlyQipKQaGBdI1u57uqcohdXo1ROLpo297slViVI89yUS 5US/uez9tW/ZPlVxxor7ofv1Fa90mJRNvJHX06j+avFeic/s16YzNfC8WbDtf90rlcALbyK4 5rK93KvuWDTDpsXvgAP79yL3jdf5/dUTCnO+bjqksrogeq/AH4vQk43NArcNQ1W5v7CotCy7 o8RSnJFoqMVcVJwIAK5HXxNcAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/taps/cmsTR3iATqoF_hUMH0cX4cyQROE Cc: Michael Welzl , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 08:12:33 -0000 I agree with the charter and Anna's comments but as John mentioned there should be a stab at suggesting a solution. /mjm Quoting Jon Crowcroft : > so good in general & +1 to Anna's comments, but also > the "work" is all about discovering what protocol services might be > available - shouldn't there be at least a stab at how to "select or engage" > one (or more) appropriately? I mean knowing how to speak 3 languages is > fine, but not being able to choose which one to speak when trying to talk > to someone is a bit, err, dumbing down:) > > my 3 zlotys > > > On Tue, May 27, 2014 at 8:38 PM, Michael Welzl wrote: > >> Hi all, >> >> Following up on this, please take a look at: >> https://sites.google.com/site/transportprotocolservices/charter-proposal >> >> I'd like to suggest this as a way forward to the group; could you support >> this as a Charter for forming a WG? >> >> I think it's clear to all of us that there should be more work beyond >> this, but it is important that the initial goals are clear and attainable. >> Work beyond could take various forms, in various places - note how Spencer >> wrote "We'll find venues for work that needs to happen". This new proposed >> charter is about having a common starting point that we all can agree on. >> >> Cheers, >> Michael >> >> >> >> On 27. mai 2014, at 16:11, Michael Welzl wrote: >> >> > Thanks a lot Spencer! >> > >> > TAPS: please stay tuned for a first proposal coming from me very soon - >> this incorporates some prior discussion that we probably don't want to >> re-iterate and wouldn't want to incorporate in the current charter - you >> heard the man: "a minimal charter that we could approve quickly", so this >> is about removing things that we wanted to do from *this* charter, and >> hoping / expecting that they will be dealt with elsewhere. >> > >> > Cheers >> > Michael >> > >> > >> > >> > On 27. mai 2014, at 15:53, Spencer Dawkins wrote: >> > >> >> So, it may be useful for me to chime in here. I'm speaking only as >> 1/16th of the IESG, of course. >> >> >> >> I thought the TAPS BoF in London was very helpful, and the IESG and IAB >> spent a significant amount of time talking about what happened at the BoF >> (thanks to Michael and Murray for capable chairing, and to Michael for >> producing near-verbatim minutes from the recorded audio), both at the "week >> in review" session on Friday afternoon after IETF 89, and at the joint >> IESG/IAB retreat a couple of weeks ago. >> >> >> >> There's a lot to talk about, and the folks who observed that IETF >> working groups are a lousy place to talk about things, especially at >> charter time, are dead-on. >> >> >> >> So what I'm asking, is that people take a shot at proposing a minimal >> charter that we could approve quickly (and maybe without a BOF - they >> aren't required, and we're trying to make it easier for people to start >> work). >> >> >> >> We'll find venues for work that needs to happen, whether in IETF >> working groups, in IRTF research groups, or as Independent Submissions, and >> I'm happy to sponsor mailing lists for various chunks of this work as you >> identify them, so you don't have to have one big conversation about the >> Answer to Life, the Universe, and Everything (c). >> >> >> >> So please, talk amongst yourselves, and see what you can agree on :-) >> >> >> >> Spencer >> >> >> >> On 05/27/2014 02:32 AM, Jon Crowcroft wrote: >> >>> totally agree - I think generalized pattern approach is really nice, >> and we tried using it in the "building blocks" structure that was used in >> the RMT group - i think quite successfully >> >>> >> >>> however, patterns (and RMT consierations too) are over-reach for TAPS, >> in my opinion....life's too short to get something done that new, big, and >> complex (and contentious in some quarters) >> >> >> >> _______________________________________________ >> >> Taps mailing list >> >> Taps@ietf.org >> >> https://www.ietf.org/mailman/listinfo/taps >> > >> > _______________________________________________ >> > Taps mailing list >> > Taps@ietf.org >> > https://www.ietf.org/mailman/listinfo/taps >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >> > From nobody Wed May 28 01:17:01 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 AFCE61A01F2 for ; Wed, 28 May 2014 01:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxHwyOQwlX-v for ; Wed, 28 May 2014 01:16:57 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8041A01D2 for ; Wed, 28 May 2014 01:16:56 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WpZ2Y-000560-9z; Wed, 28 May 2014 10:16:50 +0200 Received: from [128.65.80.89] by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WpZ2W-00057E-3P; Wed, 28 May 2014 10:16:50 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <20140528041220.jwx96kmu8gwg44sc@webmail.mit.edu> Date: Wed, 28 May 2014 10:16:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <20140528041220.jwx96kmu8gwg44sc@webmail.mit.edu> To: Marie-Jose Montpetit X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 3 sum rcpts/h 7 sum msgs/h 4 total rcpts 16862 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 82E449838E343AF030EAA6B49D977C430729454F X-UiO-SPAM-Test: remote_host: 128.65.80.89 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 2 max/h 2 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/FG38s55Ws-wREYspWZaiVK0jmDY Cc: Jon Crowcroft , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 08:16:59 -0000 So, first things first: everyone seems to agree with Anna, but what = about my negative response to her comment about making the bullets = consistent? It makes sense to identify services provided by transport protocols & = congestion control mechanisms. I don't think it makes sense to specify = how services can be provided using ... congestion control mechanisms, as = cc. mechanisms need to be implemented within a transport protocol, of = which they are a (sometimes configurable) part. You need a protocol to = provide a service. Agreed? (sure, this is just a nit, but I don't want to go against the general = perception here) On 28. mai 2014, at 10:12, Marie-Jose Montpetit wrote: > I agree with the charter and Anna's comments but as John mentioned = there should > be a stab at suggesting a solution. >=20 > /mjm >=20 >=20 > Quoting Jon Crowcroft : >=20 >> so good in general & +1 to Anna's comments, but also >> the "work" is all about discovering what protocol services might be >> available - shouldn't there be at least a stab at how to "select or = engage" >> one (or more) appropriately? I mean knowing how to speak 3 languages = is >> fine, but not being able to choose which one to speak when trying to = talk >> to someone is a bit, err, dumbing down:) >>=20 >> my 3 zlotys >>=20 >>=20 >> On Tue, May 27, 2014 at 8:38 PM, Michael Welzl = wrote: >>=20 >>> Hi all, >>>=20 >>> Following up on this, please take a look at: >>> = https://sites.google.com/site/transportprotocolservices/charter-proposal >>>=20 >>> I'd like to suggest this as a way forward to the group; could you = support >>> this as a Charter for forming a WG? >>>=20 >>> I think it's clear to all of us that there should be more work = beyond >>> this, but it is important that the initial goals are clear and = attainable. >>> Work beyond could take various forms, in various places - note how = Spencer >>> wrote "We'll find venues for work that needs to happen". This new = proposed >>> charter is about having a common starting point that we all can = agree on. >>>=20 >>> Cheers, >>> Michael >>>=20 >>>=20 >>>=20 >>> On 27. mai 2014, at 16:11, Michael Welzl wrote: >>>=20 >>> > Thanks a lot Spencer! >>> > >>> > TAPS: please stay tuned for a first proposal coming from me very = soon - >>> this incorporates some prior discussion that we probably don't want = to >>> re-iterate and wouldn't want to incorporate in the current charter - = you >>> heard the man: "a minimal charter that we could approve quickly", so = this >>> is about removing things that we wanted to do from *this* charter, = and >>> hoping / expecting that they will be dealt with elsewhere. >>> > >>> > Cheers >>> > Michael >>> > >>> > >>> > >>> > On 27. mai 2014, at 15:53, Spencer Dawkins wrote: >>> > >>> >> So, it may be useful for me to chime in here. I'm speaking only = as >>> 1/16th of the IESG, of course. >>> >> >>> >> I thought the TAPS BoF in London was very helpful, and the IESG = and IAB >>> spent a significant amount of time talking about what happened at = the BoF >>> (thanks to Michael and Murray for capable chairing, and to Michael = for >>> producing near-verbatim minutes from the recorded audio), both at = the "week >>> in review" session on Friday afternoon after IETF 89, and at the = joint >>> IESG/IAB retreat a couple of weeks ago. >>> >> >>> >> There's a lot to talk about, and the folks who observed that IETF >>> working groups are a lousy place to talk about things, especially at >>> charter time, are dead-on. >>> >> >>> >> So what I'm asking, is that people take a shot at proposing a = minimal >>> charter that we could approve quickly (and maybe without a BOF - = they >>> aren't required, and we're trying to make it easier for people to = start >>> work). >>> >> >>> >> We'll find venues for work that needs to happen, whether in IETF >>> working groups, in IRTF research groups, or as Independent = Submissions, and >>> I'm happy to sponsor mailing lists for various chunks of this work = as you >>> identify them, so you don't have to have one big conversation about = the >>> Answer to Life, the Universe, and Everything (c). >>> >> >>> >> So please, talk amongst yourselves, and see what you can agree on = :-) >>> >> >>> >> Spencer >>> >> >>> >> On 05/27/2014 02:32 AM, Jon Crowcroft wrote: >>> >>> totally agree - I think generalized pattern approach is really = nice, >>> and we tried using it in the "building blocks" structure that was = used in >>> the RMT group - i think quite successfully >>> >>> >>> >>> however, patterns (and RMT consierations too) are over-reach for = TAPS, >>> in my opinion....life's too short to get something done that new, = big, and >>> complex (and contentious in some quarters) >>> >> >>> >> _______________________________________________ >>> >> Taps mailing list >>> >> Taps@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/taps >>> > >>> > _______________________________________________ >>> > Taps mailing list >>> > Taps@ietf.org >>> > https://www.ietf.org/mailman/listinfo/taps >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>>=20 >>=20 >=20 >=20 From nobody Wed May 28 01:22:01 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 710B61A01F2 for ; Wed, 28 May 2014 01:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgjX3JEOAGHu for ; Wed, 28 May 2014 01:21:58 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91AE41A01D2 for ; Wed, 28 May 2014 01:21:57 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WpZ7Q-0000Ec-AR; Wed, 28 May 2014 10:21:52 +0200 Received: from [128.65.80.89] by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WpZ7I-0007DL-17; Wed, 28 May 2014 10:21:52 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_BE9C4F84-15EA-46B7-BE3B-1E74773BEB4F" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <23240F18-975F-48DF-959B-9CD84D4BB43A@trammell.ch> Date: Wed, 28 May 2014 10:21:31 +0200 Message-Id: <3ED0B5A7-E59E-44F7-B079-C27BE6F862A3@ifi.uio.no> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <5384F201.3050508@kau.se> <6435044C-C17F-4B37-937C-73E1B8C0DE9D@ifi.uio.no> <23240F18-975F-48DF-959B-9CD84D4BB43A@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 4 sum rcpts/h 10 sum msgs/h 5 total rcpts 16865 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: D56BD7C123D611EA6E3BEC1AB59B6C3433CBD292 X-UiO-SPAM-Test: remote_host: 128.65.80.89 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 3 max/h 3 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/xsaHlzqF8C0VOzXbJYfPM2DYFso Cc: Anna Brunstrom , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 08:22:00 -0000 --Apple-Mail=_BE9C4F84-15EA-46B7-BE3B-1E74773BEB4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 28. mai 2014, at 08:55, Brian Trammell wrote: > hi Michael, >=20 > +1 to everything Anna said; the present proposal strikes a good = balance between what can be immediately useful in this space and what we = already know how to do. I would make one point on your edit, though... >=20 > On 28 May 2014, at 08:35, Michael Welzl wrote: >=20 >> Hi, >>=20 >>=20 >> On 27. mai 2014, at 22:13, Anna Brunstrom = wrote: >>=20 >>> Hi Michael, >>>=20 >>> I agree with your proposal as a good common starting point.=20 >>=20 >> Great! Others - in case you also agree, please say it out loud too - = I think we want to get a general idea of the group's perception as soon = as possible now. >>=20 >>=20 >>> One detail on the deliverables: In the first bullet identifying = available services it says "IETF transport protocols and congestion = control mechanisms" in the third bullet on providing services it says = "IETF transports". Should the third bullet not also be "IETF transports = and congestion control mechanisms" to be consistent? (Alternatively the = first bullet should be revised.) >>=20 >> Not 100% sure which bullet you mean, but I think anyway the answer is = no: the first is about identifying services, the third (deliverable / = milestone) is about how to provide them. You need a protocol to provide = a service. >>=20 >>=20 >>> Also, you lost some text (or missed to remove): "The Working Group = will coordinate closely with groups." >>=20 >> Fixed >=20 > Coordination is not just important with other Working Groups, but with = possible Research Groups in the IRTF as well, since lots of things we = suspect we want to do but which aren't cooked enough to do engineering = on yet could be referred to a future RG. done, I added: "and/or IRTF Research Groups". This strikes me as a good opportunity to mention a detail that is easily = missed: the charter of IRTF ICCRG includes: "Because congestion control is typically a key function of transport = protocols, it is hard to separate other transport layer issues from = congestion control. Considerations for deployment of transport protocols = are therefore also considered within scope. " Not many documents are published via ICCRG, we currently function more = like a forum for presentations of things that are not ready for the IETF = yet. With ICCRG chair hat on, TAPS-related work would be very welcome in = ICCRG, if only to provide a forum until a dedicated RG exists (if that = really should be needed, i.e. if ICCRG couldn't generally fill that gap? = I think that in ICCRG, the right people are already on the list and in = the room when we meet). Cheers, Michael --Apple-Mail=_BE9C4F84-15EA-46B7-BE3B-1E74773BEB4F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On 28. mai 2014, at 08:55, Brian = Trammell <ietf@trammell.ch> = wrote:

hi Michael,

+1 to everything Anna = said; the present proposal strikes a good balance between what can be = immediately useful in this space and what we already know how to do. I = would make one point on your edit, = though...

On 28 May 2014, at 08:35, = Michael Welzl <michawe@ifi.uio.no> = wrote:

Hi,


On 27. mai = 2014, at 22:13, Anna Brunstrom <anna.brunstrom@kau.se> = wrote:

Hi = Michael,

I agree with your proposal as a good common starting = point. 
<= br>
Great!  Others - in case you also agree, please say it out = loud too - I think we want to get a general idea of the group's = perception as soon as possible = now.


One detail on the deliverables: In = the first bullet identifying available services it says "IETF transport = protocols and congestion control mechanisms" in the third bullet on = providing services it says "IETF transports". Should the third bullet = not also be "IETF transports and congestion control mechanisms" to be = consistent? (Alternatively the first bullet should be = revised.)

Not 100% sure = which bullet you mean, but I think anyway the answer is no: the first is = about identifying services, the third (deliverable / milestone) is about = how to provide them. You need a protocol to provide a = service.


Also, you = lost some text (or missed to = remove): "The Working Group will coordinate closely with = groups."

Fixed

Coordination is not = just important with other Working Groups, but with possible Research = Groups in the IRTF as well, since lots of things we suspect we want to = do but which aren't cooked enough to do engineering on yet could be = referred to a future = RG.

done, I added: "and/or = IRTF Research Groups".

This strikes me as a = good opportunity to mention a detail that is easily missed: the charter = of IRTF ICCRG includes:
"Because congestion control is = typically a key function of transport protocols, it is hard to separate = other transport layer issues from congestion control. = Considerations for deployment of transport protocols are therefore also = considered within scope. "

Not many documents = are published via ICCRG, we currently function more like a forum for = presentations of things that are not ready for the IETF yet. With ICCRG = chair hat on, TAPS-related work would be very welcome in ICCRG, if only = to provide a forum until a dedicated RG exists (if that really should be = needed, i.e. if ICCRG couldn't generally fill that gap? I think that in = ICCRG, the right people are already on the list and in the room when we = meet).

Cheers,
Michael

= --Apple-Mail=_BE9C4F84-15EA-46B7-BE3B-1E74773BEB4F-- From nobody Wed May 28 01:28:18 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 255BD1A087D for ; Wed, 28 May 2014 01:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pkhdHFG4VSr for ; Wed, 28 May 2014 01:28:15 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FD771A03D3 for ; Wed, 28 May 2014 01:28:15 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WpZDU-0006i3-Vw; Wed, 28 May 2014 10:28:08 +0200 Received: from [128.65.80.89] by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1WpZDT-0008PI-6y; Wed, 28 May 2014 10:28:08 +0200 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <20140528041220.jwx96kmu8gwg44sc@webmail.mit.edu> Date: Wed, 28 May 2014 10:27:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <20140528041220.jwx96kmu8gwg44sc@webmail.mit.edu> To: Marie-Jose Montpetit X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 12 msgs/h 5 sum rcpts/h 13 sum msgs/h 6 total rcpts 16868 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 3AF3839704085873FE29D3C899C342C25A46242E X-UiO-SPAM-Test: remote_host: 128.65.80.89 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 4 max/h 4 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/o0woT2J9qFBcM8TWilYk7afklrU Cc: Jon Crowcroft , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 08:28:17 -0000 So - maybe this is just me being stupid, but are we talking about = "selecting and engaging" a protocol or a service here, i.e. something = "under the hood" or a guidance document that says "for this, you want = that" ? Actual wording suggestions are very welcome :) On 28. mai 2014, at 10:12, Marie-Jose Montpetit wrote: > I agree with the charter and Anna's comments but as John mentioned = there should > be a stab at suggesting a solution. >=20 > /mjm >=20 >=20 > Quoting Jon Crowcroft : >=20 >> so good in general & +1 to Anna's comments, but also >> the "work" is all about discovering what protocol services might be >> available - shouldn't there be at least a stab at how to "select or = engage" >> one (or more) appropriately? I mean knowing how to speak 3 languages = is >> fine, but not being able to choose which one to speak when trying to = talk >> to someone is a bit, err, dumbing down:) >>=20 >> my 3 zlotys >>=20 >>=20 >> On Tue, May 27, 2014 at 8:38 PM, Michael Welzl = wrote: >>=20 >>> Hi all, >>>=20 >>> Following up on this, please take a look at: >>> = https://sites.google.com/site/transportprotocolservices/charter-proposal >>>=20 >>> I'd like to suggest this as a way forward to the group; could you = support >>> this as a Charter for forming a WG? >>>=20 >>> I think it's clear to all of us that there should be more work = beyond >>> this, but it is important that the initial goals are clear and = attainable. >>> Work beyond could take various forms, in various places - note how = Spencer >>> wrote "We'll find venues for work that needs to happen". This new = proposed >>> charter is about having a common starting point that we all can = agree on. >>>=20 >>> Cheers, >>> Michael >>>=20 >>>=20 >>>=20 >>> On 27. mai 2014, at 16:11, Michael Welzl wrote: >>>=20 >>> > Thanks a lot Spencer! >>> > >>> > TAPS: please stay tuned for a first proposal coming from me very = soon - >>> this incorporates some prior discussion that we probably don't want = to >>> re-iterate and wouldn't want to incorporate in the current charter - = you >>> heard the man: "a minimal charter that we could approve quickly", so = this >>> is about removing things that we wanted to do from *this* charter, = and >>> hoping / expecting that they will be dealt with elsewhere. >>> > >>> > Cheers >>> > Michael >>> > >>> > >>> > >>> > On 27. mai 2014, at 15:53, Spencer Dawkins wrote: >>> > >>> >> So, it may be useful for me to chime in here. I'm speaking only = as >>> 1/16th of the IESG, of course. >>> >> >>> >> I thought the TAPS BoF in London was very helpful, and the IESG = and IAB >>> spent a significant amount of time talking about what happened at = the BoF >>> (thanks to Michael and Murray for capable chairing, and to Michael = for >>> producing near-verbatim minutes from the recorded audio), both at = the "week >>> in review" session on Friday afternoon after IETF 89, and at the = joint >>> IESG/IAB retreat a couple of weeks ago. >>> >> >>> >> There's a lot to talk about, and the folks who observed that IETF >>> working groups are a lousy place to talk about things, especially at >>> charter time, are dead-on. >>> >> >>> >> So what I'm asking, is that people take a shot at proposing a = minimal >>> charter that we could approve quickly (and maybe without a BOF - = they >>> aren't required, and we're trying to make it easier for people to = start >>> work). >>> >> >>> >> We'll find venues for work that needs to happen, whether in IETF >>> working groups, in IRTF research groups, or as Independent = Submissions, and >>> I'm happy to sponsor mailing lists for various chunks of this work = as you >>> identify them, so you don't have to have one big conversation about = the >>> Answer to Life, the Universe, and Everything (c). >>> >> >>> >> So please, talk amongst yourselves, and see what you can agree on = :-) >>> >> >>> >> Spencer >>> >> >>> >> On 05/27/2014 02:32 AM, Jon Crowcroft wrote: >>> >>> totally agree - I think generalized pattern approach is really = nice, >>> and we tried using it in the "building blocks" structure that was = used in >>> the RMT group - i think quite successfully >>> >>> >>> >>> however, patterns (and RMT consierations too) are over-reach for = TAPS, >>> in my opinion....life's too short to get something done that new, = big, and >>> complex (and contentious in some quarters) >>> >> >>> >> _______________________________________________ >>> >> Taps mailing list >>> >> Taps@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/taps >>> > >>> > _______________________________________________ >>> > Taps mailing list >>> > Taps@ietf.org >>> > https://www.ietf.org/mailman/listinfo/taps >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>>=20 >>=20 >=20 >=20 From nobody Wed May 28 02:09:20 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF511A0032 for ; Wed, 28 May 2014 02:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cl7WjFuM3-p for ; Wed, 28 May 2014 02:09:17 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7764D1A0041 for ; Wed, 28 May 2014 02:09:17 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 835432B4258; Wed, 28 May 2014 10:09:13 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Wed, 28 May 2014 10:09:13 +0100 Message-ID: <2aa92313023c20b3243a500074e63a9d.squirrel@www.erg.abdn.ac.uk> In-Reply-To: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <20140528041220.jwx96kmu8gwg44sc@webmail.mit.edu> Date: Wed, 28 May 2014 10:09:13 +0100 From: gorry@erg.abdn.ac.uk To: "Michael Welzl" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/taps/db-uVq7HO8pKadixU49jkUY-s0I Cc: Jon Crowcroft , Marie-Jose Montpetit , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 09:09:20 -0000 Maybe I misunderstood, but I thought: "Informational RFC summarizing the services" was a little about guidance that says amongst things "for this, you want that" (if it is supported) and "Experimental RFC specifying how the defined transport services can be provided" was about "selecting and engaging" a protocol that will select and deliver a service in an actual network Gorry > So - maybe this is just me being stupid, but are we talking about > "selecting and engaging" a protocol or a service here, i.e. something > "under the hood" or a guidance document that says "for this, you want > that" ? > > Actual wording suggestions are very welcome :) > > > > On 28. mai 2014, at 10:12, Marie-Jose Montpetit wrote: > >> I agree with the charter and Anna's comments but as John mentioned there >> should >> be a stab at suggesting a solution. >> >> /mjm >> >> >> Quoting Jon Crowcroft : >> >>> so good in general & +1 to Anna's comments, but also >>> the "work" is all about discovering what protocol services might be >>> available - shouldn't there be at least a stab at how to "select or >>> engage" >>> one (or more) appropriately? I mean knowing how to speak 3 languages is >>> fine, but not being able to choose which one to speak when trying to >>> talk >>> to someone is a bit, err, dumbing down:) >>> >>> my 3 zlotys >>> >>> >>> On Tue, May 27, 2014 at 8:38 PM, Michael Welzl >>> wrote: >>> >>>> Hi all, >>>> >>>> Following up on this, please take a look at: >>>> https://sites.google.com/site/transportprotocolservices/charter-proposal >>>> >>>> I'd like to suggest this as a way forward to the group; could you >>>> support >>>> this as a Charter for forming a WG? >>>> >>>> I think it's clear to all of us that there should be more work beyond >>>> this, but it is important that the initial goals are clear and >>>> attainable. >>>> Work beyond could take various forms, in various places - note how >>>> Spencer >>>> wrote "We'll find venues for work that needs to happen". This new >>>> proposed >>>> charter is about having a common starting point that we all can agree >>>> on. >>>> >>>> Cheers, >>>> Michael >>>> >>>> >>>> >>>> On 27. mai 2014, at 16:11, Michael Welzl wrote: >>>> >>>> > Thanks a lot Spencer! >>>> > >>>> > TAPS: please stay tuned for a first proposal coming from me very >>>> soon - >>>> this incorporates some prior discussion that we probably don't want to >>>> re-iterate and wouldn't want to incorporate in the current charter - >>>> you >>>> heard the man: "a minimal charter that we could approve quickly", so >>>> this >>>> is about removing things that we wanted to do from *this* charter, and >>>> hoping / expecting that they will be dealt with elsewhere. >>>> > >>>> > Cheers >>>> > Michael >>>> > >>>> > >>>> > >>>> > On 27. mai 2014, at 15:53, Spencer Dawkins wrote: >>>> > >>>> >> So, it may be useful for me to chime in here. I'm speaking only as >>>> 1/16th of the IESG, of course. >>>> >> >>>> >> I thought the TAPS BoF in London was very helpful, and the IESG and >>>> IAB >>>> spent a significant amount of time talking about what happened at the >>>> BoF >>>> (thanks to Michael and Murray for capable chairing, and to Michael for >>>> producing near-verbatim minutes from the recorded audio), both at the >>>> "week >>>> in review" session on Friday afternoon after IETF 89, and at the joint >>>> IESG/IAB retreat a couple of weeks ago. >>>> >> >>>> >> There's a lot to talk about, and the folks who observed that IETF >>>> working groups are a lousy place to talk about things, especially at >>>> charter time, are dead-on. >>>> >> >>>> >> So what I'm asking, is that people take a shot at proposing a >>>> minimal >>>> charter that we could approve quickly (and maybe without a BOF - they >>>> aren't required, and we're trying to make it easier for people to >>>> start >>>> work). >>>> >> >>>> >> We'll find venues for work that needs to happen, whether in IETF >>>> working groups, in IRTF research groups, or as Independent >>>> Submissions, and >>>> I'm happy to sponsor mailing lists for various chunks of this work as >>>> you >>>> identify them, so you don't have to have one big conversation about >>>> the >>>> Answer to Life, the Universe, and Everything (c). >>>> >> >>>> >> So please, talk amongst yourselves, and see what you can agree on >>>> :-) >>>> >> >>>> >> Spencer >>>> >> >>>> >> On 05/27/2014 02:32 AM, Jon Crowcroft wrote: >>>> >>> totally agree - I think generalized pattern approach is really >>>> nice, >>>> and we tried using it in the "building blocks" structure that was used >>>> in >>>> the RMT group - i think quite successfully >>>> >>> >>>> >>> however, patterns (and RMT consierations too) are over-reach for >>>> TAPS, >>>> in my opinion....life's too short to get something done that new, big, >>>> and >>>> complex (and contentious in some quarters) >>>> >> >>>> >> _______________________________________________ >>>> >> Taps mailing list >>>> >> Taps@ietf.org >>>> >> https://www.ietf.org/mailman/listinfo/taps >>>> > >>>> > _______________________________________________ >>>> > Taps mailing list >>>> > Taps@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/taps >>>> >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>> >>> >> >> > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Wed May 28 02:28:51 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 DB7171A0897 for ; Wed, 28 May 2014 02:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgbzg9T_pu1y for ; Wed, 28 May 2014 02:28:41 -0700 (PDT) Received: from ppsw-40.csi.cam.ac.uk (ppsw-40-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f40]) (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 EA08C1A089A for ; Wed, 28 May 2014 02:28:40 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ravage.cl.cam.ac.uk ([128.232.1.17]:55251) by ppsw-40.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1Wpa9y-0008OG-jN (Exim 4.82_3-c0e5623) (return-path ); Wed, 28 May 2014 10:28:34 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=windows-1252 From: Toby Moncaster X-Priority: 3 (Normal) In-Reply-To: <2aa92313023c20b3243a500074e63a9d.squirrel@www.erg.abdn.ac.uk> Date: Wed, 28 May 2014 10:28:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <20140528041220.jwx96kmu8gwg44sc@webmail.mit.edu> <2aa92313023c20b3243a500074e63a9d.squirrel@www.erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.1878.2) Sender: "T. Moncaster" Archived-At: http://mailarchive.ietf.org/arch/msg/taps/W7nY-84Q0hmLDaPxMlvGhCNdNCg Cc: Marie-Jose Montpetit , Jon Crowcroft , Michael Welzl , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 09:28:47 -0000 What Gorry says seems to make sense, and perhaps should be made = explicit? Regarding the issue of apparent inconsistency between bullets one and = three. I think this highlights that one of the things we should be = seeking to do early on is disambiguate all the terminology relating to = transport protocols, transport mechanisms, congestion control = mechanisms, transport services, etc. Final point. Deliverable 2 =93Proposed Standard RFC specifying a set of = transport services that an end system should provide=94. We need to be = careful about this one. If it is going to be a proposed standard then = really it needs to specify some things as must provide. There is a = chance that we=92ll get complaints about using =93should=94 in the = bullet? I=92m assuming we are intending that this should look something = like RFC1812 Requirements for IPv4 Routers? But I may be wrong Toby On 28 May 2014, at 10:09, gorry@erg.abdn.ac.uk wrote: > Maybe I misunderstood, but I thought: >=20 > "Informational RFC summarizing the services" was a little about = guidance > that says amongst things "for this, you want that" (if it is = supported) >=20 > and >=20 > "Experimental RFC specifying how the defined transport services can be > provided" was about "selecting and engaging" a protocol that will = select > and deliver a service in an actual network >=20 > Gorry >=20 >> So - maybe this is just me being stupid, but are we talking about >> "selecting and engaging" a protocol or a service here, i.e. something >> "under the hood" or a guidance document that says "for this, you want >> that" ? >>=20 >> Actual wording suggestions are very welcome :) >>=20 >>=20 >>=20 >> On 28. mai 2014, at 10:12, Marie-Jose Montpetit = wrote: >>=20 >>> I agree with the charter and Anna's comments but as John mentioned = there >>> should >>> be a stab at suggesting a solution. >>>=20 >>> /mjm >>>=20 >>>=20 >>> Quoting Jon Crowcroft : >>>=20 >>>> so good in general & +1 to Anna's comments, but also >>>> the "work" is all about discovering what protocol services might be >>>> available - shouldn't there be at least a stab at how to "select or >>>> engage" >>>> one (or more) appropriately? I mean knowing how to speak 3 = languages is >>>> fine, but not being able to choose which one to speak when trying = to >>>> talk >>>> to someone is a bit, err, dumbing down:) >>>>=20 >>>> my 3 zlotys >>>>=20 >>>>=20 >>>> On Tue, May 27, 2014 at 8:38 PM, Michael Welzl >>>> wrote: >>>>=20 >>>>> Hi all, >>>>>=20 >>>>> Following up on this, please take a look at: >>>>> = https://sites.google.com/site/transportprotocolservices/charter-proposal >>>>>=20 >>>>> I'd like to suggest this as a way forward to the group; could you >>>>> support >>>>> this as a Charter for forming a WG? >>>>>=20 >>>>> I think it's clear to all of us that there should be more work = beyond >>>>> this, but it is important that the initial goals are clear and >>>>> attainable. >>>>> Work beyond could take various forms, in various places - note how >>>>> Spencer >>>>> wrote "We'll find venues for work that needs to happen". This new >>>>> proposed >>>>> charter is about having a common starting point that we all can = agree >>>>> on. >>>>>=20 >>>>> Cheers, >>>>> Michael >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 27. mai 2014, at 16:11, Michael Welzl = wrote: >>>>>=20 >>>>>> Thanks a lot Spencer! >>>>>>=20 >>>>>> TAPS: please stay tuned for a first proposal coming from me very >>>>> soon - >>>>> this incorporates some prior discussion that we probably don't = want to >>>>> re-iterate and wouldn't want to incorporate in the current charter = - >>>>> you >>>>> heard the man: "a minimal charter that we could approve quickly", = so >>>>> this >>>>> is about removing things that we wanted to do from *this* charter, = and >>>>> hoping / expecting that they will be dealt with elsewhere. >>>>>>=20 >>>>>> Cheers >>>>>> Michael >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 27. mai 2014, at 15:53, Spencer Dawkins wrote: >>>>>>=20 >>>>>>> So, it may be useful for me to chime in here. I'm speaking only = as >>>>> 1/16th of the IESG, of course. >>>>>>>=20 >>>>>>> I thought the TAPS BoF in London was very helpful, and the IESG = and >>>>> IAB >>>>> spent a significant amount of time talking about what happened at = the >>>>> BoF >>>>> (thanks to Michael and Murray for capable chairing, and to Michael = for >>>>> producing near-verbatim minutes from the recorded audio), both at = the >>>>> "week >>>>> in review" session on Friday afternoon after IETF 89, and at the = joint >>>>> IESG/IAB retreat a couple of weeks ago. >>>>>>>=20 >>>>>>> There's a lot to talk about, and the folks who observed that = IETF >>>>> working groups are a lousy place to talk about things, especially = at >>>>> charter time, are dead-on. >>>>>>>=20 >>>>>>> So what I'm asking, is that people take a shot at proposing a >>>>> minimal >>>>> charter that we could approve quickly (and maybe without a BOF - = they >>>>> aren't required, and we're trying to make it easier for people to >>>>> start >>>>> work). >>>>>>>=20 >>>>>>> We'll find venues for work that needs to happen, whether in IETF >>>>> working groups, in IRTF research groups, or as Independent >>>>> Submissions, and >>>>> I'm happy to sponsor mailing lists for various chunks of this work = as >>>>> you >>>>> identify them, so you don't have to have one big conversation = about >>>>> the >>>>> Answer to Life, the Universe, and Everything (c). >>>>>>>=20 >>>>>>> So please, talk amongst yourselves, and see what you can agree = on >>>>> :-) >>>>>>>=20 >>>>>>> Spencer >>>>>>>=20 >>>>>>> On 05/27/2014 02:32 AM, Jon Crowcroft wrote: >>>>>>>> totally agree - I think generalized pattern approach is really >>>>> nice, >>>>> and we tried using it in the "building blocks" structure that was = used >>>>> in >>>>> the RMT group - i think quite successfully >>>>>>>>=20 >>>>>>>> however, patterns (and RMT consierations too) are over-reach = for >>>>> TAPS, >>>>> in my opinion....life's too short to get something done that new, = big, >>>>> and >>>>> complex (and contentious in some quarters) >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Taps mailing list >>>>>>> Taps@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Taps mailing list >>>>>> Taps@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>=20 >>>>> _______________________________________________ >>>>> Taps mailing list >>>>> Taps@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >>=20 >=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed May 28 02:28:53 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007D41A088D for ; Wed, 28 May 2014 02:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 YChq4IdWfiN9 for ; Wed, 28 May 2014 02:28:49 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4F451A089E for ; Wed, 28 May 2014 02:28:43 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id q108so16428197qgd.5 for ; Wed, 28 May 2014 02:28:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=zyr+ozq80IRqlFBn7fqSPu+A3jWPrfgqa38S07eGCcs=; b=KhDUHsi31spO4il5us5L51e9E+j9lBium+uyKVy5GeeFXfZ1GOCDJP8rVfefDISvYo EHxzriHY5jOhgtfruhq/HXnTU9rsYcKFibdvyxbxzONESjFjMuZMlsnzyBpmDvz0Ezvf iiW7fq5iNVXA7dhg+Cf5p6daub37j/dgGDquD2AqS53LDpYGmFTeJ2VZ5eeTgUY0UiHv lZCAqN/c/bKRjyELx2ajB5CP4G5bOEpsDZSeFbehd5qKb9V0uz3dlEByoK4TFjNVuzH0 06k1/fb9yfPa10c643HohoZP3vS3x4DVxLxeAUy3JOD9TEVUdYhXI3kwVWr2g6O35YSl kmWw== MIME-Version: 1.0 X-Received: by 10.224.66.193 with SMTP id o1mr52071892qai.43.1401269319810; Wed, 28 May 2014 02:28:39 -0700 (PDT) Sender: crowcroft@gmail.com Received: by 10.140.48.14 with HTTP; Wed, 28 May 2014 02:28:39 -0700 (PDT) In-Reply-To: <2aa92313023c20b3243a500074e63a9d.squirrel@www.erg.abdn.ac.uk> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <20140528041220.jwx96kmu8gwg44sc@webmail.mit.edu> <2aa92313023c20b3243a500074e63a9d.squirrel@www.erg.abdn.ac.uk> Date: Wed, 28 May 2014 10:28:39 +0100 X-Google-Sender-Auth: 9B8mwa8IfkWRF0qP4vQsVSluoVo Message-ID: From: Jon Crowcroft To: Gorry Fairhurst Content-Type: multipart/alternative; boundary=001a11c2c0d40ac45104fa72703d Archived-At: http://mailarchive.ietf.org/arch/msg/taps/xCjmtuALySOkTTiy_y6RDQHilKc Cc: Marie-Jose Montpetit , Michael Welzl , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 09:28:52 -0000 --001a11c2c0d40ac45104fa72703d Content-Type: text/plain; charset=UTF-8 that sounds 100% ok to me On Wed, May 28, 2014 at 10:09 AM, wrote: > Maybe I misunderstood, but I thought: > > "Informational RFC summarizing the services" was a little about guidance > that says amongst things "for this, you want that" (if it is supported) > > and > > "Experimental RFC specifying how the defined transport services can be > provided" was about "selecting and engaging" a protocol that will select > and deliver a service in an actual network > > Gorry > > > So - maybe this is just me being stupid, but are we talking about > > "selecting and engaging" a protocol or a service here, i.e. something > > "under the hood" or a guidance document that says "for this, you want > > that" ? > > > > Actual wording suggestions are very welcome :) > > > > > > > > On 28. mai 2014, at 10:12, Marie-Jose Montpetit wrote: > > > >> I agree with the charter and Anna's comments but as John mentioned there > >> should > >> be a stab at suggesting a solution. > >> > >> /mjm > >> > >> > >> Quoting Jon Crowcroft : > >> > >>> so good in general & +1 to Anna's comments, but also > >>> the "work" is all about discovering what protocol services might be > >>> available - shouldn't there be at least a stab at how to "select or > >>> engage" > >>> one (or more) appropriately? I mean knowing how to speak 3 languages is > >>> fine, but not being able to choose which one to speak when trying to > >>> talk > >>> to someone is a bit, err, dumbing down:) > >>> > >>> my 3 zlotys > >>> > >>> > >>> On Tue, May 27, 2014 at 8:38 PM, Michael Welzl > >>> wrote: > >>> > >>>> Hi all, > >>>> > >>>> Following up on this, please take a look at: > >>>> > https://sites.google.com/site/transportprotocolservices/charter-proposal > >>>> > >>>> I'd like to suggest this as a way forward to the group; could you > >>>> support > >>>> this as a Charter for forming a WG? > >>>> > >>>> I think it's clear to all of us that there should be more work beyond > >>>> this, but it is important that the initial goals are clear and > >>>> attainable. > >>>> Work beyond could take various forms, in various places - note how > >>>> Spencer > >>>> wrote "We'll find venues for work that needs to happen". This new > >>>> proposed > >>>> charter is about having a common starting point that we all can agree > >>>> on. > >>>> > >>>> Cheers, > >>>> Michael > >>>> > >>>> > >>>> > >>>> On 27. mai 2014, at 16:11, Michael Welzl wrote: > >>>> > >>>> > Thanks a lot Spencer! > >>>> > > >>>> > TAPS: please stay tuned for a first proposal coming from me very > >>>> soon - > >>>> this incorporates some prior discussion that we probably don't want to > >>>> re-iterate and wouldn't want to incorporate in the current charter - > >>>> you > >>>> heard the man: "a minimal charter that we could approve quickly", so > >>>> this > >>>> is about removing things that we wanted to do from *this* charter, and > >>>> hoping / expecting that they will be dealt with elsewhere. > >>>> > > >>>> > Cheers > >>>> > Michael > >>>> > > >>>> > > >>>> > > >>>> > On 27. mai 2014, at 15:53, Spencer Dawkins wrote: > >>>> > > >>>> >> So, it may be useful for me to chime in here. I'm speaking only as > >>>> 1/16th of the IESG, of course. > >>>> >> > >>>> >> I thought the TAPS BoF in London was very helpful, and the IESG and > >>>> IAB > >>>> spent a significant amount of time talking about what happened at the > >>>> BoF > >>>> (thanks to Michael and Murray for capable chairing, and to Michael for > >>>> producing near-verbatim minutes from the recorded audio), both at the > >>>> "week > >>>> in review" session on Friday afternoon after IETF 89, and at the joint > >>>> IESG/IAB retreat a couple of weeks ago. > >>>> >> > >>>> >> There's a lot to talk about, and the folks who observed that IETF > >>>> working groups are a lousy place to talk about things, especially at > >>>> charter time, are dead-on. > >>>> >> > >>>> >> So what I'm asking, is that people take a shot at proposing a > >>>> minimal > >>>> charter that we could approve quickly (and maybe without a BOF - they > >>>> aren't required, and we're trying to make it easier for people to > >>>> start > >>>> work). > >>>> >> > >>>> >> We'll find venues for work that needs to happen, whether in IETF > >>>> working groups, in IRTF research groups, or as Independent > >>>> Submissions, and > >>>> I'm happy to sponsor mailing lists for various chunks of this work as > >>>> you > >>>> identify them, so you don't have to have one big conversation about > >>>> the > >>>> Answer to Life, the Universe, and Everything (c). > >>>> >> > >>>> >> So please, talk amongst yourselves, and see what you can agree on > >>>> :-) > >>>> >> > >>>> >> Spencer > >>>> >> > >>>> >> On 05/27/2014 02:32 AM, Jon Crowcroft wrote: > >>>> >>> totally agree - I think generalized pattern approach is really > >>>> nice, > >>>> and we tried using it in the "building blocks" structure that was used > >>>> in > >>>> the RMT group - i think quite successfully > >>>> >>> > >>>> >>> however, patterns (and RMT consierations too) are over-reach for > >>>> TAPS, > >>>> in my opinion....life's too short to get something done that new, big, > >>>> and > >>>> complex (and contentious in some quarters) > >>>> >> > >>>> >> _______________________________________________ > >>>> >> Taps mailing list > >>>> >> Taps@ietf.org > >>>> >> https://www.ietf.org/mailman/listinfo/taps > >>>> > > >>>> > _______________________________________________ > >>>> > Taps mailing list > >>>> > Taps@ietf.org > >>>> > https://www.ietf.org/mailman/listinfo/taps > >>>> > >>>> _______________________________________________ > >>>> Taps mailing list > >>>> Taps@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/taps > >>>> > >>> > >> > >> > > > > _______________________________________________ > > Taps mailing list > > Taps@ietf.org > > https://www.ietf.org/mailman/listinfo/taps > > > > > --001a11c2c0d40ac45104fa72703d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
that sounds 100% ok to me
=

On Wed, May 28, 2014 at 10:09 AM, <= gorry@erg.abdn.ac.uk> wrote:
Maybe I misunderstood, but I thought:

"Informational RFC summarizing the services" was a little about g= uidance
that says amongst things "for this, you want that" (if it is supp= orted)

and

"Experimental RFC specifying how the defined transport services can be=
provided" was about "selecting and engaging" a protocol that= will select
and deliver a service in an actual network

Gorry

> So - maybe this is just me being stupid, but are we talking about
> "selecting and engaging" a protocol or a service here, i.e. = something
> "under the hood" or a guidance document that says "for = this, you want
> that" ?
>
> Actual wording suggestions are very welcome =C2=A0 :)
>
>
>
> On 28. mai 2014, at 10:12, Marie-Jose Montpetit <mariejo@mit.edu> wrote:
>
>> I agree with the charter and Anna's comments but as John menti= oned there
>> should
>> be a stab at suggesting a solution.
>>
>> /mjm
>>
>>
>> Quoting Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk>:
>>
>>> so good in general & +1 to Anna's comments, but also >>> the "work" is all about discovering what protocol se= rvices might be
>>> available - shouldn't there be at least a stab at how to &= quot;select or
>>> engage"
>>> one (or more) appropriately? I mean knowing how to speak 3 lan= guages is
>>> fine, but not being able to choose which one to speak when try= ing to
>>> talk
>>> to someone is a bit, err, dumbing down:)
>>>
>>> my 3 zlotys
>>>
>>>
>>> On Tue, May 27, 2014 at 8:38 PM, Michael Welzl <michawe@ifi.uio.no>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Following up on this, please take a look at:
>>>> https://sites.google.com/site/= transportprotocolservices/charter-proposal
>>>>
>>>> I'd like to suggest this as a way forward to the group= ; could you
>>>> support
>>>> this as a Charter for forming a WG?
>>>>
>>>> I think it's clear to all of us that there should be m= ore work beyond
>>>> this, but it is important that the initial goals are clear= and
>>>> attainable.
>>>> Work beyond could take various forms, in various places - = note how
>>>> Spencer
>>>> wrote "We'll find venues for work that needs to h= appen". This new
>>>> proposed
>>>> charter is about having a common starting point that we al= l can agree
>>>> on.
>>>>
>>>> Cheers,
>>>> Michael
>>>>
>>>>
>>>>
>>>> On 27. mai 2014, at 16:11, Michael Welzl <michawe@ifi.uio.no> wrote:
>>>>
>>>> > Thanks a lot Spencer!
>>>> >
>>>> > TAPS: please stay tuned for a first proposal coming f= rom me very
>>>> soon -
>>>> this incorporates some prior discussion that we probably d= on't want to
>>>> re-iterate and wouldn't want to incorporate in the cur= rent charter -
>>>> you
>>>> heard the man: "a minimal charter that we could appro= ve quickly", so
>>>> this
>>>> is about removing things that we wanted to do from *this* = charter, and
>>>> hoping / expecting that they will be dealt with elsewhere.=
>>>> >
>>>> > Cheers
>>>> > Michael
>>>> >
>>>> >
>>>> >
>>>> > On 27. mai 2014, at 15:53, Spencer Dawkins wrote:
>>>> >
>>>> >> So, it may be useful for me to chime in here. I&#= 39;m speaking only as
>>>> 1/16th of the IESG, of course.
>>>> >>
>>>> >> I thought the TAPS BoF in London was very helpful= , and the IESG and
>>>> IAB
>>>> spent a significant amount of time talking about what happ= ened at the
>>>> BoF
>>>> (thanks to Michael and Murray for capable chairing, and to= Michael for
>>>> producing near-verbatim minutes from the recorded audio), = both at the
>>>> "week
>>>> in review" session on Friday afternoon after IETF 89,= and at the joint
>>>> IESG/IAB retreat a couple of weeks ago.
>>>> >>
>>>> >> There's a lot to talk about, and the folks wh= o observed that IETF
>>>> working groups are a lousy place to talk about things, esp= ecially at
>>>> charter time, are dead-on.
>>>> >>
>>>> >> So what I'm asking, is that people take a sho= t at proposing a
>>>> minimal
>>>> charter that we could approve quickly (and maybe without a= BOF - they
>>>> aren't required, and we're trying to make it easie= r for people to
>>>> start
>>>> work).
>>>> >>
>>>> >> We'll find venues for work that needs to happ= en, whether in IETF
>>>> working groups, in IRTF research groups, or as Independent=
>>>> Submissions, and
>>>> I'm happy to sponsor mailing lists for various chunks = of this work as
>>>> you
>>>> identify them, so you don't have to have one big conve= rsation about
>>>> the
>>>> Answer to Life, the Universe, and Everything (c).
>>>> >>
>>>> >> So please, talk amongst yourselves, and see what = you can agree on
>>>> :-)
>>>> >>
>>>> >> Spencer
>>>> >>
>>>> >> On 05/27/2014 02:32 AM, Jon Crowcroft wrote:
>>>> >>> totally agree - I think generalized pattern a= pproach is really
>>>> nice,
>>>> and we tried using it in the "building blocks" s= tructure that was used
>>>> in
>>>> the RMT group - i think quite successfully
>>>> >>>
>>>> >>> however, patterns (and RMT consierations too)= are over-reach for
>>>> TAPS,
>>>> in my opinion....life's too short to get something don= e that new, big,
>>>> and
>>>> complex (and contentious in some quarters)
>>>> >>
>>>> >> _______________________________________________ >>>> >> Taps mailing list
>>>> >> Taps@ietf.org
>>>> >> https://www.ietf.org/mailman/listinfo/taps
>>>> >
>>>> > _______________________________________________
>>>> > Taps mailing list
>>>> > Taps@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/taps
>>>>
>>>> _______________________________________________
>>>> Taps mailing list
>>>> Taps@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/taps
>>>>
>>>
>>
>>
>
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
>



--001a11c2c0d40ac45104fa72703d-- From nobody Wed May 28 05:26:08 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6861A096C for ; Wed, 28 May 2014 05:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peFG7LLwT961 for ; Wed, 28 May 2014 05:26:02 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 441C31A0969 for ; Wed, 28 May 2014 05:26:02 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Wpcva-0001Kl-Dh; Wed, 28 May 2014 14:25:54 +0200 Received: from cisne-cn09.upc.es ([147.83.182.9] helo=[10.82.22.206]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WpcvZ-0007Dk-SI; Wed, 28 May 2014 14:25:54 +0200 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=windows-1252 From: Michael Welzl X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 28 May 2014 14:25:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <20140528041220.jwx96kmu8gwg44sc@webmail.mit.edu> <2aa92313023c20b3243a500074e63a9d.squirrel@www.erg.abdn.ac.uk> To: Toby Moncaster X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 12 sum msgs/h 4 total rcpts 16874 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B90A55F94C15A77E3F8028BDB6E98236E205A537 X-UiO-SPAM-Test: remote_host: 147.83.182.9 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 1 max/h 1 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/yA3yuZ9tejyLoWLNXQHySq6NFq0 Cc: "gorry@erg.abdn.ac.uk \(erg\)" , Marie-Jose Montpetit , Jon Crowcroft , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 12:26:06 -0000 Gorry's interpretation was also mine, which is why I didn't get what = exactly you people want at first - On 28. mai 2014, at 11:28, Toby Moncaster = wrote: > What Gorry says seems to make sense, and perhaps should be made = explicit? Fine, yes - but I'd still welcome actual wording... > Regarding the issue of apparent inconsistency between bullets one and = three. I think this highlights that one of the things we should be = seeking to do early on is disambiguate all the terminology relating to = transport protocols, transport mechanisms, congestion control = mechanisms, transport services, etc. I agree, but I also take this to mean that you agree with not changing = it. (it's really only a nit anyway) > Final point. Deliverable 2 =93Proposed Standard RFC specifying a set = of transport services that an end system should provide=94. We need to = be careful about this one. If it is going to be a proposed standard then = really it needs to specify some things as must provide. There is a = chance that we=92ll get complaints about using =93should=94 in the = bullet? I=92m assuming we are intending that this should look something = like RFC1812 Requirements for IPv4 Routers? But I may be wrong Hm. But this is about future end systems - if we just replace "should" = with "must" then we can only write "reliable byte stream" and = "unreliable datagram service" in there :-) Thoughts? Cheers, Michael From nobody Wed May 28 06:07:38 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4FEE1A0979 for ; Wed, 28 May 2014 06:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLDqmmqjXHVP for ; Wed, 28 May 2014 06:07:32 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 96D701A010C for ; Wed, 28 May 2014 06:07:32 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 567E22B4258; Wed, 28 May 2014 14:07:28 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Wed, 28 May 2014 14:07:28 +0100 Message-ID: In-Reply-To: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <20140528041220.jwx96kmu8gwg44sc@webmail.mit.edu> <2aa92313023c20b3243a500074e63a9d.squirrel@www.erg.abdn.ac.uk> Date: Wed, 28 May 2014 14:07:28 +0100 From: gorry@erg.abdn.ac.uk To: "Michael Welzl" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/taps/OW0WjoHZ2B2YdJ9rkSwBAGv84cI Cc: Marie-Jose Montpetit , Jon Crowcroft , Toby Moncaster , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 13:07:35 -0000 I suggest three things: (1) Shorten M14 - It's long for the tracker and the details are in the Charter above: "M14: Submit specification of how the defined transport services can be provided using IETF transports, including the definition of mechanisms to discover the availability of protocols on an interface (end system support and path support), to IESG as an Experimental RFC." I suggest: "M14: Submit specification of how the transport services can be provided to IESG as an Experimental RFC." (2) On the wording below, I suggest: "Proposed Standard RFC specifying a set of transport services that end systems need to provide" (3) On the milestone below, I suggest: "M13: Submit end system transport services to IESG as a Proposed Standard." Please change as people see fit, Gorry > Gorry's interpretation was also mine, which is why I didn't get what > exactly you people want at first - > > On 28. mai 2014, at 11:28, Toby Moncaster > wrote: > >> What Gorry says seems to make sense, and perhaps should be made >> explicit? > > Fine, yes - but I'd still welcome actual wording... > > >> Regarding the issue of apparent inconsistency between bullets one and >> three. I think this highlights that one of the things we should be >> seeking to do early on is disambiguate all the terminology relating to >> transport protocols, transport mechanisms, congestion control >> mechanisms, transport services, etc. > > I agree, but I also take this to mean that you agree with not changing it. > (it's really only a nit anyway) > > >> Final point. Deliverable 2 “Proposed Standard RFC specifying a set of >> transport services that an end system should provide”. We need to be >> careful about this one. If it is going to be a proposed standard then >> really it needs to specify some things as must provide. There is a >> chance that we’ll get complaints about using “should” in the bullet? I’m >> assuming we are intending that this should look something like RFC1812 >> Requirements for IPv4 Routers? But I may be wrong > > Hm. But this is about future end systems - if we just replace "should" > with "must" then we can only write "reliable byte stream" and "unreliable > datagram service" in there :-) > Thoughts? > > Cheers, > Michael > From nobody Wed May 28 06:08:48 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 8B6341A0383 for ; Wed, 28 May 2014 06:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hkoLCqjlql4 for ; Wed, 28 May 2014 06:08:44 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DAAF1A010C for ; Wed, 28 May 2014 06:08:44 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ravage.cl.cam.ac.uk ([128.232.1.17]:56545) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1Wpdav-0002L1-RZ (Exim 4.82_3-c0e5623) (return-path ); Wed, 28 May 2014 14:08:37 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=windows-1252 From: Toby Moncaster X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 28 May 2014 14:08:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <20140528041220.jwx96kmu8gwg44sc@webmail.mit.edu> <2aa92313023c20b3243a500074e63a9d.squirrel@www.erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.1878.2) Sender: "T. Moncaster" Archived-At: http://mailarchive.ietf.org/arch/msg/taps/UOaV4idCJD5nKN73hQMU1cM0Keg Cc: Marie-Jose Montpetit , Jon Crowcroft , Michael Welzl , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 13:08:46 -0000 I agree with all three of these :) Toby On 28 May 2014, at 14:07, gorry@erg.abdn.ac.uk wrote: > I suggest three things: >=20 > (1) Shorten M14 - It's long for the tracker and the details are in the > Charter above: "M14: Submit specification of how the defined transport > services can be provided using IETF transports, including the = definition > of mechanisms to discover the availability of protocols on an = interface > (end system support and path support), to IESG as an Experimental = RFC." > I suggest: > "M14: Submit specification of how the transport services can be = provided > to IESG as an Experimental RFC." >=20 > (2) On the wording below, I suggest: > "Proposed Standard RFC specifying a set of transport services that end > systems need to provide" >=20 > (3) On the milestone below, I suggest: > "M13: Submit end system transport services to IESG as a Proposed = Standard." >=20 > Please change as people see fit, >=20 > Gorry >=20 >> Gorry's interpretation was also mine, which is why I didn't get what >> exactly you people want at first - >>=20 >> On 28. mai 2014, at 11:28, Toby Moncaster = >> wrote: >>=20 >>> What Gorry says seems to make sense, and perhaps should be made >>> explicit? >>=20 >> Fine, yes - but I'd still welcome actual wording... >>=20 >>=20 >>> Regarding the issue of apparent inconsistency between bullets one = and >>> three. I think this highlights that one of the things we should be >>> seeking to do early on is disambiguate all the terminology relating = to >>> transport protocols, transport mechanisms, congestion control >>> mechanisms, transport services, etc. >>=20 >> I agree, but I also take this to mean that you agree with not = changing it. >> (it's really only a nit anyway) >>=20 >>=20 >>> Final point. Deliverable 2 =93Proposed Standard RFC specifying a set = of >>> transport services that an end system should provide=94. We need to = be >>> careful about this one. If it is going to be a proposed standard = then >>> really it needs to specify some things as must provide. There is a >>> chance that we=92ll get complaints about using =93should=94 in the = bullet? I=92m >>> assuming we are intending that this should look something like = RFC1812 >>> Requirements for IPv4 Routers? But I may be wrong >>=20 >> Hm. But this is about future end systems - if we just replace = "should" >> with "must" then we can only write "reliable byte stream" and = "unreliable >> datagram service" in there :-) >> Thoughts? >>=20 >> Cheers, >> Michael >>=20 >=20 >=20 From nobody Wed May 28 06:10:44 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3501A035B for ; Wed, 28 May 2014 06:10:43 -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 BPOxD3wlA86w for ; Wed, 28 May 2014 06:10:42 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B2301A010C for ; Wed, 28 May 2014 06:10:41 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id va2so10785207obc.11 for ; Wed, 28 May 2014 06:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=IFrT+c3lHC7AQUQSntq44hcJTX7j4k85V6CMafHEqIM=; b=xqxYYu+Yhnq4HfuNrrSVIlES6LVAb2WkHTtxK1lhdZeKOV3p1IYyv32XpsrzV0/pAE j2/fD3eycz+c1Jt6+Yoj6qIIAc99pYmIMLxdwZVjlIqQrSKCbS3LlmGJ5kkDzIaDRAec zOrmldVrmOQdQdEW0YTKVezhYo7gwNUi9RgcxOrcYz66gRK7aXGLfssxefHzhC+1lm23 lKGHd8Qct5HNw+bMgfZpS3IsZ1Ek/7pjyFe7P/RxrD0XtvinrLTGZbWYDfGcS5cN6PEt 2ctZu0KSf3RT+ipQDKajmKt2Jqm9iH9ewFNckx/2n1EAW6TqvGFKYss7WVvJWQsDH8EJ ypZw== X-Received: by 10.182.109.226 with SMTP id hv2mr12568654obb.79.1401282638206; Wed, 28 May 2014 06:10:38 -0700 (PDT) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id b9sm65501465oel.4.2014.05.28.06.10.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 06:10:37 -0700 (PDT) Message-ID: <5385E04B.4020508@gmail.com> Date: Wed, 28 May 2014 08:10:35 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Brian Trammell , Michael Welzl References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <5384F201.3050508@kau.se> <6435044C-C17F-4B37-937C-73E1B8C0DE9D@ifi.uio.no> <23240F18-975F-48DF-959B-9CD84D4BB43A@trammell.ch> In-Reply-To: <23240F18-975F-48DF-959B-9CD84D4BB43A@trammell.ch> Content-Type: multipart/alternative; boundary="------------020808080706030808020103" Archived-At: http://mailarchive.ietf.org/arch/msg/taps/E9t37Qa0WDiJJWa0YpQJk-bJcUM Cc: Anna Brunstrom , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 13:10:43 -0000 This is a multi-part message in MIME format. --------------020808080706030808020103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/28/2014 01:55 AM, Brian Trammell wrote: > hi Michael, > > +1 to everything Anna said; the present proposal strikes a good > balance between what can be immediately useful in this space and what > we already know how to do. I would make one point on your edit, though... ... > Coordination is not just important with other Working Groups, but with > possible Research Groups in the IRTF as well, since lots of things we > suspect we want to do but which aren't cooked enough to do engineering > on yet could be referred to a future RG. Brian, thanks for suggesting this edit (which Michael is picking up). In addition to anything that ends up in the IRTF ... my understanding was that the IAB may end up with a program somewhere near the meta-TAPS space. Is it premature to call that out? If the IAB does put a relevant program in place, I'd expect some interaction, and I'd rather not have to revise the charter to say so :-) Thanks, Spencer --------------020808080706030808020103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 05/28/2014 01:55 AM, Brian Trammell wrote:
hi Michael,

+1 to everything Anna said; the present proposal strikes a good balance between what can be immediately useful in this space and what we already know how to do. I would make one point on your edit, though...

...

Coordination is not just important with other Working Groups, but with possible Research Groups in the IRTF as well, since lots of things we suspect we want to do but which aren't cooked enough to do engineering on yet could be referred to a future RG.

Brian, thanks for suggesting this edit (which Michael is picking up).

In addition to anything that ends up in the IRTF ... my understanding was that the IAB may end up with a program somewhere near the meta-TAPS space. Is it premature to call that out?

If the IAB does put a relevant program in place, I'd expect some interaction, and I'd rather not have to revise the charter to say so :-)

Thanks,

Spencer
--------------020808080706030808020103-- From nobody Wed May 28 06:11:03 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB391A097E for ; Wed, 28 May 2014 06:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 diuw8FbKi6zi for ; Wed, 28 May 2014 06:10:54 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 532D61A0985 for ; Wed, 28 May 2014 06:10:54 -0700 (PDT) Received: by mail-qg0-f54.google.com with SMTP id q108so17281629qgd.41 for ; Wed, 28 May 2014 06:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8pUsFJjOyB1iZFhr9SZl9Whlrl9kUFRDkPy8D/Tdo44=; b=08Q29g5nkQV6E0CJrJI9dwQF5h7H2CG0OAGTe5nPY7axMcFQ8StY4JBumDmDqMtI97 9ssiZLBVffm3kFrPPCjuvg9qe1EJcp4BvoOX+/QQZF52Qx/VKYWtJKPWAdQKm5H5lBu6 X705CErB1nmz6kJyifZmPtXzZiwHkUpCsZFHI4TY0WBRZzEonsmPyOWp1AO3oNa9nQku 7JelA5c4Y6jl4PeEqKlkQ9HQZwH4hYeDB5GcDR/omgynxYKh2W8ab/VbpOB2/+e0Mze4 dqsvVpFI1DupXAKsUDRnYQMRcsXlL+9dcvu9RP9AWZgxHOKmR/QgskANPFWeYvPdAAWf zEcg== MIME-Version: 1.0 X-Received: by 10.140.102.166 with SMTP id w35mr50965666qge.97.1401282650322; Wed, 28 May 2014 06:10:50 -0700 (PDT) Sender: crowcroft@gmail.com Received: by 10.140.48.14 with HTTP; Wed, 28 May 2014 06:10:50 -0700 (PDT) In-Reply-To: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <20140528041220.jwx96kmu8gwg44sc@webmail.mit.edu> <2aa92313023c20b3243a500074e63a9d.squirrel@www.erg.abdn.ac.uk> Date: Wed, 28 May 2014 14:10:50 +0100 X-Google-Sender-Auth: f8zuSEb1P_nNA_kBXHSD2UOj_lg Message-ID: From: Jon Crowcroft To: Toby Moncaster Content-Type: multipart/alternative; boundary=001a11c15f3a9a3d1a04fa758afe Archived-At: http://mailarchive.ietf.org/arch/msg/taps/u_v92sh0PASw-xJIKnw9t8eYEFg Cc: Gorry Fairhurst , Marie-Jose Montpetit , Michael Welzl , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 13:10:55 -0000 --001a11c15f3a9a3d1a04fa758afe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 On Wed, May 28, 2014 at 2:08 PM, Toby Moncaster wrote: > I agree with all three of these :) > > Toby > > On 28 May 2014, at 14:07, gorry@erg.abdn.ac.uk wrote: > > > I suggest three things: > > > > (1) Shorten M14 - It's long for the tracker and the details are in the > > Charter above: "M14: Submit specification of how the defined transport > > services can be provided using IETF transports, including the definitio= n > > of mechanisms to discover the availability of protocols on an interface > > (end system support and path support), to IESG as an Experimental RFC." > > I suggest: > > "M14: Submit specification of how the transport services can be provide= d > > to IESG as an Experimental RFC." > > > > (2) On the wording below, I suggest: > > "Proposed Standard RFC specifying a set of transport services that end > > systems need to provide" > > > > (3) On the milestone below, I suggest: > > "M13: Submit end system transport services to IESG as a Proposed > Standard." > > > > Please change as people see fit, > > > > Gorry > > > >> Gorry's interpretation was also mine, which is why I didn't get what > >> exactly you people want at first - > >> > >> On 28. mai 2014, at 11:28, Toby Moncaster > >> wrote: > >> > >>> What Gorry says seems to make sense, and perhaps should be made > >>> explicit? > >> > >> Fine, yes - but I'd still welcome actual wording... > >> > >> > >>> Regarding the issue of apparent inconsistency between bullets one and > >>> three. I think this highlights that one of the things we should be > >>> seeking to do early on is disambiguate all the terminology relating t= o > >>> transport protocols, transport mechanisms, congestion control > >>> mechanisms, transport services, etc. > >> > >> I agree, but I also take this to mean that you agree with not changing > it. > >> (it's really only a nit anyway) > >> > >> > >>> Final point. Deliverable 2 =E2=80=9CProposed Standard RFC specifying = a set of > >>> transport services that an end system should provide=E2=80=9D. We nee= d to be > >>> careful about this one. If it is going to be a proposed standard then > >>> really it needs to specify some things as must provide. There is a > >>> chance that we=E2=80=99ll get complaints about using =E2=80=9Cshould= =E2=80=9D in the bullet? > I=E2=80=99m > >>> assuming we are intending that this should look something like RFC181= 2 > >>> Requirements for IPv4 Routers? But I may be wrong > >> > >> Hm. But this is about future end systems - if we just replace "should" > >> with "must" then we can only write "reliable byte stream" and > "unreliable > >> datagram service" in there :-) > >> Thoughts? > >> > >> Cheers, > >> Michael > >> > > > > > > --001a11c15f3a9a3d1a04fa758afe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1


On Wed, May 28, 2014 at 2:08 PM, Toby Moncaster <tob= y.moncaster@cl.cam.ac.uk> wrote:
I agree with all three of these :)

Toby

On 28 May 2014, at 14:07, gorry@erg= .abdn.ac.uk wrote:

> I suggest three things:
>
> (1) Shorten M14 - It's long for the tracker and the details are in= the
> Charter above: "M14: Submit specification of how the defined tran= sport
> services can be provided using IETF transports, including the definiti= on
> of mechanisms to discover the availability of protocols on an interfac= e
> (end system support and path support), to IESG as an Experimental RFC.= "
> I suggest:
> "M14: Submit specification of how the transport services can be p= rovided
> to IESG as an Experimental RFC."
>
> (2) On the wording below, I suggest:
> "Proposed Standard RFC specifying a set of transport services tha= t end
> systems need to provide"
>
> (3) On the milestone below, I suggest:
> "M13: Submit end system transport services to IESG as a Proposed = Standard."
>
> Please change as people see fit,
>
> Gorry
>
>> Gorry's interpretation was also mine, which is why I didn'= t get what
>> exactly you people want at first -
>>
>> On 28. mai 2014, at 11:28, Toby Moncaster <toby.moncaster@cl.cam.ac.uk>
>> wrote:
>>
>>> What Gorry says seems to make sense, and perhaps should be mad= e
>>> explicit?
>>
>> Fine, yes - but I'd still welcome actual wording...
>>
>>
>>> Regarding the issue of apparent inconsistency between bullets = one and
>>> three. I think this highlights that one of the things we shoul= d be
>>> seeking to do early on is disambiguate all the terminology rel= ating to
>>> transport protocols, transport mechanisms, congestion control<= br> >>> mechanisms, transport services, etc.
>>
>> I agree, but I also take this to mean that you agree with not chan= ging it.
>> (it's really only a nit anyway)
>>
>>
>>> Final point. Deliverable 2 =E2=80=9CProposed Standard RFC spec= ifying a set of
>>> transport services that an end system should provide=E2=80=9D.= We need to be
>>> careful about this one. If it is going to be a proposed standa= rd then
>>> really it needs to specify some things as must provide. There = is a
>>> chance that we=E2=80=99ll get complaints about using =E2=80=9C= should=E2=80=9D in the bullet? I=E2=80=99m
>>> assuming we are intending that this should look something like= RFC1812
>>> Requirements for IPv4 Routers? But I may be wrong
>>
>> Hm. But this is about future end systems - if we just replace &quo= t;should"
>> with "must" then we can only write "reliable byte s= tream" and "unreliable
>> datagram service" in there =C2=A0:-)
>> Thoughts?
>>
>> Cheers,
>> Michael
>>
>
>


--001a11c15f3a9a3d1a04fa758afe-- From nobody Wed May 28 07:56:17 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4FE1A0153 for ; Wed, 28 May 2014 07:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 050gpgoFmMdL for ; Wed, 28 May 2014 07:56:09 -0700 (PDT) Received: from mail-ve0-f198.google.com (mail-ve0-f198.google.com [209.85.128.198]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E05EB1A0353 for ; Wed, 28 May 2014 07:56:08 -0700 (PDT) Received: by mail-ve0-f198.google.com with SMTP id sa20so44575520veb.5 for ; Wed, 28 May 2014 07:56:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zlk/wiiwCQYtKrE3S11zyLlRzLQUacDl0r7nrRcVSio=; b=kwj4SqRC15RAPgzRaDIOjvzIVFSIqQB8VL1A/64SVShJBdPE4T3bsjbsQ40EyjvqbL +64REwNBimGqzuMQKEyACFWLo8ez6gQakkyiLA3N0lOrf+MYXpLn7gn5BTdUx9W/WhZF pi9AiS6X/6ccG+PPij6hVSISkijSxq6P/bn5WXXlKUQS5SQxDcDCHij9etj99n1aj9GC /P5GRbvbXkyJ1FYNcTdft+7EAP+B+jjjcsIEiVKoDIw6D3/WqCTEyZ3di7XbKB+Qyn6B eW3qc8pP/yUY2vHnZtLsfQpZIg/bXGVRQgqKo/HnD1ZTywLvPSBUTc2GePBEg7APR3Oh 7vLw== X-Gm-Message-State: ALoCoQlN6qzUjYthC9KQml9JxGL6vGpNwRiW8qhOWIxJL23SFJrJqDahicAIXx5JOcTyAr1T2Dvu X-Received: by 10.58.195.231 with SMTP id ih7mr206303vec.32.1401288963493; Wed, 28 May 2014 07:56:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.84.35 with HTTP; Wed, 28 May 2014 07:55:43 -0700 (PDT) In-Reply-To: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> From: Aaron Falk Date: Wed, 28 May 2014 10:55:43 -0400 Message-ID: To: Michael Welzl Content-Type: multipart/alternative; boundary=047d7b676630e5a46404fa770254 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/EwLyKZbbuB-sk_HOxx3mWxvDHk4 Cc: taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 14:56:16 -0000 --047d7b676630e5a46404fa770254 Content-Type: text/plain; charset=UTF-8 Again, I'm coming into the discussion a little late but I found the charter a little hard to understand. Others have tripped over the same thing I think. Likely easily solved with a little more preface. - The charter says the goal of the wg is 'identifying transport services' but that term isn't clearly defined. I think a definition needs to be in the charter (esp since it is the name of the wg). - 'Encapsulated transports' also needs a definition. - Without a distinction between a 'transport service' vs. protocols & congestion control mechanisms I can't make sense of working group goal #2. Or maybe the first clause should be deleted: ("Specify the definition of mechanisms to discover the availability of protocols on an interface (end system support and path support.") - Is the informational RFC just a catalog of protocols & congestion control mechanisms? I thought the goal was more about finding the assembled combinations of such that are useful. --aaron On Tue, May 27, 2014 at 3:38 PM, Michael Welzl wrote: > Hi all, > > Following up on this, please take a look at: > https://sites.google.com/site/transportprotocolservices/charter-proposal > > I'd like to suggest this as a way forward to the group; could you support > this as a Charter for forming a WG? > > I think it's clear to all of us that there should be more work beyond > this, but it is important that the initial goals are clear and attainable. > Work beyond could take various forms, in various places - note how Spencer > wrote "We'll find venues for work that needs to happen". This new proposed > charter is about having a common starting point that we all can agree on. > > Cheers, > Michael > > > > On 27. mai 2014, at 16:11, Michael Welzl wrote: > > > Thanks a lot Spencer! > > > > TAPS: please stay tuned for a first proposal coming from me very soon - > this incorporates some prior discussion that we probably don't want to > re-iterate and wouldn't want to incorporate in the current charter - you > heard the man: "a minimal charter that we could approve quickly", so this > is about removing things that we wanted to do from *this* charter, and > hoping / expecting that they will be dealt with elsewhere. > > > > Cheers > > Michael > > > > > > > > On 27. mai 2014, at 15:53, Spencer Dawkins wrote: > > > >> So, it may be useful for me to chime in here. I'm speaking only as > 1/16th of the IESG, of course. > >> > >> I thought the TAPS BoF in London was very helpful, and the IESG and IAB > spent a significant amount of time talking about what happened at the BoF > (thanks to Michael and Murray for capable chairing, and to Michael for > producing near-verbatim minutes from the recorded audio), both at the "week > in review" session on Friday afternoon after IETF 89, and at the joint > IESG/IAB retreat a couple of weeks ago. > >> > >> There's a lot to talk about, and the folks who observed that IETF > working groups are a lousy place to talk about things, especially at > charter time, are dead-on. > >> > >> So what I'm asking, is that people take a shot at proposing a minimal > charter that we could approve quickly (and maybe without a BOF - they > aren't required, and we're trying to make it easier for people to start > work). > >> > >> We'll find venues for work that needs to happen, whether in IETF > working groups, in IRTF research groups, or as Independent Submissions, and > I'm happy to sponsor mailing lists for various chunks of this work as you > identify them, so you don't have to have one big conversation about the > Answer to Life, the Universe, and Everything (c). > >> > >> So please, talk amongst yourselves, and see what you can agree on :-) > >> > >> Spencer > >> > >> On 05/27/2014 02:32 AM, Jon Crowcroft wrote: > >>> totally agree - I think generalized pattern approach is really nice, > and we tried using it in the "building blocks" structure that was used in > the RMT group - i think quite successfully > >>> > >>> however, patterns (and RMT consierations too) are over-reach for TAPS, > in my opinion....life's too short to get something done that new, big, and > complex (and contentious in some quarters) > >> > >> _______________________________________________ > >> 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 > --047d7b676630e5a46404fa770254 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Again, I'm coming into the discussion a little late bu= t I found the charter a little hard to understand. =C2=A0Others have trippe= d over the same thing I think. =C2=A0Likely easily solved with a little mor= e preface.
  • The charter says the goal of the wg is 'identifying transport s= ervices' but that term isn't clearly defined. I think a definition = needs to be in the charter (esp since it is the name of the wg).
  • 'Encapsulated transports' also needs a definition.
  • Without = a distinction between a 'transport service' vs. protocols & con= gestion control mechanisms I can't make sense of working group goal #2.= =C2=A0 Or maybe the first clause should be deleted: ("Specify the def= inition of mechanisms to discover the availability of protocols on an inter= face (end system support and path support.")=C2=A0
  • Is the informational RFC just a catalog of protocols & congestion c= ontrol mechanisms? =C2=A0I thought the goal was more about finding the asse= mbled combinations of such that are useful. =C2=A0
--aaron


On Tue,= May 27, 2014 at 3:38 PM, Michael Welzl <michawe@ifi.uio.no> wrote:
Hi all,

Following up on this, please take a look at:
https://sites.google.com/site/transportprotocol= services/charter-proposal

I'd like to suggest this as a way forward to the group; could you suppo= rt this as a Charter for forming a WG?

I think it's clear to all of us that there should be more work beyond t= his, but it is important that the initial goals are clear and attainable. W= ork beyond could take various forms, in various places - note how Spencer w= rote "We'll find venues for work that needs to happen". This = new proposed charter is about having a common starting point that we all ca= n agree on.

Cheers,
Michael



On 27. mai 2014, at 16:11, Michael Welzl <michawe@ifi.uio.no> wrote:

> Thanks a lot Spencer!
>
> TAPS: please stay tuned for a first proposal coming from me very soon = - this incorporates some prior discussion that we probably don't want t= o re-iterate and wouldn't want to incorporate in the current charter - = you heard the man: "a minimal charter that we could approve quickly&qu= ot;, so this is about removing things that we wanted to do from *this* char= ter, and hoping / expecting that they will be dealt with elsewhere.
>
> Cheers
> Michael
>
>
>
> On 27. mai 2014, at 15:53, Spencer Dawkins wrote:
>
>> So, it may be useful for me to chime in here. I'm speaking onl= y as 1/16th of the IESG, of course.
>>
>> I thought the TAPS BoF in London was very helpful, and the IESG an= d IAB spent a significant amount of time talking about what happened at the= BoF (thanks to Michael and Murray for capable chairing, and to Michael for= producing near-verbatim minutes from the recorded audio), both at the &quo= t;week in review" session on Friday afternoon after IETF 89, and at th= e joint IESG/IAB retreat a couple of weeks ago.
>>
>> There's a lot to talk about, and the folks who observed that I= ETF working groups are a lousy place to talk about things, especially at ch= arter time, are dead-on.
>>
>> So what I'm asking, is that people take a shot at proposing a = minimal charter that we could approve quickly (and maybe without a BOF - th= ey aren't required, and we're trying to make it easier for people t= o start work).
>>
>> We'll find venues for work that needs to happen, whether in IE= TF working groups, in IRTF research groups, or as Independent Submissions, = and I'm happy to sponsor mailing lists for various chunks of this work = as you identify them, so you don't have to have one big conversation ab= out the Answer to Life, the Universe, and Everything (c).
>>
>> So please, talk amongst yourselves, and see what you can agree on = :-)
>>
>> Spencer
>>
>> On 05/27/2014 02:32 AM, Jon Crowcroft wrote:
>>> totally agree - I think generalized pattern approach is really= nice, and we tried using it in the "building blocks" structure t= hat was used in the RMT group - i think quite successfully
>>>
>>> however, patterns (and RMT consierations too) are over-reach f= or TAPS, in my opinion....life's too short to get something done that n= ew, big, and complex (and contentious in some quarters)
>>
>> _______________________________________________
>> 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

--047d7b676630e5a46404fa770254-- From nobody Wed May 28 07:59:23 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2426A1A042B for ; Wed, 28 May 2014 07:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNjcWdAKHwiO for ; Wed, 28 May 2014 07:59:18 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B581A035B for ; Wed, 28 May 2014 07:59:18 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WpfJv-0003H5-5C; Wed, 28 May 2014 16:59:11 +0200 Received: from cisne-cn09.upc.es ([147.83.182.9] helo=[10.82.22.206]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WpfJu-0005Lh-Iz; Wed, 28 May 2014 16:59:11 +0200 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=windows-1252 From: Michael Welzl X-Priority: 3 (Normal) In-Reply-To: Date: Wed, 28 May 2014 16:59:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <370713FF-D465-4366-B823-2E8C7FA59132@ifi.uio.no> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <20140528041220.jwx96kmu8gwg44sc@webmail.mit.edu> <2aa92313023c20b3243a500074e63a9d.squirrel@www.erg.abdn.ac.uk> To: "gorry@erg.abdn.ac.uk (erg)" X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 5 sum rcpts/h 14 sum msgs/h 6 total rcpts 16887 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 0800ED7F7BB35A8C8CD9665FB859FB22ECD86B0C X-UiO-SPAM-Test: remote_host: 147.83.182.9 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 8 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/9J3fCx8xg5god3j6Lx2o_8OHiaw Cc: Marie-Jose Montpetit , Jon Crowcroft , Toby Moncaster , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 14:59:21 -0000 Done. There's still one missing bit. Toby said that "what Gorry said should be = made more explicit", and what Gorry said was the following: >"Informational RFC summarizing the services" was a little about = guidance >that says amongst things "for this, you want that" (if it is supported) I now addressed this by adding, under "The Working Group will:", where = it says "identify services ...", the following sentence: "The resulting document will provide guidance on making a choice among = available mechanisms and protocols to obtain a certain transport = service." and he said: >"Experimental RFC specifying how the defined transport services can be >provided" was about "selecting and engaging" a protocol that will = select >and deliver a service in an actual network I now addressed this by adding, under "The Working Group will:", where = it says "Specify how ...", the following sentence: "The resulting document will explain how to select and engage a protocol = in order to deliver a transport service." See: = https://sites.google.com/site/transportprotocolservices/charter-proposal Opinions? Cheers, Michael On 28. mai 2014, at 15:07, gorry@erg.abdn.ac.uk wrote: > I suggest three things: >=20 > (1) Shorten M14 - It's long for the tracker and the details are in the > Charter above: "M14: Submit specification of how the defined transport > services can be provided using IETF transports, including the = definition > of mechanisms to discover the availability of protocols on an = interface > (end system support and path support), to IESG as an Experimental = RFC." > I suggest: > "M14: Submit specification of how the transport services can be = provided > to IESG as an Experimental RFC." >=20 > (2) On the wording below, I suggest: > "Proposed Standard RFC specifying a set of transport services that end > systems need to provide" >=20 > (3) On the milestone below, I suggest: > "M13: Submit end system transport services to IESG as a Proposed = Standard." >=20 > Please change as people see fit, >=20 > Gorry >=20 >> Gorry's interpretation was also mine, which is why I didn't get what >> exactly you people want at first - >>=20 >> On 28. mai 2014, at 11:28, Toby Moncaster = >> wrote: >>=20 >>> What Gorry says seems to make sense, and perhaps should be made >>> explicit? >>=20 >> Fine, yes - but I'd still welcome actual wording... >>=20 >>=20 >>> Regarding the issue of apparent inconsistency between bullets one = and >>> three. I think this highlights that one of the things we should be >>> seeking to do early on is disambiguate all the terminology relating = to >>> transport protocols, transport mechanisms, congestion control >>> mechanisms, transport services, etc. >>=20 >> I agree, but I also take this to mean that you agree with not = changing it. >> (it's really only a nit anyway) >>=20 >>=20 >>> Final point. Deliverable 2 =93Proposed Standard RFC specifying a set = of >>> transport services that an end system should provide=94. We need to = be >>> careful about this one. If it is going to be a proposed standard = then >>> really it needs to specify some things as must provide. There is a >>> chance that we=92ll get complaints about using =93should=94 in the = bullet? I=92m >>> assuming we are intending that this should look something like = RFC1812 >>> Requirements for IPv4 Routers? But I may be wrong >>=20 >> Hm. But this is about future end systems - if we just replace = "should" >> with "must" then we can only write "reliable byte stream" and = "unreliable >> datagram service" in there :-) >> Thoughts? >>=20 >> Cheers, >> Michael >>=20 >=20 >=20 From nobody Wed May 28 08:08:34 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2509A1A017B for ; Wed, 28 May 2014 08:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgPXCLcuPZ64 for ; Wed, 28 May 2014 08:08:30 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395A31A03E9 for ; Wed, 28 May 2014 08:08:30 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WpfSr-0004xo-Fb; Wed, 28 May 2014 17:08:25 +0200 Received: from cisne-cn09.upc.es ([147.83.182.9] helo=[10.82.22.206]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WpfSq-0005za-TC; Wed, 28 May 2014 17:08:25 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_9FB7D5F7-87B2-4EFC-9E1C-7CF2212CDC00" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: Date: Wed, 28 May 2014 17:08:22 +0200 Message-Id: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> To: Aaron Falk X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 3 sum rcpts/h 11 sum msgs/h 5 total rcpts 16893 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A617B988782FD208D52C9A069E3B6C5E5AB0EAFF X-UiO-SPAM-Test: remote_host: 147.83.182.9 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 11 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/KswEnXCpdga2n5JBUoHX0YGcmJ4 Cc: taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 15:08:33 -0000 --Apple-Mail=_9FB7D5F7-87B2-4EFC-9E1C-7CF2212CDC00 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Aaron, Great input, thanks!! On 28. mai 2014, at 16:55, Aaron Falk wrote: > Again, I'm coming into the discussion a little late but I found the = charter a little hard to understand. Others have tripped over the same = thing I think. Likely easily solved with a little more preface. > The charter says the goal of the wg is 'identifying transport = services' but that term isn't clearly defined. I think a definition = needs to be in the charter (esp since it is the name of the wg). > 'Encapsulated transports' also needs a definition. > Without a distinction between a 'transport service' vs. protocols & = congestion control mechanisms I can't make sense of working group goal = #2. Or maybe the first clause should be deleted: ("Specify the = definition of mechanisms to discover the availability of protocols on an = interface (end system support and path support.")=20 I agree about these things and will propose suitable fixes ASAP. > Is the informational RFC just a catalog of protocols & congestion = control mechanisms? I thought the goal was more about finding the = assembled combinations of such that are useful. =20 I thought it should be such a catalog, and the (most) useful = combinations would go into the proposed standard RFC. Cheers, Michael --Apple-Mail=_9FB7D5F7-87B2-4EFC-9E1C-7CF2212CDC00 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi Aaron,

Great input, thanks!!


On 28. mai 2014, at 16:55, Aaron Falk <falk-ietf@dgftech.com> wrote:

Again, I'm coming into the discussion a little late but I found the charter a little hard to understand.  Others have tripped over the same thing I think.  Likely easily solved with a little more preface.
  • The charter says the goal of the wg is 'identifying transport services' but that term isn't clearly defined. I think a definition needs to be in the charter (esp since it is the name of the wg).
  • 'Encapsulated transports' also needs a definition.
  • Without a distinction between a 'transport service' vs. protocols & congestion control mechanisms I can't make sense of working group goal #2.   Or maybe the first clause should be deleted: ("Specify the definition of mechanisms to discover the availability of protocols on an interface (end system support and path support.") 

I agree about these things and will propose suitable fixes ASAP.


  • Is the informational RFC just a catalog of protocols & congestion control mechanisms?  I thought the goal was more about finding the assembled combinations of such that are useful.  

I thought it should be such a catalog, and the (most) useful combinations would go into the proposed standard RFC.

Cheers,
Michael

--Apple-Mail=_9FB7D5F7-87B2-4EFC-9E1C-7CF2212CDC00-- From nobody Wed May 28 08:21:13 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A768C1A0177 for ; Wed, 28 May 2014 08:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltp-LIEmNCyl for ; Wed, 28 May 2014 08:21:11 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA3451A0155 for ; Wed, 28 May 2014 08:21:10 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Wpff8-0003hc-BK; Wed, 28 May 2014 17:21:06 +0200 Received: from cisne-cn09.upc.es ([147.83.182.9] helo=[10.82.22.206]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Wpff7-0002xO-DU; Wed, 28 May 2014 17:21:06 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_F1E71466-607D-4003-BBAF-6E13309B785F" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: Date: Wed, 28 May 2014 17:21:03 +0200 Message-Id: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> To: Aaron Falk X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 4 sum rcpts/h 13 sum msgs/h 6 total rcpts 16895 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 6FC897EA7A0AD11D2D3C5934055DC658C2AEA289 X-UiO-SPAM-Test: remote_host: 147.83.182.9 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 4 total 12 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/egyh1PZ0eO1a15rmx1n_YYglvzA Cc: taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 15:21:12 -0000 --Apple-Mail=_F1E71466-607D-4003-BBAF-6E13309B785F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 28. mai 2014, at 17:08, Michael Welzl wrote: > Hi Aaron, >=20 > Great input, thanks!! >=20 >=20 > On 28. mai 2014, at 16:55, Aaron Falk wrote: >=20 >> Again, I'm coming into the discussion a little late but I found the = charter a little hard to understand. Others have tripped over the same = thing I think. Likely easily solved with a little more preface. >> The charter says the goal of the wg is 'identifying transport = services' but that term isn't clearly defined. I think a definition = needs to be in the charter (esp since it is the name of the wg). Proposal: add the following sentence as sentence 2 in the charter, i.e. = after: "Conjointly, transport protocols such as SCTP, DCCP, MPTCP, = UDP-Lite and the LEDBAT congestion control mechanism offer a large = number of services to applications in addition to the long-standing two = services provided by TCP and UDP. " *** For example, SCTP provides potentially faster reliable delivery for = applications that can accept blocks of data out of order, and LEDBAT = provides low-priority "scavenger" communication. *** It's definition by example, but it should make it pretty clear what is = meant? >> 'Encapsulated transports' also needs a definition. I suggest to include, right after "Encapsulated transports: *** (e.g., SCTP over UDP) *** >> Without a distinction between a 'transport service' vs. protocols & = congestion control mechanisms I can't make sense of working group goal = #2. Or maybe the first clause should be deleted: ("Specify the = definition of mechanisms to discover the availability of protocols on an = interface (end system support and path support.")=20 Given the above (or similar) changes, do you still think it's needed to = remove the clause? I like your changed sentence, but in context it might = make the reader wonder "why do they do that?" because the reason is now = gone. Cheers, Michael --Apple-Mail=_F1E71466-607D-4003-BBAF-6E13309B785F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 28. mai 2014, at 17:08, Michael = Welzl <michawe@ifi.uio.no>= wrote:

Hi = Aaron,

Great input, = thanks!!


On 28. mai 2014, at = 16:55, Aaron Falk <falk-ietf@dgftech.com> = wrote:

Again, I'm coming into the discussion a = little late but I found the charter a little hard to understand. =  Others have tripped over the same thing I think.  Likely = easily solved with a little more preface.
  • The charter says the goal of the wg is 'identifying transport = services' but that term isn't clearly defined. I think a definition = needs to be in the charter (esp since it is the name of the = wg).
Proposal: add the following sentence as sentence 2 in the charter, i.e. = after: "Conjointly, transport protocols such as SCTP, DCCP, MPTCP, = UDP-Lite and the LEDBAT congestion control mechanism offer a large = number of services to applications in addition to the long-standing two = services provided by TCP and UDP. = "

***
For example, SCTP provides = potentially faster reliable delivery for applications that can accept = blocks of data out of order, and LEDBAT provides low-priority = "scavenger" communication.
***

It's = definition by example, but it should make it pretty clear what is = meant?

  • 'Encapsulated transports' also needs a = definition.

I suggest to include, right after "Encapsulated = transports:
***
(e.g., SCTP over = UDP)
***

  • Without a distinction = between a 'transport service' vs. protocols & congestion control = mechanisms I can't make sense of working group goal #2.   Or maybe = the first clause should be deleted: ("Specify the definition of = mechanisms to discover the availability of protocols on an interface = (end system support and path = support.") 

Given the above (or similar) changes, do = you still think it's needed to remove the clause? I like your changed = sentence, but in context it might make the reader wonder "why do they do = that?" because the reason is now = gone.

Cheers,
Michael

= --Apple-Mail=_F1E71466-607D-4003-BBAF-6E13309B785F-- From nobody Wed May 28 08:23:53 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFF01A03DE for ; Wed, 28 May 2014 08:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMdzH3r9y2S5 for ; Wed, 28 May 2014 08:23:49 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 620C71A0366 for ; Wed, 28 May 2014 08:23:49 -0700 (PDT) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) by trammell.ch (Postfix) with ESMTPSA id C0C601A02DC; Wed, 28 May 2014 17:23:43 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_48A253FA-25F9-42A1-96AE-B0ACAA0F5E62"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Brian Trammell In-Reply-To: Date: Wed, 28 May 2014 17:23:50 +0200 Message-Id: <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> To: Michael Welzl X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/3-ZTuF7My5nSslrQXKjhP9Ixl2g Cc: Aaron Falk , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 15:23:51 -0000 --Apple-Mail=_48A253FA-25F9-42A1-96AE-B0ACAA0F5E62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 28 May 2014, at 17:08, Michael Welzl wrote: > Hi Aaron, >=20 > Great input, thanks!! >=20 >=20 > On 28. mai 2014, at 16:55, Aaron Falk wrote: >=20 >> Again, I'm coming into the discussion a little late but I found the = charter a little hard to understand. Others have tripped over the same = thing I think. Likely easily solved with a little more preface. >> =95 The charter says the goal of the wg is 'identifying = transport services' but that term isn't clearly defined. I think a = definition needs to be in the charter (esp since it is the name of the = wg). >> =95 'Encapsulated transports' also needs a definition. >> =95 Without a distinction between a 'transport service' vs. = protocols & congestion control mechanisms I can't make sense of working = group goal #2. Or maybe the first clause should be deleted: ("Specify = the definition of mechanisms to discover the availability of protocols = on an interface (end system support and path support.")=20 >=20 > I agree about these things and will propose suitable fixes ASAP. >=20 >=20 >> =95 Is the informational RFC just a catalog of protocols & = congestion control mechanisms? I thought the goal was more about = finding the assembled combinations of such that are useful. =20 >=20 > I thought it should be such a catalog, and the (most) useful = combinations would go into the proposed standard RFC. It might (eventually) make sense to publish these as a single document. Cheers, Brian --Apple-Mail=_48A253FA-25F9-42A1-96AE-B0ACAA0F5E62 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 iQEcBAEBCgAGBQJThf+GAAoJENt3nsOmbNJc7jEH/RC6izEOgUC602RoNg1cSylx G3n4zQiKG5oDZifwfIqRa2zuy2sAN+Nu+rvWCU6QNjfvOOwt15jvzlUTSV246WXK wnq6nxUIGKcsQDTyQRkqDpUQ7/ftqYDBHt0rhxoibs0BfEIRNewwuq8Z3RMKhbg1 snP9AtVxse0xsI7Nfx4kKJEZHSo7XN+xZzmeMxHDyFpAjrRwBfMTfsLJlJMsyPMs HGJfrVhvYCUEYLp2yAb8K9oCRZa5NUZaeSTr/LJgVeZC+hy6FWMGtNYd7toylk6a Hga/8cs1dOMgAaTT7huswLrkmrjlcZwFhMdBZPAGRDBdG2frKdtaiaFILOpp5/4= =mJOW -----END PGP SIGNATURE----- --Apple-Mail=_48A253FA-25F9-42A1-96AE-B0ACAA0F5E62-- From nobody Wed May 28 08:33: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 8744F1A015F for ; Wed, 28 May 2014 08:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tujbdYkuxYXE for ; Wed, 28 May 2014 08:33:53 -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 15AC71A0366 for ; Wed, 28 May 2014 08:33:53 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WpfrP-0003Jq-Ci; Wed, 28 May 2014 17:33:47 +0200 Received: from cisne-cn09.upc.es ([147.83.182.9] helo=[10.82.22.206]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WpfrO-0004Ew-GL; Wed, 28 May 2014 17:33:47 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_B475AAB9-B7D3-4330-8929-BA8A201D41FF" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> Date: Wed, 28 May 2014 17:33:44 +0200 Message-Id: <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 12 msgs/h 6 sum rcpts/h 17 sum msgs/h 8 total rcpts 16899 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 97DDCD4CC9DEC58826A4A92D74DF69FCB31F3F5A X-UiO-SPAM-Test: remote_host: 147.83.182.9 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 6 total 14 max/h 6 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/xRlhFIOOwAebNl1QTYhKl-iNZA8 Cc: Aaron Falk , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 15:33:55 -0000 --Apple-Mail=_B475AAB9-B7D3-4330-8929-BA8A201D41FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 28. mai 2014, at 17:23, Brian Trammell wrote: >=20 > On 28 May 2014, at 17:08, Michael Welzl wrote: >=20 >> Hi Aaron, >>=20 >> Great input, thanks!! >>=20 >>=20 >> On 28. mai 2014, at 16:55, Aaron Falk wrote: >>=20 >>> Again, I'm coming into the discussion a little late but I found the = charter a little hard to understand. Others have tripped over the same = thing I think. Likely easily solved with a little more preface. >>> =95 The charter says the goal of the wg is 'identifying = transport services' but that term isn't clearly defined. I think a = definition needs to be in the charter (esp since it is the name of the = wg). >>> =95 'Encapsulated transports' also needs a definition. >>> =95 Without a distinction between a 'transport service' vs. = protocols & congestion control mechanisms I can't make sense of working = group goal #2. Or maybe the first clause should be deleted: ("Specify = the definition of mechanisms to discover the availability of protocols = on an interface (end system support and path support.")=20 >>=20 >> I agree about these things and will propose suitable fixes ASAP. >>=20 >>=20 >>> =95 Is the informational RFC just a catalog of protocols & = congestion control mechanisms? I thought the goal was more about = finding the assembled combinations of such that are useful. =20 >>=20 >> I thought it should be such a catalog, and the (most) useful = combinations would go into the proposed standard RFC. >=20 > It might (eventually) make sense to publish these as a single = document. Not sure what you're suggesting. In my mind (but maybe we have a = different interpretation?), we first have the Informational RFC, which = is long. Then, the Proposed Standard, which is essentially a shortened = version of the Informational RFC. What you say is that we should eventually combine them into one = document? =3D> you mean a long document, where the key combinations are marked as = such? Yes this might make sense, or it might just be a very long = document that noone wants to read. - again, I'll point to page 51 of = this document: = http://heim.ifi.uio.no/~michawe/teaching/dipls/stefan_joerer.pdf - one = can imagine that the list in the Informational RFC would be 1) much = longer, 2) much more detailed. My suggestion: possibly write such a document, but decide that later, as = (if) we recharter. Ok? If so, do you want me to insert this in the = sentence about rechartering? (I wouldn't, as we'd really only see at = the end of the work if this makes sense or not, and as I said I suspect = the outcome will be negative, just because of the sheer length of the = result - but fine with me either way). Cheers, Michael --Apple-Mail=_B475AAB9-B7D3-4330-8929-BA8A201D41FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 28. mai 2014, at 17:23, Brian = Trammell <ietf@trammell.ch> = wrote:


On 28 May 2014, at 17:08, = Michael Welzl <michawe@ifi.uio.no> = wrote:

Hi Aaron,

Great input, = thanks!!


On 28. mai 2014, at 16:55, Aaron Falk <falk-ietf@dgftech.com> = wrote:

Again, I'm coming into the = discussion a little late but I found the charter a little hard to = understand.  Others have tripped over the same thing I think. =  Likely easily solved with a little more preface.
=95 The = charter says the goal of the wg is 'identifying transport services' but = that term isn't clearly defined. I think a definition needs to be in the = charter (esp since it is the name of the wg).
=95 = 'Encapsulated transports' also needs a definition.
=95 = Without a distinction between a 'transport service' vs. protocols & = congestion control mechanisms I can't make sense of working group goal = #2.   Or maybe the first clause should be deleted: ("Specify = the definition of mechanisms to discover the availability of protocols = on an interface (end system support and path support.") 

I = agree about these things and will propose suitable fixes = ASAP.


=95 Is the informational RFC just = a catalog of protocols & congestion control mechanisms?  I = thought the goal was more about finding the assembled combinations of = such that are useful.  

I thought it should be = such a catalog, and the (most) useful combinations would go into the = proposed standard RFC.

It might (eventually) make = sense to publish these as a single = document.

Not sure what you're = suggesting. In my mind (but maybe we have a different interpretation?), = we first have the Informational RFC, which is long. Then, the Proposed = Standard, which is essentially a shortened version of the Informational = RFC.

What you say is that we should eventually = combine them into one document?

=3D> you = mean a long document, where the key combinations are marked as such? =  Yes this might make sense, or it might just be a very long = document that noone wants to read. - again, I'll point to page 51 of = this document: = http://heim.ifi.uio.no/~michawe/teaching/dipls/stefan_joerer.pdf =   - one can imagine that the list in the Informational RFC would be = 1) much longer, 2) much more detailed.

My = suggestion: possibly write such a document, but decide that later, as = (if) we recharter. Ok?  If so, do you want me to insert this in the = sentence about rechartering?  (I wouldn't, as we'd really only see = at the end of the work if this makes sense or not, and as I said I = suspect the outcome will be negative, just because of the sheer length = of the result - but fine with me either = way).

Cheers,
Michael

= --Apple-Mail=_B475AAB9-B7D3-4330-8929-BA8A201D41FF-- From nobody Wed May 28 09:14:06 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB6F1A0164 for ; Wed, 28 May 2014 09:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 eTMhu4pDFl97 for ; Wed, 28 May 2014 09:14:00 -0700 (PDT) Received: from mail-qg0-f71.google.com (mail-qg0-f71.google.com [209.85.192.71]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DAE61A0456 for ; Wed, 28 May 2014 09:14:00 -0700 (PDT) Received: by mail-qg0-f71.google.com with SMTP id a108so27034992qge.2 for ; Wed, 28 May 2014 09:13:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=f5UTxT79dDiUCFugnk8WId1z7bgSvZz0MmTM/K0Yen4=; b=KBZRCygiTYPRjLPWaEj86SQ22hIMCGzkK3JtO0V48diZA3iv0XUbDEmFvJIuvcQueM X4B26hwaBd3LfO/RzF1/YVsva1RDLRQHrc6f1dvKa8+fHxukBqDRRBzl1UorDq8pSTYM Ggyp/AWveuY2YsrfPtekt5KQGdhFPV890tMYhAAY7sHJzmNA1v3UQr7Tk1P7ozBmW6W6 Geq4Te1l/6HoxyPR3bx88/3P9lPF1BsdDBRyJkJt97xE0kJiS3+VDNGTbz0XuYzulxEc /33UyOKBETjsIZLZugJpEgjblDcts75m4ooLbW4JeIH2O8rwP9r3HLjoDiuTcBGAGbGA b+Ig== X-Gm-Message-State: ALoCoQmow31L/FJbGNvXveGXPNJgNrZPS6qdyJKhtdgzEzFSIiUGt9BHLxEYNpfx01JHmPKGdsCs X-Received: by 10.58.28.205 with SMTP id d13mr559889veh.55.1401293635907; Wed, 28 May 2014 09:13:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.84.35 with HTTP; Wed, 28 May 2014 09:13:35 -0700 (PDT) In-Reply-To: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> From: Aaron Falk Date: Wed, 28 May 2014 12:13:35 -0400 Message-ID: To: Michael Welzl Content-Type: multipart/alternative; boundary=047d7b6dc1e665082804fa781938 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/g4BOXmBUltlZDHP8HrOw4BR3zek Cc: taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 16:14:04 -0000 --047d7b6dc1e665082804fa781938 Content-Type: text/plain; charset=UTF-8 On Wed, May 28, 2014 at 11:21 AM, Michael Welzl wrote: > > On 28. mai 2014, at 17:08, Michael Welzl wrote: > > Hi Aaron, > > Great input, thanks!! > > > On 28. mai 2014, at 16:55, Aaron Falk wrote: > > Again, I'm coming into the discussion a little late but I found the > charter a little hard to understand. Others have tripped over the same > thing I think. Likely easily solved with a little more preface. > > - The charter says the goal of the wg is 'identifying transport > services' but that term isn't clearly defined. I think a definition needs > to be in the charter (esp since it is the name of the wg). > > Proposal: add the following sentence as sentence 2 in the charter, i.e. > after: "Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite > and the LEDBAT congestion control mechanism offer a large number of > services to applications in addition to the long-standing two services > provided by TCP and UDP. " > > How about "Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and the LEDBAT congestion control mechanism extend the number of transport services to applications in addition to the long-standing two services provided by TCP and UDP. " I think it is clearer if 'transport services" is explicitly used. > *** > For example, SCTP provides potentially faster reliable delivery for > applications that can accept blocks of data out of order, and LEDBAT > provides low-priority "scavenger" communication. > *** > > It's definition by example, but it should make it pretty clear what is > meant? > it's a good example. > > > - 'Encapsulated transports' also needs a definition. > > > I suggest to include, right after "Encapsulated transports: > *** > (e.g., SCTP over UDP) > *** > Right. Very helpful. > > > - Without a distinction between a 'transport service' vs. protocols & > congestion control mechanisms I can't make sense of working group goal #2. > Or maybe the first clause should be deleted: ("Specify the definition of > mechanisms to discover the availability of protocols on an interface (end > system support and path support.") > > > Given the above (or similar) changes, do you still think it's needed to > remove the clause? I like your changed sentence, but in context it might > make the reader wonder "why do they do that?" because the reason is now > gone. > It's worth motivating that task. how about adding "to provide a basis for incremental deployment"? My preference is to remove the clause because it adds ambiguity. YMMV. --aaron --047d7b6dc1e665082804fa781938 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, May 28, 2014 at 11:21 AM, Michael Welzl <michawe@ifi.uio.no&g= t; wrote:

On 28. mai 2014, at 17:08, Michael Welzl <michawe@ifi.uio.no> wrote:

Hi Aaron,

<= /div>
Great input, thanks!!


On 28. ma= i 2014, at 16:55, Aaron Falk <falk-ietf@dgftech.com> wrote:

Again, I'm coming into the discussion a little late bu= t I found the charter a little hard to understand. =C2=A0Others have trippe= d over the same thing I think. =C2=A0Likely easily solved with a little mor= e preface.
  • The charter says the goal of the wg is 'identifying transport s= ervices' but that term isn't clearly defined. I think a definition = needs to be in the charter (esp since it is the name of the wg).
Proposal= : add the following sentence as sentence 2 in the charter, i.e. after: &quo= t;Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and t= he LEDBAT congestion control mechanism offer a large number of services to = applications in addition to the long-standing two services provided by TCP = and UDP. "


How about =C2= =A0"Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lit= e and the LEDBAT congestion control mechanism extend the number of transpor= t services to applications in addition to the long-standing two services pr= ovided by TCP and UDP. " =C2=A0I think it is clearer if 'transport= services" is explicitly used.
=C2=A0
=
***
For example, SCTP provides potentially faster reliable d= elivery for applications that can accept blocks of data out of order, and L= EDBAT provides low-priority "scavenger" communication.
***

It's definition by example, but it should make it p= retty clear what is meant?


=
it's a good example.
=C2=A0

  • 'Encapsulated transports' also needs a definition.
<= /div>

I sug= gest to include, right after "Encapsulated transports:
***
(e.g., SCTP over UDP)
***
<= div>
Right. =C2=A0Very helpful.

=C2= =A0

  • Without a distinction between a = 9;transport service' vs. protocols & congestion control mechanisms = I can't make sense of working group goal #2. =C2=A0 Or maybe the first = clause should be deleted: ("Specify the definition of mechanisms to di= scover the availability of protocols on an interface (end system support an= d path support.")=C2=A0

Given the above (or similar) changes, do you still think it= 9;s needed to remove the clause? I like your changed sentence, but in conte= xt it might make the reader wonder "why do they do that?" because= the reason is now gone.

It's worth motivating that task. =C2= =A0how about adding "to provide a basis for incremental deployment&quo= t;? =C2=A0My preference is to remove the clause because it adds ambiguity. = =C2=A0YMMV.

--aaron
--047d7b6dc1e665082804fa781938-- From nobody Wed May 28 10:04:30 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C131A6EEE for ; Wed, 28 May 2014 10:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqksCg2MXn5F for ; Wed, 28 May 2014 10:04:27 -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 94F781A6EE6 for ; Wed, 28 May 2014 10:04:26 -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 1WphH3-0001y8-VF; Wed, 28 May 2014 19:04:21 +0200 Received: from [84.88.52.198] (helo=[192.168.20.99]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WphH2-0002Zw-Us; Wed, 28 May 2014 19:04:21 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_EC6AC393-DE70-483F-B606-E4AE454949D7" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: Date: Wed, 28 May 2014 19:04:16 +0200 Message-Id: <23632C15-BD30-4C62-8AE3-F98059BF541C@ifi.uio.no> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> To: Aaron Falk X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 10 sum msgs/h 5 total rcpts 16901 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: BF56A99F1349F9FD9440C42B9303521EE32ABCA3 X-UiO-SPAM-Test: remote_host: 84.88.52.198 spam_score: -49 maxlevel 80 minaction 2 bait 0 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/lzH1zJf-K7mUUi8OwWXQga0U_XQ Cc: taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 17:04:29 -0000 --Apple-Mail=_EC6AC393-DE70-483F-B606-E4AE454949D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 28. mai 2014, at 18:13, Aaron Falk wrote: >=20 > On Wed, May 28, 2014 at 11:21 AM, Michael Welzl = wrote: >=20 > On 28. mai 2014, at 17:08, Michael Welzl wrote: >=20 >> Hi Aaron, >>=20 >> Great input, thanks!! >>=20 >>=20 >> On 28. mai 2014, at 16:55, Aaron Falk wrote: >>=20 >>> Again, I'm coming into the discussion a little late but I found the = charter a little hard to understand. Others have tripped over the same = thing I think. Likely easily solved with a little more preface. >>> The charter says the goal of the wg is 'identifying transport = services' but that term isn't clearly defined. I think a definition = needs to be in the charter (esp since it is the name of the wg). >=20 > Proposal: add the following sentence as sentence 2 in the charter, = i.e. after: "Conjointly, transport protocols such as SCTP, DCCP, MPTCP, = UDP-Lite and the LEDBAT congestion control mechanism offer a large = number of services to applications in addition to the long-standing two = services provided by TCP and UDP. " >=20 >=20 > How about "Conjointly, transport protocols such as SCTP, DCCP, MPTCP, = UDP-Lite and the LEDBAT congestion control mechanism extend the number = of transport services to applications in addition to the long-standing = two services provided by TCP and UDP. " I think it is clearer if = 'transport services" is explicitly used. done =20 > *** > For example, SCTP provides potentially faster reliable delivery for = applications that can accept blocks of data out of order, and LEDBAT = provides low-priority "scavenger" communication. > *** >=20 > It's definition by example, but it should make it pretty clear what is = meant? >=20 >=20 > it's a good example. inserted =20 >=20 >>> 'Encapsulated transports' also needs a definition. >=20 > I suggest to include, right after "Encapsulated transports: > *** > (e.g., SCTP over UDP) > *** >=20 > Right. Very helpful. ... but now deleted because I went with your update below which removes = the whole bit of encapsulated transports - =20 >=20 >>> Without a distinction between a 'transport service' vs. protocols & = congestion control mechanisms I can't make sense of working group goal = #2. Or maybe the first clause should be deleted: ("Specify the = definition of mechanisms to discover the availability of protocols on an = interface (end system support and path support.")=20 >=20 > Given the above (or similar) changes, do you still think it's needed = to remove the clause? I like your changed sentence, but in context it = might make the reader wonder "why do they do that?" because the reason = is now gone. >=20 > It's worth motivating that task. how about adding "to provide a basis = for incremental deployment"? My preference is to remove the clause = because it adds ambiguity. YMMV. done (and changed "specify the definition of mechanisms" to "specify = mechanisms", I think this was a leftover from the previous text where it = said "the definition"). So the final text for goal #2 now reads: " =95 To provide a basis for incremental deployment, specify = mechanisms to discover the availability of protocols on an interface = (end system support and path support). The resulting document will = explain how to select and engage a protocol in order to deliver a = transport service." and the full beast is at: https://sites.google.com/site/transportprotocolservices/charter-proposal Cheers, Michael --Apple-Mail=_EC6AC393-DE70-483F-B606-E4AE454949D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 28. mai 2014, at 18:13, Aaron Falk = <falk-ietf@dgftech.com>= wrote:


On Wed, May 28, 2014 at 11:21 AM, Michael Welzl = <michawe@ifi.uio.no> wrote:

On 28. mai 2014, at 17:08, Michael Welzl <michawe@ifi.uio.no> wrote:

Hi = Aaron,

Great input, thanks!!


On 28. = mai 2014, at 16:55, Aaron Falk <falk-ietf@dgftech.com> = wrote:

Again, I'm coming into the discussion a little late but = I found the charter a little hard to understand.  Others have = tripped over the same thing I think.  Likely easily solved with a = little more preface.
  • The charter says the goal of the wg is 'identifying transport = services' but that term isn't clearly defined. I think a definition = needs to be in the charter (esp since it is the name of the = wg).
=
Proposa= l: add the following sentence as sentence 2 in the charter, i.e. after: = "Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and = the LEDBAT congestion control mechanism offer a large number of services = to applications in addition to the long-standing two services provided = by TCP and UDP. "


How about =  "Conjointly, transport protocols such as SCTP, DCCP, MPTCP, = UDP-Lite and the LEDBAT congestion control mechanism extend the number = of transport services to applications in addition to the long-standing = two services provided by TCP and UDP. "  I think it is clearer if = 'transport services" is explicitly = used.

done
 
***
For example, SCTP provides potentially faster = reliable delivery for applications that can accept blocks of data out of = order, and LEDBAT provides low-priority "scavenger" communication.
***

It's definition by example, but it should make it = pretty clear what is = meant?


it's a = good = example.

inserted
=

 

  • 'Encapsulated transports' also needs a = definition.

=
I suggest to include, right after "Encapsulated = transports:
***
(e.g., SCTP over = UDP)
***

Right. =  Very = helpful.

... but now = deleted because I went with your update below which removes the whole = bit of encapsulated transports = -

 

  • Without a distinction between a = 'transport service' vs. protocols & congestion control mechanisms I = can't make sense of working group goal #2.   Or maybe the first = clause should be deleted: ("Specify the definition of mechanisms to = discover the availability of protocols on an interface (end system = support and path support.") 

Given = the above (or similar) changes, do you still think it's needed to remove = the clause? I like your changed sentence, but in context it might make = the reader wonder "why do they do that?" because the reason is now = gone.

It's worth motivating that task. =  how about adding "to provide a basis for incremental deployment"? =  My preference is to remove the clause because it adds ambiguity. =  YMMV.

done (and = changed "specify the definition of mechanisms" to "specify mechanisms", = I think this was a leftover from the previous text where it said "the = definition"). So the final text for goal #2 now = reads:

" =95 To provide a basis for = incremental deployment, specify mechanisms to discover the availability = of protocols on an interface (end system support and path = support). The resulting document will explain how to select = and engage a protocol in order to deliver a transport = service."

and the full beast is = at:

Cheers,
Michael
= --Apple-Mail=_EC6AC393-DE70-483F-B606-E4AE454949D7-- From nobody Wed May 28 10:05:58 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8E61A045D for ; Wed, 28 May 2014 10:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nXZRKYa5Wxx for ; Wed, 28 May 2014 10:05:54 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id E62241A0190 for ; Wed, 28 May 2014 10:05:53 -0700 (PDT) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) by trammell.ch (Postfix) with ESMTPSA id 28C491A070A; Wed, 28 May 2014 19:05:16 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_BA44623F-1E43-4245-88EE-16BB901BC534"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Brian Trammell In-Reply-To: <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> Date: Wed, 28 May 2014 19:05:26 +0200 Message-Id: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/ZFq0dh-GPueBHtE6qHY5NNk1UCw Cc: Aaron Falk , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 17:05:56 -0000 --Apple-Mail=_BA44623F-1E43-4245-88EE-16BB901BC534 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 hi Michael, the short short answer here is that the scope of work is much more = important than the actual division of content across individual = documents (indeed, I'd leave the deliverables list out of the charter = text, and put the actual documents only in the milestones, but maybe = that's just me). Cheers, Brian On 28 May 2014, at 17:33, Michael Welzl wrote: >=20 > On 28. mai 2014, at 17:23, Brian Trammell wrote: >=20 >>=20 >> On 28 May 2014, at 17:08, Michael Welzl wrote: >>=20 >>> Hi Aaron, >>>=20 >>> Great input, thanks!! >>>=20 >>>=20 >>> On 28. mai 2014, at 16:55, Aaron Falk wrote: >>>=20 >>>> Again, I'm coming into the discussion a little late but I found the = charter a little hard to understand. Others have tripped over the same = thing I think. Likely easily solved with a little more preface. >>>> =95 The charter says the goal of the wg is 'identifying = transport services' but that term isn't clearly defined. I think a = definition needs to be in the charter (esp since it is the name of the = wg). >>>> =95 'Encapsulated transports' also needs a definition. >>>> =95 Without a distinction between a 'transport service' vs. = protocols & congestion control mechanisms I can't make sense of working = group goal #2. Or maybe the first clause should be deleted: ("Specify = the definition of mechanisms to discover the availability of protocols = on an interface (end system support and path support.")=20 >>>=20 >>> I agree about these things and will propose suitable fixes ASAP. >>>=20 >>>=20 >>>> =95 Is the informational RFC just a catalog of protocols & = congestion control mechanisms? I thought the goal was more about = finding the assembled combinations of such that are useful. =20 >>>=20 >>> I thought it should be such a catalog, and the (most) useful = combinations would go into the proposed standard RFC. >>=20 >> It might (eventually) make sense to publish these as a single = document. >=20 > Not sure what you're suggesting. In my mind (but maybe we have a = different interpretation?), we first have the Informational RFC, which = is long. Then, the Proposed Standard, which is essentially a shortened = version of the Informational RFC. >=20 > What you say is that we should eventually combine them into one = document? >=20 > =3D> you mean a long document, where the key combinations are marked = as such? Yes this might make sense, or it might just be a very long = document that noone wants to read. - again, I'll point to page 51 of = this document: = http://heim.ifi.uio.no/~michawe/teaching/dipls/stefan_joerer.pdf - one = can imagine that the list in the Informational RFC would be 1) much = longer, 2) much more detailed. >=20 > My suggestion: possibly write such a document, but decide that later, = as (if) we recharter. Ok? If so, do you want me to insert this in the = sentence about rechartering? (I wouldn't, as we'd really only see at = the end of the work if this makes sense or not, and as I said I suspect = the outcome will be negative, just because of the sheer length of the = result - but fine with me either way). >=20 > Cheers, > Michael --Apple-Mail=_BA44623F-1E43-4245-88EE-16BB901BC534 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 iQEcBAEBCgAGBQJThhdWAAoJENt3nsOmbNJc9h4IAKktPYsKEX2HkOY0u2e8o5iq ggAN/szkvyy8x0fkJ6cyQY885jaAvR5/tt80ZaqWhGoVlMAkU0dZfv8c97H256Ks INYkq9Tp+NmliR7KnQh4hx4TO6nWP7GyIQ7Sr4T112cqT5bRnreyYQ7Q9GTVgcAM xlp/6RyAm9R2UGeTKbl+Vw1e9cnvrOgxlGorDOp+RzMYM3e6W2o/PgGJlQqCxrxQ v0yDiioNfxwHwDU12XQFLB4KtzXDXN8FP+C7TqF4CJFumldO0Ao81jusxTwsxVR6 E84PdidP01Kz8pFfLtTmF2WaX93ID9tigIrAUcNxqU1FRiRgoq6jR0oJ8DNJ0tI= =+nWg -----END PGP SIGNATURE----- --Apple-Mail=_BA44623F-1E43-4245-88EE-16BB901BC534-- From nobody Wed May 28 10:12:03 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC931A049C for ; Wed, 28 May 2014 10:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bw38hgwqk0uw for ; Wed, 28 May 2014 10:11:48 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 117241A0431 for ; Wed, 28 May 2014 10:11:20 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WphNj-0001N5-Go; Wed, 28 May 2014 19:11:15 +0200 Received: from [84.88.52.198] (helo=[192.168.20.99]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WphNj-0004K0-0M; Wed, 28 May 2014 19:11:15 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: Date: Wed, 28 May 2014 19:11:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <44BB549A-EC7D-4345-9E60-49476F9EFF5A@ifi.uio.no> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> To: Brian Trammell X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 7 msgs/h 3 sum rcpts/h 15 sum msgs/h 7 total rcpts 16906 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 011D7E81864BF011C4DD2B437E72FDC7C4F972C2 X-UiO-SPAM-Test: remote_host: 84.88.52.198 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 2 max/h 2 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/JSyQ_NMRlzYJM-oFCj0U4UX5gu0 Cc: Aaron Falk , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 28 May 2014 17:12:00 -0000 On 28. mai 2014, at 19:05, Brian Trammell wrote: > hi Michael, >=20 > the short short answer here is that the scope of work is much more = important than the actual division of content across individual = documents Sure! Any comments about the scope as it's now written? > (indeed, I'd leave the deliverables list out of the charter text, and = put the actual documents only in the milestones, but maybe that's just = me). I think I'll leave them as they are because: - Gorry has already made me shorten the text on a milestone because it's = long for the tracker - your suggestion would make them longer again - at the same time you seem to indicate that you don't care much about = this detail, so this seems to be the easiest solution for me. Cheers, Michael From nobody Thu May 29 00:38:32 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 508151A0793 for ; Thu, 29 May 2014 00:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WBfUaPGqR-7 for ; Thu, 29 May 2014 00:38:26 -0700 (PDT) Received: from trammell.ch (trammell1.nine.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id F10C61A0789 for ; Thu, 29 May 2014 00:38:25 -0700 (PDT) Received: from [10.0.27.102] (cust-integra-122-165.antanet.ch [80.75.122.165]) by trammell.ch (Postfix) with ESMTPSA id 3A3CC1A0870; Thu, 29 May 2014 09:37:49 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_5AF24FE1-F16B-4A88-92CA-EEAB1EA2EBC5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Brian Trammell In-Reply-To: <44BB549A-EC7D-4345-9E60-49476F9EFF5A@ifi.uio.no> Date: Thu, 29 May 2014 09:37:49 +0200 Message-Id: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <44BB549A-EC7D-4345-9E60-49476F9EFF5A@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/lPBzdiMSKMzfkmU2fYH93ZKp0lM Cc: Aaron Falk , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 29 May 2014 07:38:28 -0000 --Apple-Mail=_5AF24FE1-F16B-4A88-92CA-EEAB1EA2EBC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 28 May 2014, at 19:11, Michael Welzl wrote: >=20 > On 28. mai 2014, at 19:05, Brian Trammell wrote: >=20 >> hi Michael, >>=20 >> the short short answer here is that the scope of work is much more = important than the actual division of content across individual = documents >=20 > Sure! Any comments about the scope as it's now written? Scope looks good. Tiny English comment: the structure of the points = should be parallel, so I'd edit point 2 to read: =95 specify mechanisms to discover the availability of protocols = on an interface (end system support and path support), in order to = provide a basis for incremental deployment. The resulting document will = explain how to select and engage a protocol in order to deliver a = transport service. I'd also drop the point in the deliverables about rechartering to do an = example API. The working group could recharter to do lots of things. If = you want the text in the charter to head off questions about "why aren't = we doing this", I'd suggest adding a new list beginning with "The = following topics are currently out of scope for this Working Group, but = may be addressed in a future charter:" Cheers, Brian >=20 >> (indeed, I'd leave the deliverables list out of the charter text, and = put the actual documents only in the milestones, but maybe that's just = me). >=20 > I think I'll leave them as they are because: > - Gorry has already made me shorten the text on a milestone because = it's long for the tracker > - your suggestion would make them longer again > - at the same time you seem to indicate that you don't care much about = this detail, so this seems to be the easiest solution for me. >=20 > Cheers, > Michael >=20 --Apple-Mail=_5AF24FE1-F16B-4A88-92CA-EEAB1EA2EBC5 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 iQEcBAEBCgAGBQJThuPNAAoJENt3nsOmbNJcIHMH/2snay/8w9iObqC2qi80+tNY EhCpiC2uq6/CY09CCMlhBhzUZyJWKRhVaiH7L2wLlBS+iQg5CAcL4DFnH5DA2XhU ttTLdof/wZjbZde1wnBFy0bCSxaYZXwO1BHZ2wN6nGDbsfu5Gq5XB/jJdhBa2aU0 L4izSCmKyUx8LTOifDxq9cQZ+DwM+y1JlQVl8mKHVPhZkWcAYYYrrf7ftlixadpv nk0ze2hMD7+PRRbkRIH6BlMC5G9CCvRQHEVcFmdZy7rG5Ur4fDBaueDC15bu9a56 3JQHv6Jaq8C19UYPkg/z58ajSsfrto6srbqGwQsQBP1V/8KzWdHz5stYOsNpNms= =EekA -----END PGP SIGNATURE----- --Apple-Mail=_5AF24FE1-F16B-4A88-92CA-EEAB1EA2EBC5-- From nobody Thu May 29 02:26:03 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFDF1A010B for ; Thu, 29 May 2014 02:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8op7-DEiqvBs for ; Thu, 29 May 2014 02:25:59 -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 85CB61A085E for ; Thu, 29 May 2014 02:25:59 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Wpwav-0008EX-8U; Thu, 29 May 2014 11:25:53 +0200 Received: from cisne-cn10.upc.es ([147.83.182.10] helo=[10.82.30.79]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1Wpwau-0007Hm-J8; Thu, 29 May 2014 11:25:53 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: Date: Thu, 29 May 2014 11:25:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0796CF95-2852-4E9D-B6B4-AEA906D6D23E@ifi.uio.no> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <44BB549A-EC7D-4345-9E60-49476F9EFF5A@ifi.uio.no> To: Brian Trammell X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 2 sum rcpts/h 8 sum msgs/h 5 total rcpts 16926 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: DC9F1BB249FA50910C38183C03578306C7728004 X-UiO-SPAM-Test: remote_host: 147.83.182.10 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 16 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/oNsiqsZU3iGxMuE-sx3ZnBdp_kE Cc: Aaron Falk , taps@ietf.org Subject: Re: [Taps] IETF journal article update 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, 29 May 2014 09:26:02 -0000 On 29. mai 2014, at 09:37, Brian Trammell wrote: >=20 > On 28 May 2014, at 19:11, Michael Welzl wrote: >=20 >>=20 >> On 28. mai 2014, at 19:05, Brian Trammell wrote: >>=20 >>> hi Michael, >>>=20 >>> the short short answer here is that the scope of work is much more = important than the actual division of content across individual = documents >>=20 >> Sure! Any comments about the scope as it's now written? >=20 > Scope looks good. Great! > Tiny English comment: the structure of the points should be parallel, = so I'd edit point 2 to read: >=20 > =95 specify mechanisms to discover the availability of protocols = on an interface (end system support and path support), in order to = provide a basis for incremental deployment. The resulting document will = explain how to select and engage a protocol in order to deliver a = transport service. done > I'd also drop the point in the deliverables about rechartering to do = an example API. The working group could recharter to do lots of things. = If you want the text in the charter to head off questions about "why = aren't we doing this", I'd suggest adding a new list beginning with "The = following topics are currently out of scope for this Working Group, but = may be addressed in a future charter:" Okay; out of these two options, I chose removing the sentence. (I see that a list as you suggest would make more sense than having this = single item, but then again, creating a list on possible future work = seems unnecessary at this stage - we'd end up getting into a long debate = on our potential future visions, which we wanted to avoid with this = charter in the first place.) Cheers, Michael From nobody Thu May 29 02:29: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 A5CAC1A01F2 for ; Thu, 29 May 2014 02:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RI8MUbNx62o for ; Thu, 29 May 2014 02:29:01 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 022E31A010B for ; Thu, 29 May 2014 02:29:01 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 5A6EA2B44D1; Thu, 29 May 2014 10:28:56 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 29 May 2014 10:28:56 +0100 Message-ID: In-Reply-To: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> Date: Thu, 29 May 2014 10:28:56 +0100 From: gorry@erg.abdn.ac.uk To: "Brian Trammell" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/taps/qZe8RnP9HmZkVc_4_OKb8DsbRXM Cc: Aaron Falk , Michael Welzl , taps@ietf.org Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 09:29:03 -0000 (1) I did like the list of deliverables in the description when the group was talking about a BOF. However, I'd agree with Brian T's point that an actual working group charter is best not to include this list. So, I suggest to remove the entire list, and instead just adjust the plain-text describing what the WG will do. Reading again, I think all that is needed could be adding one final sentence about the last work item to the two existing bullets, i.e. something like: "• define a set of Experimental mechanisms to discover the availability of protocols on an interface (both end and path support)." Would that work? (2) I'd also agree with omitting the re-charter line. The scope is now clear. (3) Finally, I think the non-goal concerning tunnels on the last line should be clearer. I suggest the out-of-scope items are actually: "The following topics are out of scope of this Working Group: • mechanisms to specify Quality-of-Service (QoS). • definition of new encapsulations and tunneling mechanisms." - My rationale is that any new specs would seem like tsvwg work (or at least not this group) -- but working with any existing specs could possibly be in scope? At least existing specs that directly encapsulate transport protocols. Gorry - > hi Michael, > > the short short answer here is that the scope of work is much more > important than the actual division of content across individual documents > (indeed, I'd leave the deliverables list out of the charter text, and put > the actual documents only in the milestones, but maybe that's just me). > > Cheers, > > Brian > > On 28 May 2014, at 17:33, Michael Welzl wrote: > >> >> On 28. mai 2014, at 17:23, Brian Trammell wrote: >> >>> >>> On 28 May 2014, at 17:08, Michael Welzl wrote: >>> >>>> Hi Aaron, >>>> >>>> Great input, thanks!! >>>> >>>> >>>> On 28. mai 2014, at 16:55, Aaron Falk wrote: >>>> >>>>> Again, I'm coming into the discussion a little late but I found the >>>>> charter a little hard to understand. Others have tripped over the >>>>> same thing I think. Likely easily solved with a little more preface. >>>>> • The charter says the goal of the wg is 'identifying transport >>>>> services' but that term isn't clearly defined. I think a definition >>>>> needs to be in the charter (esp since it is the name of the wg). >>>>> • 'Encapsulated transports' also needs a definition. >>>>> • Without a distinction between a 'transport service' vs. protocols >>>>> & congestion control mechanisms I can't make sense of working group >>>>> goal #2. Or maybe the first clause should be deleted: ("Specify >>>>> the definition of mechanisms to discover the availability of >>>>> protocols on an interface (end system support and path support.") >>>> >>>> I agree about these things and will propose suitable fixes ASAP. >>>> >>>> >>>>> • Is the informational RFC just a catalog of protocols & congestion >>>>> control mechanisms? I thought the goal was more about finding the >>>>> assembled combinations of such that are useful. >>>> >>>> I thought it should be such a catalog, and the (most) useful >>>> combinations would go into the proposed standard RFC. >>> >>> It might (eventually) make sense to publish these as a single document. >> >> Not sure what you're suggesting. In my mind (but maybe we have a >> different interpretation?), we first have the Informational RFC, which >> is long. Then, the Proposed Standard, which is essentially a shortened >> version of the Informational RFC. >> >> What you say is that we should eventually combine them into one >> document? >> >> => you mean a long document, where the key combinations are marked as >> such? Yes this might make sense, or it might just be a very long >> document that noone wants to read. - again, I'll point to page 51 of >> this document: >> http://heim.ifi.uio.no/~michawe/teaching/dipls/stefan_joerer.pdf - one >> can imagine that the list in the Informational RFC would be 1) much >> longer, 2) much more detailed. >> >> My suggestion: possibly write such a document, but decide that later, as >> (if) we recharter. Ok? If so, do you want me to insert this in the >> sentence about rechartering? (I wouldn't, as we'd really only see at >> the end of the work if this makes sense or not, and as I said I suspect >> the outcome will be negative, just because of the sheer length of the >> result - but fine with me either way). >> >> Cheers, >> Michael > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Thu May 29 03:33:58 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA08C1A08A8 for ; Thu, 29 May 2014 03:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQ7TGka36d80 for ; Thu, 29 May 2014 03:33:54 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C4551A0A23 for ; Thu, 29 May 2014 03:33:54 -0700 (PDT) Received: from mail-mx3.uio.no ([129.240.10.44]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Wpxed-0003rJ-TY; Thu, 29 May 2014 12:33:47 +0200 Received: from cisne-cn10.upc.es ([147.83.182.10] helo=[10.82.30.79]) by mail-mx3.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Wpxed-0005wA-AU; Thu, 29 May 2014 12:33:47 +0200 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=windows-1252 From: Michael Welzl X-Priority: 3 (Normal) In-Reply-To: Date: Thu, 29 May 2014 12:33:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> To: "gorry@erg.abdn.ac.uk (erg)" X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 5 sum rcpts/h 12 sum msgs/h 7 total rcpts 16934 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B5F5B51D6ADF43DEE6F2CE9144DD50BEB274DA85 X-UiO-SPAM-Test: remote_host: 147.83.182.10 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 21 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/fH-U0xH5EoM-Mn_4sJq8kBNvXso Cc: Brian Trammell , Aaron Falk , taps@ietf.org Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 10:33:56 -0000 On 29. mai 2014, at 11:28, gorry@erg.abdn.ac.uk wrote: >=20 >=20 > (1) I did like the list of deliverables in the description when the = group > was talking about a BOF. >=20 > However, I'd agree with Brian T's point that an actual working group > charter is best not to include this list. So, I suggest to remove the > entire list, and instead just adjust the plain-text describing what = the WG > will do. Fine by me - as I wrote before, I left the text in there because I = thought this is how charters typically are written (but I have very = limited experience there). So ok, I'll cut it. > Reading again, I think all that is needed could be adding one > final sentence about the last work item to the two existing bullets, = i.e. > something like: >=20 > "=95 define a set of Experimental mechanisms to discover the = availability of > protocols on an interface (both end and path support)." >=20 > Would that work? Fine in principle, and I see the point, but this sounds like a = repetition of the second bullet in the list. I propose the following = complete text for the "The Working Group will:" bullets (I think it maps = well to the existing milestones): *** =95 identify services provided by existing IETF transport protocols and congestion control mechanisms, based on Standards-track and Experimental RFCs that were developed in the IETF's Transport Area. * specify a set of transport services that end systems need to provide = and provide guidance on making a choice among available mechanisms and protocols to obtain a certain transport service. =95 specify experimental mechanisms as a basis for incremental = deployment to discover the availability of protocols on an interface (both end system = and path support). This will explain how to select and engage a protocol to = deliver a transport service. *** ok? > (2) I'd also agree with omitting the re-charter line. The scope is now = clear. Good; I have already applied that change. > (3) Finally, I think the non-goal concerning tunnels on the last line > should be clearer. I suggest the out-of-scope items are actually: >=20 > "The following topics are out of scope of this Working Group: >=20 > =95 mechanisms to specify Quality-of-Service (QoS). > =95 definition of new encapsulations and tunneling mechanisms." >=20 > - My rationale is that any new specs would seem like tsvwg work (or at > least not this group) -- but working with any existing specs could > possibly be in scope? At least existing specs that directly = encapsulate > transport protocols. Fine by me. As for applying existing encapsulating / tunneling = mechanisms, just because "native and encapsulated transports" isn't = there anymore I don't think there's anything in the charter that = restrains it to only native transports (e.g., SCTP over UDP etc. could = definitely be used?!). Cheers, Michael From nobody Thu May 29 03:49:37 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C321A08B1 for ; Thu, 29 May 2014 03:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yimzMATt4qXO for ; Thu, 29 May 2014 03:49:34 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id BCA761A08A8 for ; Thu, 29 May 2014 03:49:33 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 4A6742B4044; Thu, 29 May 2014 11:49:29 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 29 May 2014 11:49:29 +0100 Message-ID: In-Reply-To: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> Date: Thu, 29 May 2014 11:49:29 +0100 From: gorry@erg.abdn.ac.uk To: "Michael Welzl" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/taps/R7aY_CvHPLdAjmbZL-p7DaTx1yE Cc: "gorry@erg.abdn.ac.uk \(erg\)" , Brian Trammell , Aaron Falk , taps@ietf.org Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 10:49:35 -0000 If others are content, I'd be happy with your proposed text. Gorry > > On 29. mai 2014, at 11:28, gorry@erg.abdn.ac.uk wrote: > >> >> >> (1) I did like the list of deliverables in the description when the >> group >> was talking about a BOF. >> >> However, I'd agree with Brian T's point that an actual working group >> charter is best not to include this list. So, I suggest to remove the >> entire list, and instead just adjust the plain-text describing what the >> WG >> will do. > > Fine by me - as I wrote before, I left the text in there because I thought > this is how charters typically are written (but I have very limited > experience there). So ok, I'll cut it. > > >> Reading again, I think all that is needed could be adding one >> final sentence about the last work item to the two existing bullets, >> i.e. >> something like: >> >> "• define a set of Experimental mechanisms to discover the availability >> of >> protocols on an interface (both end and path support)." >> >> Would that work? > > Fine in principle, and I see the point, but this sounds like a repetition > of the second bullet in the list. I propose the following complete text > for the "The Working Group will:" bullets (I think it maps well to the > existing milestones): > > *** > > • identify services provided by existing IETF transport protocols and > congestion control mechanisms, based on Standards-track and Experimental > RFCs that were developed in the IETF's Transport Area. > > * specify a set of transport services that end systems need to provide and > provide guidance on making a choice among available mechanisms and > protocols to obtain a certain transport service. > > • specify experimental mechanisms as a basis for incremental deployment to > discover the availability of protocols on an interface (both end system > and path > support). This will explain how to select and engage a protocol to deliver > a transport service. > > *** > > ok? > > > >> (2) I'd also agree with omitting the re-charter line. The scope is now >> clear. > > Good; I have already applied that change. > > >> (3) Finally, I think the non-goal concerning tunnels on the last line >> should be clearer. I suggest the out-of-scope items are actually: >> >> "The following topics are out of scope of this Working Group: >> >> • mechanisms to specify Quality-of-Service (QoS). >> • definition of new encapsulations and tunneling mechanisms." >> >> - My rationale is that any new specs would seem like tsvwg work (or at >> least not this group) -- but working with any existing specs could >> possibly be in scope? At least existing specs that directly encapsulate >> transport protocols. > > Fine by me. As for applying existing encapsulating / tunneling mechanisms, > just because "native and encapsulated transports" isn't there anymore I > don't think there's anything in the charter that restrains it to only > native transports (e.g., SCTP over UDP etc. could definitely be used?!). > > Cheers, > Michael > From nobody Thu May 29 03:54:43 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 173DB1A08A9 for ; Thu, 29 May 2014 03:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfWPIXumgrbR for ; Thu, 29 May 2014 03:54:39 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 741E41A089C for ; Thu, 29 May 2014 03:54:39 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ravage.cl.cam.ac.uk ([128.232.1.17]:62046) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1Wpxya-0007Jn-YI (Exim 4.82_3-c0e5623) (return-path ); Thu, 29 May 2014 11:54:24 +0100 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_615CF782-47B9-43D6-8945-DBA34E08C93C" From: Toby Moncaster X-Priority: 3 (Normal) In-Reply-To: Date: Thu, 29 May 2014 11:54:23 +0100 Message-Id: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <51893438-8690-4832-A19A-337633DDBAEB@nrl.navy.mil> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.1878.2) Sender: "T. Moncaster" Archived-At: http://mailarchive.ietf.org/arch/msg/taps/1o_RINIrpaWCwPdUDWR5LPGWGjo Cc: Brian Trammell , Aaron Falk , Michael Welzl , taps@ietf.org Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 10:54:42 -0000 --Apple-Mail=_615CF782-47B9-43D6-8945-DBA34E08C93C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I have one question - do we need to specify =93that were developed in = the IETF=92s Transport Area=94? Could we make it =93were developed in = the IETF=94 I might re-word bullet two to: =93specify a set of transport services that end systems need to provide = and provide guidance on choosing among available mechanisms and protocols to obtain a given transport service." Other than that that I=92m happy with the text Toby On 29 May 2014, at 11:49, gorry@erg.abdn.ac.uk wrote: > If others are content, I'd be happy with your proposed text. >=20 > Gorry >=20 >>=20 >> On 29. mai 2014, at 11:28, gorry@erg.abdn.ac.uk wrote: >>=20 >>>=20 >>>=20 >>> (1) I did like the list of deliverables in the description when the >>> group >>> was talking about a BOF. >>>=20 >>> However, I'd agree with Brian T's point that an actual working group >>> charter is best not to include this list. So, I suggest to remove = the >>> entire list, and instead just adjust the plain-text describing what = the >>> WG >>> will do. >>=20 >> Fine by me - as I wrote before, I left the text in there because I = thought >> this is how charters typically are written (but I have very limited >> experience there). So ok, I'll cut it. >>=20 >>=20 >>> Reading again, I think all that is needed could be adding one >>> final sentence about the last work item to the two existing bullets, >>> i.e. >>> something like: >>>=20 >>> "=95 define a set of Experimental mechanisms to discover the = availability >>> of >>> protocols on an interface (both end and path support)." >>>=20 >>> Would that work? >>=20 >> Fine in principle, and I see the point, but this sounds like a = repetition >> of the second bullet in the list. I propose the following complete = text >> for the "The Working Group will:" bullets (I think it maps well to = the >> existing milestones): >>=20 >> *** >>=20 >> =95 identify services provided by existing IETF transport protocols = and >> congestion control mechanisms, based on Standards-track and = Experimental >> RFCs that were developed in the IETF's Transport Area. >>=20 >> * specify a set of transport services that end systems need to = provide and >> provide guidance on making a choice among available mechanisms and >> protocols to obtain a certain transport service. >>=20 >> =95 specify experimental mechanisms as a basis for incremental = deployment to >> discover the availability of protocols on an interface (both end = system >> and path >> support). This will explain how to select and engage a protocol to = deliver >> a transport service. >>=20 >> *** >>=20 >> ok? >>=20 >>=20 >>=20 >>> (2) I'd also agree with omitting the re-charter line. The scope is = now >>> clear. >>=20 >> Good; I have already applied that change. >>=20 >>=20 >>> (3) Finally, I think the non-goal concerning tunnels on the last = line >>> should be clearer. I suggest the out-of-scope items are actually: >>>=20 >>> "The following topics are out of scope of this Working Group: >>>=20 >>> =95 mechanisms to specify Quality-of-Service (QoS). >>> =95 definition of new encapsulations and tunneling mechanisms." >>>=20 >>> - My rationale is that any new specs would seem like tsvwg work (or = at >>> least not this group) -- but working with any existing specs could >>> possibly be in scope? At least existing specs that directly = encapsulate >>> transport protocols. >>=20 >> Fine by me. As for applying existing encapsulating / tunneling = mechanisms, >> just because "native and encapsulated transports" isn't there anymore = I >> don't think there's anything in the charter that restrains it to only >> native transports (e.g., SCTP over UDP etc. could definitely be = used?!). >>=20 >> Cheers, >> Michael >>=20 >=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_615CF782-47B9-43D6-8945-DBA34E08C93C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I have = one question - do we need to specify =93that were developed in the = IETF=92s Transport Area=94? Could we make it =93were developed in the = IETF=94

I might re-word bullet two = to:

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

Other than that that I=92m happy = with the = text

Toby

On = 29 May 2014, at 11:49, gorry@erg.abdn.ac.uk = wrote:

If others are content, I'd be happy with your proposed = text.

Gorry


On 29. mai 2014, = at 11:28, gorry@erg.abdn.ac.uk= wrote:



(1) I did like the list = of deliverables in the description when the
group
was talking = about a BOF.

However, I'd agree with Brian T's point that an = actual working group
charter is best not to include this list. So, I = suggest to remove the
entire list, and instead just adjust the = plain-text describing what the
WG
will = do.

Fine by me - as I wrote before, I left the text = in there because I thought
this is how charters typically are written = (but I have very limited
experience there). So ok, I'll cut = it.


Reading again,  I think = all that is needed could be adding one
final sentence about the last = work item to the two existing bullets,
i.e.
something = like:

"=95 define a set of Experimental mechanisms to discover = the availability
of
protocols on an interface (both end and path = support)."

Would that work?

Fine in = principle, and I see the point, but this sounds like a repetition
of = the second bullet in the list. I propose the following complete = text
for the "The Working Group will:" bullets (I think it maps well = to the
existing milestones):

***

=95 identify services = provided by existing IETF transport protocols and
congestion control = mechanisms, based on Standards-track and Experimental
RFCs that were = developed in the IETF's Transport Area.

* specify a set of = transport services that end systems need to provide and
provide = guidance on making a choice among available mechanisms and
protocols = to obtain a certain transport service.

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

***

ok?



(2) I'd also agree with omitting the re-charter line. The = scope is now
clear.

Good; I have already applied = that change.


(3) Finally, I think = the non-goal concerning tunnels on the last line
should be clearer. I = suggest the out-of-scope items are actually:

"The following = topics are out of scope of this Working Group:

=95 mechanisms to = specify Quality-of-Service (QoS).
=95 definition of new = encapsulations and tunneling mechanisms."

- My rationale is that = any new specs would seem like tsvwg work (or at
least not this group) = -- but working with any existing specs could
possibly be in scope? At = least existing specs that  directly encapsulate
transport = protocols.

Fine by me. As for applying existing = encapsulating / tunneling mechanisms,
just because "native and = encapsulated transports" isn't there anymore I
don't think there's = anything in the charter that restrains it to only
native transports =  (e.g., SCTP over UDP etc. could definitely be = used?!).

Cheers,
Michael



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

= --Apple-Mail=_615CF782-47B9-43D6-8945-DBA34E08C93C-- From nobody Thu May 29 04:04:14 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6035C1A08B2 for ; Thu, 29 May 2014 04:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-psMX9aXnJf for ; Thu, 29 May 2014 04:04:10 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 464FD1A088D for ; Thu, 29 May 2014 04:04:10 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id CBE1B2B4044; Thu, 29 May 2014 12:04:05 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 29 May 2014 12:04:05 +0100 Message-ID: <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> In-Reply-To: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <537C8F99.8040308@erg.abdn.ac.uk> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> Date: Thu, 29 May 2014 12:04:05 +0100 From: gorry@erg.abdn.ac.uk To: "Toby Moncaster" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/taps/TkO25QhE4xo27TSbTh2Zoc9v4gw Cc: gorry@erg.abdn.ac.uk, Brian Trammell , Aaron Falk , Michael Welzl , taps@ietf.org Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 11:04:12 -0000 See inline > I have one question - do we need to specify “that were developed in the > IETF’s Transport Area”? Could we make it “were developed in the IETF” > Would work for me too -- but I do think the work should be confined to transport protocols in the IETF. > I might re-word bullet two to: > > “specify a set of transport services that end systems need to provide and > provide guidance on choosing among available mechanisms and > protocols to obtain a given transport service." > That would also be OK > Other than that that I’m happy with the text > > Toby > > On 29 May 2014, at 11:49, gorry@erg.abdn.ac.uk wrote: > >> If others are content, I'd be happy with your proposed text. >> >> Gorry >> >>> >>> On 29. mai 2014, at 11:28, gorry@erg.abdn.ac.uk wrote: >>> >>>> >>>> >>>> (1) I did like the list of deliverables in the description when the >>>> group >>>> was talking about a BOF. >>>> >>>> However, I'd agree with Brian T's point that an actual working group >>>> charter is best not to include this list. So, I suggest to remove the >>>> entire list, and instead just adjust the plain-text describing what >>>> the >>>> WG >>>> will do. >>> >>> Fine by me - as I wrote before, I left the text in there because I >>> thought >>> this is how charters typically are written (but I have very limited >>> experience there). So ok, I'll cut it. >>> >>> >>>> Reading again, I think all that is needed could be adding one >>>> final sentence about the last work item to the two existing bullets, >>>> i.e. >>>> something like: >>>> >>>> "• define a set of Experimental mechanisms to discover the >>>> availability >>>> of >>>> protocols on an interface (both end and path support)." >>>> >>>> Would that work? >>> >>> Fine in principle, and I see the point, but this sounds like a >>> repetition >>> of the second bullet in the list. I propose the following complete text >>> for the "The Working Group will:" bullets (I think it maps well to the >>> existing milestones): >>> >>> *** >>> >>> • identify services provided by existing IETF transport protocols and >>> congestion control mechanisms, based on Standards-track and >>> Experimental >>> RFCs that were developed in the IETF's Transport Area. >>> >>> * specify a set of transport services that end systems need to provide >>> and >>> provide guidance on making a choice among available mechanisms and >>> protocols to obtain a certain transport service. >>> >>> • specify experimental mechanisms as a basis for incremental deployment >>> to >>> discover the availability of protocols on an interface (both end system >>> and path >>> support). This will explain how to select and engage a protocol to >>> deliver >>> a transport service. >>> >>> *** >>> >>> ok? >>> >>> >>> >>>> (2) I'd also agree with omitting the re-charter line. The scope is now >>>> clear. >>> >>> Good; I have already applied that change. >>> >>> >>>> (3) Finally, I think the non-goal concerning tunnels on the last line >>>> should be clearer. I suggest the out-of-scope items are actually: >>>> >>>> "The following topics are out of scope of this Working Group: >>>> >>>> • mechanisms to specify Quality-of-Service (QoS). >>>> • definition of new encapsulations and tunneling mechanisms." >>>> >>>> - My rationale is that any new specs would seem like tsvwg work (or at >>>> least not this group) -- but working with any existing specs could >>>> possibly be in scope? At least existing specs that directly >>>> encapsulate >>>> transport protocols. >>> >>> Fine by me. As for applying existing encapsulating / tunneling >>> mechanisms, >>> just because "native and encapsulated transports" isn't there anymore I >>> don't think there's anything in the charter that restrains it to only >>> native transports (e.g., SCTP over UDP etc. could definitely be >>> used?!). >>> >>> Cheers, >>> Michael >>> >> >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > From nobody Thu May 29 04:22: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 7B54B1A08A2 for ; Thu, 29 May 2014 04:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35] 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 85MKcx-jlN_L for ; Thu, 29 May 2014 04:22:32 -0700 (PDT) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FCFE1A01B3 for ; Thu, 29 May 2014 04:22:32 -0700 (PDT) X-Spam-Processed: mail.kau.se, Thu, 29 May 2014 13:22:17 +0200 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: annabrun@kau.se X-MDRemoteIP: 213.113.183.212 X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se X-MDaemon-Deliver-To: taps@ietf.org Message-ID: <5387186C.5010800@kau.se> Date: Thu, 29 May 2014 13:22:20 +0200 From: Anna Brunstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: taps@ietf.org References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/pYuagsVffmvE5B58xyiBSZPc-pA Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 11:22:34 -0000 Hi, I think you lost Brian's update related to bullet three. I think it would be more clear to say: "specify experimental mechanisms to discover the availability of protocols on an interface (both end system and path support), in order to provide a basis for incremental deployment. This will explain how to select and engage a protocol to deliver a transport service." Toby's update for bullet two looks good to me. I also agree with Gorry that the work should be confined to transport protocols in the IETF. Anna On 2014-05-29 13:04, gorry@erg.abdn.ac.uk wrote: > See inline > >> I have one question - do we need to specify “that were developed in the >> IETF’s Transport Area”? Could we make it “were developed in the IETF” >> > Would work for me too -- but I do think the work should be confined to > transport protocols in the IETF. > >> I might re-word bullet two to: >> >> “specify a set of transport services that end systems need to provide and >> provide guidance on choosing among available mechanisms and >> protocols to obtain a given transport service." >> > That would also be OK > >> Other than that that I’m happy with the text >> >> Toby >> >> On 29 May 2014, at 11:49, gorry@erg.abdn.ac.uk wrote: >> >>> If others are content, I'd be happy with your proposed text. >>> >>> Gorry >>> >>>> On 29. mai 2014, at 11:28, gorry@erg.abdn.ac.uk wrote: >>>> >>>>> >>>>> (1) I did like the list of deliverables in the description when the >>>>> group >>>>> was talking about a BOF. >>>>> >>>>> However, I'd agree with Brian T's point that an actual working group >>>>> charter is best not to include this list. So, I suggest to remove the >>>>> entire list, and instead just adjust the plain-text describing what >>>>> the >>>>> WG >>>>> will do. >>>> Fine by me - as I wrote before, I left the text in there because I >>>> thought >>>> this is how charters typically are written (but I have very limited >>>> experience there). So ok, I'll cut it. >>>> >>>> >>>>> Reading again, I think all that is needed could be adding one >>>>> final sentence about the last work item to the two existing bullets, >>>>> i.e. >>>>> something like: >>>>> >>>>> "• define a set of Experimental mechanisms to discover the >>>>> availability >>>>> of >>>>> protocols on an interface (both end and path support)." >>>>> >>>>> Would that work? >>>> Fine in principle, and I see the point, but this sounds like a >>>> repetition >>>> of the second bullet in the list. I propose the following complete text >>>> for the "The Working Group will:" bullets (I think it maps well to the >>>> existing milestones): >>>> >>>> *** >>>> >>>> • identify services provided by existing IETF transport protocols and >>>> congestion control mechanisms, based on Standards-track and >>>> Experimental >>>> RFCs that were developed in the IETF's Transport Area. >>>> >>>> * specify a set of transport services that end systems need to provide >>>> and >>>> provide guidance on making a choice among available mechanisms and >>>> protocols to obtain a certain transport service. >>>> >>>> • specify experimental mechanisms as a basis for incremental deployment >>>> to >>>> discover the availability of protocols on an interface (both end system >>>> and path >>>> support). This will explain how to select and engage a protocol to >>>> deliver >>>> a transport service. >>>> >>>> *** >>>> >>>> ok? >>>> >>>> >>>> >>>>> (2) I'd also agree with omitting the re-charter line. The scope is now >>>>> clear. >>>> Good; I have already applied that change. >>>> >>>> >>>>> (3) Finally, I think the non-goal concerning tunnels on the last line >>>>> should be clearer. I suggest the out-of-scope items are actually: >>>>> >>>>> "The following topics are out of scope of this Working Group: >>>>> >>>>> • mechanisms to specify Quality-of-Service (QoS). >>>>> • definition of new encapsulations and tunneling mechanisms." >>>>> >>>>> - My rationale is that any new specs would seem like tsvwg work (or at >>>>> least not this group) -- but working with any existing specs could >>>>> possibly be in scope? At least existing specs that directly >>>>> encapsulate >>>>> transport protocols. >>>> Fine by me. As for applying existing encapsulating / tunneling >>>> mechanisms, >>>> just because "native and encapsulated transports" isn't there anymore I >>>> don't think there's anything in the charter that restrains it to only >>>> native transports (e.g., SCTP over UDP etc. could definitely be >>>> used?!). >>>> >>>> Cheers, >>>> Michael >>>> >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >> > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu May 29 04:56: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 B40DC1A00C6 for ; Thu, 29 May 2014 04:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByBphBjVrKgD for ; Thu, 29 May 2014 04:56:42 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25481A0049 for ; Thu, 29 May 2014 04:56:41 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Wpywm-0005PG-DE; Thu, 29 May 2014 13:56:36 +0200 Received: from cisne-cn10.upc.es ([147.83.182.10] helo=[10.82.30.79]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Wpywl-0000dw-N8; Thu, 29 May 2014 13:56:36 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <5387186C.5010800@kau.se> Date: Thu, 29 May 2014 13:56:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <5387186C.501080 0@kau.se> To: Anna Brunstrom X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 2 msgs/h 1 sum rcpts/h 7 sum msgs/h 3 total rcpts 16936 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A754C63A7EBB5F8ECD4A35983C331D0BFFD937C8 X-UiO-SPAM-Test: remote_host: 147.83.182.10 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 22 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/_k7sMxFY8DTiP1PXwTCw2cYRNBw Cc: taps@ietf.org Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 11:56:44 -0000 Hi, Thank you all for your updates! Great work! About this, from Gorry = (that Anna agrees with): >Would work for me too -- but I do think the work should be confined to >transport protocols in the IETF. This is the original sentence that we're talking about: *** identify services provided by existing IETF transport protocols and = congestion control mechanisms, based on Standards-track and Experimental = RFCs that were developed in the IETF's Transport Area. *** The proposal of Toby was to not limit the RFCs to the IETF's *Transport = Area*. Changing this text to "in the IETF" makes it redundant, as "IETF = transport protocols" is already there anyway. So I now changed it to: *** identify services provided by existing IETF transport protocols and = congestion control mechanisms, based on Standards-track and Experimental = RFCs. *** I changed this in the text and incorporated all the other suggested = changes, please check at https://sites.google.com/site/transportprotocolservices/charter-proposal if I didn't make a mistake. At least one person told me about problems reaching the page, so I'm = copying the whole text in at the end of this email too. Cheers, Michael ****** Transport Services (TAPS) Status: Proposed Working Group Last Updated: 2014-05-29 Chair(s): TBD Transport Area Director(s): Spencer Dawkins Martin Stiemerling Transport Area Advisor: TBD Mailing Lists: taps@ietf.org Description of Working Group Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and = the LEDBAT congestion control mechanism extend the number of transport = services to applications in addition to the long-standing two services = provided by TCP and UDP. For example, SCTP provides potentially faster = reliable delivery for applications that can accept blocks of data out of = order, and LEDBAT provides low-priority "scavenger" communication. For = an application programmer, it is hard to use protocols other than TCP or = UDP: not all protocols are available everywhere, hence a fall-back = solution to e.g. TCP or UDP must be implemented. Some protocols provide = the same services in different ways. Layering decisions must be made = (e.g. should a protocol be used natively or over UDP?). Because of these = complications, programmers often resort to either using TCP or = implementing their own customized solution over UDP, and chances of = benefiting from other transport protocols are lost. There are many ways in which this problem could be addressed; while it = may not yet be clear what the best way forward could be, any approach to = provide a richer set of transport services to applications will have to = begin with the identification of the services that current transport = protocols provide. The Working Group will: =95 identify services provided by existing IETF transport = protocols and congestion control mechanisms, based on Standards-track = and Experimental RFCs. The resulting document will provide guidance on = making a choice among available mechanisms and protocols to obtain a = certain transport service. =95 specify a set of transport services that end systems need to = provide and provide guidance on choosing among available mechanisms and = protocols to obtain a given transport service. =95 specify experimental mechanisms to discover the availability = of protocols on an interface (both end system and path support), in = order to provide a basis for incremental deployment. This will explain = how to select and engage a protocol to deliver a transport service. The Working Group will coordinate closely with other Working Groups = and/or IRTF Research Groups. The following topics are out of scope of this Working Group: =95 Quality-of-Service (QoS) and tunneling mechanisms and = services =95 Definition of new encapsulations and tunneling mechanisms Deliverables: =95 Informational RFC summarizing the services provided by IETF = transport protocols and congestion control mechanisms =95 Proposed Standard RFC specifying a set of transport services = that end systems need to provide =95 Experimental RFC specifying how the defined transport = services can be provided using IETF transports, including the definition = of mechanisms to discover the availability of protocols on an interface = (end system support and path support). Milestones: =95 M7: Submit summary of the services provided by IETF = transport protocols and congestion control mechanisms to IESG as an = Informational RFC. =95 M13: Submit end system transport services to IESG as a = Proposed Standard. =95 M14: Submit specification of how the transport services can = be provided to IESG as an Experimental RFC. From nobody Thu May 29 05:01:36 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63CC91A08A2 for ; Thu, 29 May 2014 05:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87DMGyWj0Vil for ; Thu, 29 May 2014 05:01:32 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19961A0687 for ; Thu, 29 May 2014 05:01:31 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ravage.cl.cam.ac.uk ([128.232.1.17]:62459) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1Wpz1R-0001tF-WW (Exim 4.82_3-c0e5623) (return-path ); Thu, 29 May 2014 13:01:25 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Toby Moncaster In-Reply-To: Date: Thu, 29 May 2014 13:01:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <5387186C.501080 0@kau.se> To: Michael Welzl X-Mailer: Apple Mail (2.1878.2) Sender: "T. Moncaster" Archived-At: http://mailarchive.ietf.org/arch/msg/taps/heFT7Mli66puSsBT_cRpupOk8F0 Cc: Anna Brunstrom , taps@ietf.org Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 12:01:34 -0000 final nit=85 I think we should say=20 =93=85coordinate closely with other Working Group and IRTF Research = Groups.=94 (not and/or) Also wasn=92t Spencer encouraging us to mention potential IAB = interaction? In which case this would be the sentence to say that in=85 Toby On 29 May 2014, at 12:56, Michael Welzl wrote: > Hi, >=20 > Thank you all for your updates! Great work! About this, from Gorry = (that Anna agrees with): >=20 >> Would work for me too -- but I do think the work should be confined = to >> transport protocols in the IETF. >=20 > This is the original sentence that we're talking about: >=20 > *** > identify services provided by existing IETF transport protocols and = congestion control mechanisms, based on Standards-track and Experimental = RFCs that were developed in the IETF's Transport Area. > *** >=20 > The proposal of Toby was to not limit the RFCs to the IETF's = *Transport Area*. Changing this text to "in the IETF" makes it = redundant, as "IETF transport protocols" is already there anyway. So I = now changed it to: >=20 > *** > identify services provided by existing IETF transport protocols and = congestion control mechanisms, based on Standards-track and Experimental = RFCs. > *** >=20 > I changed this in the text and incorporated all the other suggested = changes, please check at > = https://sites.google.com/site/transportprotocolservices/charter-proposal > if I didn't make a mistake. >=20 > At least one person told me about problems reaching the page, so I'm = copying the whole text in at the end of this email too. >=20 > Cheers, > Michael >=20 > ****** >=20 > Transport Services (TAPS) >=20 > Status: Proposed Working Group > Last Updated: 2014-05-29 >=20 > Chair(s): > TBD >=20 > Transport Area Director(s): > Spencer Dawkins > Martin Stiemerling >=20 > Transport Area Advisor: > TBD >=20 > Mailing Lists: taps@ietf.org >=20 >=20 > Description of Working Group >=20 > Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite = and the LEDBAT congestion control mechanism extend the number of = transport services to applications in addition to the long-standing two = services provided by TCP and UDP. For example, SCTP provides potentially = faster reliable delivery for applications that can accept blocks of data = out of order, and LEDBAT provides low-priority "scavenger" = communication. For an application programmer, it is hard to use = protocols other than TCP or UDP: not all protocols are available = everywhere, hence a fall-back solution to e.g. TCP or UDP must be = implemented. Some protocols provide the same services in different ways. = Layering decisions must be made (e.g. should a protocol be used natively = or over UDP?). Because of these complications, programmers often resort = to either using TCP or implementing their own customized solution over = UDP, and chances of benefiting from other transport protocols are lost. >=20 > There are many ways in which this problem could be addressed; while it = may not yet be clear what the best way forward could be, any approach to = provide a richer set of transport services to applications will have to = begin with the identification of the services that current transport = protocols provide. >=20 > The Working Group will: > =95 identify services provided by existing IETF transport = protocols and congestion control mechanisms, based on Standards-track = and Experimental RFCs. The resulting document will provide guidance on = making a choice among available mechanisms and protocols to obtain a = certain transport service. > =95 specify a set of transport services that end systems need to = provide and provide guidance on choosing among available mechanisms and = protocols to obtain a given transport service. > =95 specify experimental mechanisms to discover the availability = of protocols on an interface (both end system and path support), in = order to provide a basis for incremental deployment. This will explain = how to select and engage a protocol to deliver a transport service. >=20 > The Working Group will coordinate closely with other Working Groups = and/or IRTF Research Groups. >=20 > The following topics are out of scope of this Working Group: > =95 Quality-of-Service (QoS) and tunneling mechanisms and = services > =95 Definition of new encapsulations and tunneling mechanisms >=20 > Deliverables: > =95 Informational RFC summarizing the services provided by IETF = transport protocols and congestion control mechanisms > =95 Proposed Standard RFC specifying a set of transport services = that end systems need to provide > =95 Experimental RFC specifying how the defined transport = services can be provided using IETF transports, including the definition = of mechanisms to discover the availability of protocols on an interface = (end system support and path support). >=20 > Milestones: > =95 M7: Submit summary of the services provided by IETF = transport protocols and congestion control mechanisms to IESG as an = Informational RFC. > =95 M13: Submit end system transport services to IESG as a = Proposed Standard. > =95 M14: Submit specification of how the transport services can = be provided to IESG as an Experimental RFC. >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu May 29 05:09:48 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 96DE51A08D2 for ; Thu, 29 May 2014 05:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 iIss9YDd-QvU for ; Thu, 29 May 2014 05:09:43 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3377E1A08C8 for ; Thu, 29 May 2014 05:09:43 -0700 (PDT) Received: from [192.168.1.200] (p508F0AE5.dip0.t-ipconnect.de [80.143.10.229]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id AA5EA1C104903; Thu, 29 May 2014 14:09:36 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Tuexen In-Reply-To: Date: Thu, 29 May 2014 14:09:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8AD9B5C2-8EE2-4444-B89D-D6C3268367AB@fh-muenster.de> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <5387186C.501080 0@kau.se> To: Michael Welzl X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/kVrSot8J2ofjz7oNISEnG9cesuE Cc: Anna Brunstrom , taps@ietf.org Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 12:09:45 -0000 On 29 May 2014, at 13:56, Michael Welzl wrote: > Hi, >=20 > Thank you all for your updates! Great work! About this, from Gorry = (that Anna agrees with): >=20 >> Would work for me too -- but I do think the work should be confined = to >> transport protocols in the IETF. >=20 > This is the original sentence that we're talking about: >=20 > *** > identify services provided by existing IETF transport protocols and = congestion control mechanisms, based on Standards-track and Experimental = RFCs that were developed in the IETF's Transport Area. > *** >=20 > The proposal of Toby was to not limit the RFCs to the IETF's = *Transport Area*. Changing this text to "in the IETF" makes it = redundant, as "IETF transport protocols" is already there anyway. So I = now changed it to: >=20 > *** > identify services provided by existing IETF transport protocols and = congestion control mechanisms, based on Standards-track and Experimental = RFCs. > *** Just to double check: We obviously want to exclude Historic RFCs. Is the = same true for Informational ones? Best regards Michael >=20 > I changed this in the text and incorporated all the other suggested = changes, please check at > = https://sites.google.com/site/transportprotocolservices/charter-proposal > if I didn't make a mistake. >=20 > At least one person told me about problems reaching the page, so I'm = copying the whole text in at the end of this email too. >=20 > Cheers, > Michael >=20 > ****** >=20 > Transport Services (TAPS) >=20 > Status: Proposed Working Group > Last Updated: 2014-05-29 >=20 > Chair(s): > TBD >=20 > Transport Area Director(s): > Spencer Dawkins > Martin Stiemerling >=20 > Transport Area Advisor: > TBD >=20 > Mailing Lists: taps@ietf.org >=20 >=20 > Description of Working Group >=20 > Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite = and the LEDBAT congestion control mechanism extend the number of = transport services to applications in addition to the long-standing two = services provided by TCP and UDP. For example, SCTP provides potentially = faster reliable delivery for applications that can accept blocks of data = out of order, and LEDBAT provides low-priority "scavenger" = communication. For an application programmer, it is hard to use = protocols other than TCP or UDP: not all protocols are available = everywhere, hence a fall-back solution to e.g. TCP or UDP must be = implemented. Some protocols provide the same services in different ways. = Layering decisions must be made (e.g. should a protocol be used natively = or over UDP?). Because of these complications, programmers often resort = to either using TCP or implementing their own customized solution over = UDP, and chances of benefiting from other transport protocols are lost. >=20 > There are many ways in which this problem could be addressed; while it = may not yet be clear what the best way forward could be, any approach to = provide a richer set of transport services to applications will have to = begin with the identification of the services that current transport = protocols provide. >=20 > The Working Group will: > =95 identify services provided by existing IETF transport = protocols and congestion control mechanisms, based on Standards-track = and Experimental RFCs. The resulting document will provide guidance on = making a choice among available mechanisms and protocols to obtain a = certain transport service. > =95 specify a set of transport services that end systems need to = provide and provide guidance on choosing among available mechanisms and = protocols to obtain a given transport service. > =95 specify experimental mechanisms to discover the availability = of protocols on an interface (both end system and path support), in = order to provide a basis for incremental deployment. This will explain = how to select and engage a protocol to deliver a transport service. >=20 > The Working Group will coordinate closely with other Working Groups = and/or IRTF Research Groups. >=20 > The following topics are out of scope of this Working Group: > =95 Quality-of-Service (QoS) and tunneling mechanisms and = services > =95 Definition of new encapsulations and tunneling mechanisms >=20 > Deliverables: > =95 Informational RFC summarizing the services provided by IETF = transport protocols and congestion control mechanisms > =95 Proposed Standard RFC specifying a set of transport services = that end systems need to provide > =95 Experimental RFC specifying how the defined transport = services can be provided using IETF transports, including the definition = of mechanisms to discover the availability of protocols on an interface = (end system support and path support). >=20 > Milestones: > =95 M7: Submit summary of the services provided by IETF = transport protocols and congestion control mechanisms to IESG as an = Informational RFC. > =95 M13: Submit end system transport services to IESG as a = Proposed Standard. > =95 M14: Submit specification of how the transport services can = be provided to IESG as an Experimental RFC. >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps >=20 From nobody Thu May 29 05:11:43 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 1FFD11A0687 for ; Thu, 29 May 2014 05:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wwuwcl-QTOPv for ; Thu, 29 May 2014 05:11:35 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 2600A1A00C2 for ; Thu, 29 May 2014 05:11:35 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id A11D42B4044; Thu, 29 May 2014 13:11:30 +0100 (BST) Received: from 139.133.204.42 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 29 May 2014 13:11:30 +0100 Message-ID: In-Reply-To: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <5387186C.501080 0@kau.se> Date: Thu, 29 May 2014 13:11:30 +0100 From: gorry@erg.abdn.ac.uk To: "Toby Moncaster" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/taps/DyimSkx0J3uHyDqDLxpRgxPKJLs Cc: Anna Brunstrom , Michael Welzl , taps@ietf.org Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 12:11:41 -0000 Maybe the IAB don't need a specific mention here? - If they do work it'll become visible and I am sure we can coordinate - including it seems like the group somehow needs to take specific notice of something. Gorry > final nit… I think we should say > > “…coordinate closely with other Working Group and IRTF Research Groups.” > (not and/or) > > Also wasn’t Spencer encouraging us to mention potential IAB interaction? > In which case this would be the sentence to say that in… > > Toby > > On 29 May 2014, at 12:56, Michael Welzl wrote: > >> Hi, >> >> Thank you all for your updates! Great work! About this, from Gorry >> (that Anna agrees with): >> >>> Would work for me too -- but I do think the work should be confined to >>> transport protocols in the IETF. >> >> This is the original sentence that we're talking about: >> >> *** >> identify services provided by existing IETF transport protocols and >> congestion control mechanisms, based on Standards-track and Experimental >> RFCs that were developed in the IETF's Transport Area. >> *** >> >> The proposal of Toby was to not limit the RFCs to the IETF's *Transport >> Area*. Changing this text to "in the IETF" makes it redundant, as "IETF >> transport protocols" is already there anyway. So I now changed it to: >> >> *** >> identify services provided by existing IETF transport protocols and >> congestion control mechanisms, based on Standards-track and Experimental >> RFCs. >> *** >> >> I changed this in the text and incorporated all the other suggested >> changes, please check at >> https://sites.google.com/site/transportprotocolservices/charter-proposal >> if I didn't make a mistake. >> >> At least one person told me about problems reaching the page, so I'm >> copying the whole text in at the end of this email too. >> >> Cheers, >> Michael >> >> ****** >> >> Transport Services (TAPS) >> >> Status: Proposed Working Group >> Last Updated: 2014-05-29 >> >> Chair(s): >> TBD >> >> Transport Area Director(s): >> Spencer Dawkins >> Martin Stiemerling >> >> Transport Area Advisor: >> TBD >> >> Mailing Lists: taps@ietf.org >> >> >> Description of Working Group >> >> Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and >> the LEDBAT congestion control mechanism extend the number of transport >> services to applications in addition to the long-standing two services >> provided by TCP and UDP. For example, SCTP provides potentially faster >> reliable delivery for applications that can accept blocks of data out of >> order, and LEDBAT provides low-priority "scavenger" communication. For >> an application programmer, it is hard to use protocols other than TCP or >> UDP: not all protocols are available everywhere, hence a fall-back >> solution to e.g. TCP or UDP must be implemented. Some protocols provide >> the same services in different ways. Layering decisions must be made >> (e.g. should a protocol be used natively or over UDP?). Because of these >> complications, programmers often resort to either using TCP or >> implementing their own customized solution over UDP, and chances of >> benefiting from other transport protocols are lost. >> >> There are many ways in which this problem could be addressed; while it >> may not yet be clear what the best way forward could be, any approach to >> provide a richer set of transport services to applications will have to >> begin with the identification of the services that current transport >> protocols provide. >> >> The Working Group will: >> • identify services provided by existing IETF transport protocols and >> congestion control mechanisms, based on Standards-track and >> Experimental RFCs. The resulting document will provide guidance on >> making a choice among available mechanisms and protocols to obtain a >> certain transport service. >> • specify a set of transport services that end systems need to provide >> and provide guidance on choosing among available mechanisms and >> protocols to obtain a given transport service. >> • specify experimental mechanisms to discover the availability of >> protocols on an interface (both end system and path support), in order >> to provide a basis for incremental deployment. This will explain how to >> select and engage a protocol to deliver a transport service. >> >> The Working Group will coordinate closely with other Working Groups >> and/or IRTF Research Groups. >> >> The following topics are out of scope of this Working Group: >> • Quality-of-Service (QoS) and tunneling mechanisms and services >> • Definition of new encapsulations and tunneling mechanisms >> >> Deliverables: >> • Informational RFC summarizing the services provided by IETF transport >> protocols and congestion control mechanisms >> • Proposed Standard RFC specifying a set of transport services that end >> systems need to provide >> • Experimental RFC specifying how the defined transport services can be >> provided using IETF transports, including the definition of mechanisms >> to discover the availability of protocols on an interface (end system >> support and path support). >> >> Milestones: >> • M7: Submit summary of the services provided by IETF transport >> protocols and congestion control mechanisms to IESG as an Informational >> RFC. >> • M13: Submit end system transport services to IESG as a Proposed >> Standard. >> • M14: Submit specification of how the transport services can be >> provided to IESG as an Experimental RFC. >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Thu May 29 05:14:08 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D3C1A01B3 for ; Thu, 29 May 2014 05:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6K_CMfjZdtgr for ; Thu, 29 May 2014 05:14:05 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0452E1A00C2 for ; Thu, 29 May 2014 05:14:05 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WpzDb-0000nJ-Lq; Thu, 29 May 2014 14:13:59 +0200 Received: from cisne-cn10.upc.es ([147.83.182.10] helo=[10.82.30.79]) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WpzDb-0004pI-5k; Thu, 29 May 2014 14:13:59 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: Date: Thu, 29 May 2014 14:13:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <5387186C.501080 0@kau.se> To: Toby Moncaster X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 6 sum msgs/h 2 total rcpts 16939 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: E5C07B28C3CE770EDF1C13FFDA6AEB98E307F7BC X-UiO-SPAM-Test: remote_host: 147.83.182.10 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 23 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/z6ffA2tl_lk8A9BRsPfNDfanhlY Cc: Anna Brunstrom , taps@ietf.org Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 12:14:06 -0000 On 29. mai 2014, at 14:01, Toby Moncaster = wrote: > final nit=85 I think we should say=20 >=20 > =93=85coordinate closely with other Working Group and IRTF Research = Groups.=94 (not and/or) fixed > Also wasn=92t Spencer encouraging us to mention potential IAB = interaction? In which case this would be the sentence to say that in=85 Since I don't think I'm the right person to decide whether the IAB = should be mentioned or not I'll see what happens on the list upon = Gorry's response before incorporating text on that. Cheers, Michael From nobody Thu May 29 05:16: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 BEF5F1A0687 for ; Thu, 29 May 2014 05:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxQAmLChdsAB for ; Thu, 29 May 2014 05:16:34 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id F01801A08D9 for ; Thu, 29 May 2014 05:16:29 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 9B0B42B44D1; Thu, 29 May 2014 13:16:25 +0100 (BST) Received: from 139.133.204.42 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 29 May 2014 13:16:25 +0100 Message-ID: In-Reply-To: <8AD9B5C2-8EE2-4444-B89D-D6C3268367AB@fh-muenster.de> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <5387186C.501080 0@kau.se> <8AD9B5C2-8EE2-4444-B89D-D6C3268367AB@fh-muenster.de> Date: Thu, 29 May 2014 13:16:25 +0100 From: gorry@erg.abdn.ac.uk To: "Michael Tuexen" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/taps/FKm4Xq57GajCo6QXoGniQ1-pzPs Cc: Anna Brunstrom , Michael Welzl , taps@ietf.org Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 12:16:37 -0000 I'd suspect we don't need to go adding wording about INFO specs. The important thing the group needs to include the standards-track methods. Gorry > On 29 May 2014, at 13:56, Michael Welzl wrote: > >> Hi, >> >> Thank you all for your updates! Great work! About this, from Gorry >> (that Anna agrees with): >> >>> Would work for me too -- but I do think the work should be confined to >>> transport protocols in the IETF. >> >> This is the original sentence that we're talking about: >> >> *** >> identify services provided by existing IETF transport protocols and >> congestion control mechanisms, based on Standards-track and Experimental >> RFCs that were developed in the IETF's Transport Area. >> *** >> >> The proposal of Toby was to not limit the RFCs to the IETF's *Transport >> Area*. Changing this text to "in the IETF" makes it redundant, as "IETF >> transport protocols" is already there anyway. So I now changed it to: >> >> *** >> identify services provided by existing IETF transport protocols and >> congestion control mechanisms, based on Standards-track and Experimental >> RFCs. >> *** > Just to double check: We obviously want to exclude Historic RFCs. Is the > same > true for Informational ones? > > Best regards > Michael >> >> I changed this in the text and incorporated all the other suggested >> changes, please check at >> https://sites.google.com/site/transportprotocolservices/charter-proposal >> if I didn't make a mistake. >> >> At least one person told me about problems reaching the page, so I'm >> copying the whole text in at the end of this email too. >> >> Cheers, >> Michael >> >> ****** >> >> Transport Services (TAPS) >> >> Status: Proposed Working Group >> Last Updated: 2014-05-29 >> >> Chair(s): >> TBD >> >> Transport Area Director(s): >> Spencer Dawkins >> Martin Stiemerling >> >> Transport Area Advisor: >> TBD >> >> Mailing Lists: taps@ietf.org >> >> >> Description of Working Group >> >> Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite and >> the LEDBAT congestion control mechanism extend the number of transport >> services to applications in addition to the long-standing two services >> provided by TCP and UDP. For example, SCTP provides potentially faster >> reliable delivery for applications that can accept blocks of data out of >> order, and LEDBAT provides low-priority "scavenger" communication. For >> an application programmer, it is hard to use protocols other than TCP or >> UDP: not all protocols are available everywhere, hence a fall-back >> solution to e.g. TCP or UDP must be implemented. Some protocols provide >> the same services in different ways. Layering decisions must be made >> (e.g. should a protocol be used natively or over UDP?). Because of these >> complications, programmers often resort to either using TCP or >> implementing their own customized solution over UDP, and chances of >> benefiting from other transport protocols are lost. >> >> There are many ways in which this problem could be addressed; while it >> may not yet be clear what the best way forward could be, any approach to >> provide a richer set of transport services to applications will have to >> begin with the identification of the services that current transport >> protocols provide. >> >> The Working Group will: >> • identify services provided by existing IETF transport protocols and >> congestion control mechanisms, based on Standards-track and >> Experimental RFCs. The resulting document will provide guidance on >> making a choice among available mechanisms and protocols to obtain a >> certain transport service. >> • specify a set of transport services that end systems need to provide >> and provide guidance on choosing among available mechanisms and >> protocols to obtain a given transport service. >> • specify experimental mechanisms to discover the availability of >> protocols on an interface (both end system and path support), in order >> to provide a basis for incremental deployment. This will explain how to >> select and engage a protocol to deliver a transport service. >> >> The Working Group will coordinate closely with other Working Groups >> and/or IRTF Research Groups. >> >> The following topics are out of scope of this Working Group: >> • Quality-of-Service (QoS) and tunneling mechanisms and services >> • Definition of new encapsulations and tunneling mechanisms >> >> Deliverables: >> • Informational RFC summarizing the services provided by IETF transport >> protocols and congestion control mechanisms >> • Proposed Standard RFC specifying a set of transport services that end >> systems need to provide >> • Experimental RFC specifying how the defined transport services can be >> provided using IETF transports, including the definition of mechanisms >> to discover the availability of protocols on an interface (end system >> support and path support). >> >> Milestones: >> • M7: Submit summary of the services provided by IETF transport >> protocols and congestion control mechanisms to IESG as an Informational >> RFC. >> • M13: Submit end system transport services to IESG as a Proposed >> Standard. >> • M14: Submit specification of how the transport services can be >> provided to IESG as an Experimental RFC. >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >> > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Thu May 29 05:55:23 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07B71A08F0 for ; Thu, 29 May 2014 05:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 J9wXGDkjhlOX for ; Thu, 29 May 2014 05:55:18 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 290681A00AF for ; Thu, 29 May 2014 05:55:18 -0700 (PDT) Received: from [192.168.1.200] (p508F0AE5.dip0.t-ipconnect.de [80.143.10.229]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id BDE7E1C0E9801; Thu, 29 May 2014 14:55:10 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=windows-1252 From: Michael Tuexen X-Priority: 3 (Normal) In-Reply-To: Date: Thu, 29 May 2014 14:55:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1D68E0EB-7F18-45A0-9ECB-F39378309E94@fh-muenster.de> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <5387186C.501080 0@kau.se> <8AD9B5C2-8EE2-4444-B89D-D6C3268367AB@fh-muenster.de> To: Gorry Fairhurst X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/vXWoUrIJivNRa9_b4vccrzjuSRQ Cc: Anna Brunstrom , Michael Welzl , taps@ietf.org Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 12:55:20 -0000 On 29 May 2014, at 14:16, gorry@erg.abdn.ac.uk wrote: > I'd suspect we don't need to go adding wording about INFO specs. The > important thing the group needs to include the standards-track = methods. Standards track RFCs are as clear as Historic ones. However, = experimental are explicitly covered, that is why I wanted to bring up informational ones... I just want to make sure that the selection is on purpose... Best regards Michael >=20 > Gorry >=20 >> On 29 May 2014, at 13:56, Michael Welzl wrote: >>=20 >>> Hi, >>>=20 >>> Thank you all for your updates! Great work! About this, from Gorry >>> (that Anna agrees with): >>>=20 >>>> Would work for me too -- but I do think the work should be confined = to >>>> transport protocols in the IETF. >>>=20 >>> This is the original sentence that we're talking about: >>>=20 >>> *** >>> identify services provided by existing IETF transport protocols and >>> congestion control mechanisms, based on Standards-track and = Experimental >>> RFCs that were developed in the IETF's Transport Area. >>> *** >>>=20 >>> The proposal of Toby was to not limit the RFCs to the IETF's = *Transport >>> Area*. Changing this text to "in the IETF" makes it redundant, as = "IETF >>> transport protocols" is already there anyway. So I now changed it = to: >>>=20 >>> *** >>> identify services provided by existing IETF transport protocols and >>> congestion control mechanisms, based on Standards-track and = Experimental >>> RFCs. >>> *** >> Just to double check: We obviously want to exclude Historic RFCs. Is = the >> same >> true for Informational ones? >>=20 >> Best regards >> Michael >>>=20 >>> I changed this in the text and incorporated all the other suggested >>> changes, please check at >>> = https://sites.google.com/site/transportprotocolservices/charter-proposal >>> if I didn't make a mistake. >>>=20 >>> At least one person told me about problems reaching the page, so I'm >>> copying the whole text in at the end of this email too. >>>=20 >>> Cheers, >>> Michael >>>=20 >>> ****** >>>=20 >>> Transport Services (TAPS) >>>=20 >>> Status: Proposed Working Group >>> Last Updated: 2014-05-29 >>>=20 >>> Chair(s): >>> TBD >>>=20 >>> Transport Area Director(s): >>> Spencer Dawkins >>> Martin Stiemerling >>>=20 >>> Transport Area Advisor: >>> TBD >>>=20 >>> Mailing Lists: taps@ietf.org >>>=20 >>>=20 >>> Description of Working Group >>>=20 >>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite = and >>> the LEDBAT congestion control mechanism extend the number of = transport >>> services to applications in addition to the long-standing two = services >>> provided by TCP and UDP. For example, SCTP provides potentially = faster >>> reliable delivery for applications that can accept blocks of data = out of >>> order, and LEDBAT provides low-priority "scavenger" communication. = For >>> an application programmer, it is hard to use protocols other than = TCP or >>> UDP: not all protocols are available everywhere, hence a fall-back >>> solution to e.g. TCP or UDP must be implemented. Some protocols = provide >>> the same services in different ways. Layering decisions must be made >>> (e.g. should a protocol be used natively or over UDP?). Because of = these >>> complications, programmers often resort to either using TCP or >>> implementing their own customized solution over UDP, and chances of >>> benefiting from other transport protocols are lost. >>>=20 >>> There are many ways in which this problem could be addressed; while = it >>> may not yet be clear what the best way forward could be, any = approach to >>> provide a richer set of transport services to applications will have = to >>> begin with the identification of the services that current transport >>> protocols provide. >>>=20 >>> The Working Group will: >>> =95 identify services provided by existing IETF transport = protocols and >>> congestion control mechanisms, based on Standards-track and >>> Experimental RFCs. The resulting document will provide guidance on >>> making a choice among available mechanisms and protocols to obtain a >>> certain transport service. >>> =95 specify a set of transport services that end systems need to = provide >>> and provide guidance on choosing among available mechanisms and >>> protocols to obtain a given transport service. >>> =95 specify experimental mechanisms to discover the availability = of >>> protocols on an interface (both end system and path support), in = order >>> to provide a basis for incremental deployment. This will explain how = to >>> select and engage a protocol to deliver a transport service. >>>=20 >>> The Working Group will coordinate closely with other Working Groups >>> and/or IRTF Research Groups. >>>=20 >>> The following topics are out of scope of this Working Group: >>> =95 Quality-of-Service (QoS) and tunneling mechanisms and = services >>> =95 Definition of new encapsulations and tunneling mechanisms >>>=20 >>> Deliverables: >>> =95 Informational RFC summarizing the services provided by IETF = transport >>> protocols and congestion control mechanisms >>> =95 Proposed Standard RFC specifying a set of transport services = that end >>> systems need to provide >>> =95 Experimental RFC specifying how the defined transport = services can be >>> provided using IETF transports, including the definition of = mechanisms >>> to discover the availability of protocols on an interface (end = system >>> support and path support). >>>=20 >>> Milestones: >>> =95 M7: Submit summary of the services provided by IETF = transport >>> protocols and congestion control mechanisms to IESG as an = Informational >>> RFC. >>> =95 M13: Submit end system transport services to IESG as a = Proposed >>> Standard. >>> =95 M14: Submit specification of how the transport services can = be >>> provided to IESG as an Experimental RFC. >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>>=20 >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >>=20 >=20 >=20 From nobody Thu May 29 06:06:11 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9042B1A08FF for ; Thu, 29 May 2014 06:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrkeWvXFWrpx for ; Thu, 29 May 2014 06:05:58 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA7B1A0904 for ; Thu, 29 May 2014 06:05:47 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 13C962B4044; Thu, 29 May 2014 14:05:43 +0100 (BST) Received: from 139.133.204.42 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 29 May 2014 14:05:43 +0100 Message-ID: <91d6b1cb534c805ae128726fdc828c45.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <1D68E0EB-7F18-45A0-9ECB-F39378309E94@fh-muenster.de> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <5387186C.501080 0@kau.se> <8AD9B5C2-8EE2-4444-B89D-D6C3268367AB@fh-muenster.de> <1D68E0EB-7F18-45A0-9ECB-F39378309E94@fh-muenster.de> Date: Thu, 29 May 2014 14:05:43 +0100 From: gorry@erg.abdn.ac.uk To: "Michael Tuexen" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/taps/gnalLadWGTp9gXW0byfQ1-INGzA Cc: Gorry Fairhurst , Anna Brunstrom , Michael Welzl , taps@ietf.org Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:06:09 -0000 I'm not sure I understand the point - are there specific INFO RFCs that describe non-standards track RFCs that the group should consider? I think the group should prioritise IETF-reviewed specs and wouldn't particularly like to see too much focus on proprietary documented protocols (such things are typically published as AD-sponsored INFO documents in the RFC series). Gorry > On 29 May 2014, at 14:16, gorry@erg.abdn.ac.uk wrote: > >> I'd suspect we don't need to go adding wording about INFO specs. The >> important thing the group needs to include the standards-track methods. > Standards track RFCs are as clear as Historic ones. However, experimental > are explicitly covered, that is why I wanted to bring up informational > ones... I just want to make sure that the selection is on purpose... > > Best regards > Michael >> >> Gorry >> >>> On 29 May 2014, at 13:56, Michael Welzl wrote: >>> >>>> Hi, >>>> >>>> Thank you all for your updates! Great work! About this, from Gorry >>>> (that Anna agrees with): >>>> >>>>> Would work for me too -- but I do think the work should be confined >>>>> to >>>>> transport protocols in the IETF. >>>> >>>> This is the original sentence that we're talking about: >>>> >>>> *** >>>> identify services provided by existing IETF transport protocols and >>>> congestion control mechanisms, based on Standards-track and >>>> Experimental >>>> RFCs that were developed in the IETF's Transport Area. >>>> *** >>>> >>>> The proposal of Toby was to not limit the RFCs to the IETF's >>>> *Transport >>>> Area*. Changing this text to "in the IETF" makes it redundant, as >>>> "IETF >>>> transport protocols" is already there anyway. So I now changed it to: >>>> >>>> *** >>>> identify services provided by existing IETF transport protocols and >>>> congestion control mechanisms, based on Standards-track and >>>> Experimental >>>> RFCs. >>>> *** >>> Just to double check: We obviously want to exclude Historic RFCs. Is >>> the >>> same >>> true for Informational ones? >>> >>> Best regards >>> Michael >>>> >>>> I changed this in the text and incorporated all the other suggested >>>> changes, please check at >>>> https://sites.google.com/site/transportprotocolservices/charter-proposal >>>> if I didn't make a mistake. >>>> >>>> At least one person told me about problems reaching the page, so I'm >>>> copying the whole text in at the end of this email too. >>>> >>>> Cheers, >>>> Michael >>>> >>>> ****** >>>> >>>> Transport Services (TAPS) >>>> >>>> Status: Proposed Working Group >>>> Last Updated: 2014-05-29 >>>> >>>> Chair(s): >>>> TBD >>>> >>>> Transport Area Director(s): >>>> Spencer Dawkins >>>> Martin Stiemerling >>>> >>>> Transport Area Advisor: >>>> TBD >>>> >>>> Mailing Lists: taps@ietf.org >>>> >>>> >>>> Description of Working Group >>>> >>>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP, UDP-Lite >>>> and >>>> the LEDBAT congestion control mechanism extend the number of transport >>>> services to applications in addition to the long-standing two services >>>> provided by TCP and UDP. For example, SCTP provides potentially faster >>>> reliable delivery for applications that can accept blocks of data out >>>> of >>>> order, and LEDBAT provides low-priority "scavenger" communication. For >>>> an application programmer, it is hard to use protocols other than TCP >>>> or >>>> UDP: not all protocols are available everywhere, hence a fall-back >>>> solution to e.g. TCP or UDP must be implemented. Some protocols >>>> provide >>>> the same services in different ways. Layering decisions must be made >>>> (e.g. should a protocol be used natively or over UDP?). Because of >>>> these >>>> complications, programmers often resort to either using TCP or >>>> implementing their own customized solution over UDP, and chances of >>>> benefiting from other transport protocols are lost. >>>> >>>> There are many ways in which this problem could be addressed; while it >>>> may not yet be clear what the best way forward could be, any approach >>>> to >>>> provide a richer set of transport services to applications will have >>>> to >>>> begin with the identification of the services that current transport >>>> protocols provide. >>>> >>>> The Working Group will: >>>> • identify services provided by existing IETF transport protocols and >>>> congestion control mechanisms, based on Standards-track and >>>> Experimental RFCs. The resulting document will provide guidance on >>>> making a choice among available mechanisms and protocols to obtain a >>>> certain transport service. >>>> • specify a set of transport services that end systems need to >>>> provide >>>> and provide guidance on choosing among available mechanisms and >>>> protocols to obtain a given transport service. >>>> • specify experimental mechanisms to discover the availability of >>>> protocols on an interface (both end system and path support), in order >>>> to provide a basis for incremental deployment. This will explain how >>>> to >>>> select and engage a protocol to deliver a transport service. >>>> >>>> The Working Group will coordinate closely with other Working Groups >>>> and/or IRTF Research Groups. >>>> >>>> The following topics are out of scope of this Working Group: >>>> • Quality-of-Service (QoS) and tunneling mechanisms and services >>>> • Definition of new encapsulations and tunneling mechanisms >>>> >>>> Deliverables: >>>> • Informational RFC summarizing the services provided by IETF >>>> transport >>>> protocols and congestion control mechanisms >>>> • Proposed Standard RFC specifying a set of transport services that >>>> end >>>> systems need to provide >>>> • Experimental RFC specifying how the defined transport services can >>>> be >>>> provided using IETF transports, including the definition of mechanisms >>>> to discover the availability of protocols on an interface (end system >>>> support and path support). >>>> >>>> Milestones: >>>> • M7: Submit summary of the services provided by IETF transport >>>> protocols and congestion control mechanisms to IESG as an >>>> Informational >>>> RFC. >>>> • M13: Submit end system transport services to IESG as a Proposed >>>> Standard. >>>> • M14: Submit specification of how the transport services can be >>>> provided to IESG as an Experimental RFC. >>>> >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>> >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>> >> >> > From nobody Thu May 29 06:15: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 268041A08FD for ; Thu, 29 May 2014 06:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 5pDNAlWc3yD6 for ; Thu, 29 May 2014 06:15:28 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C5D01A08EB for ; Thu, 29 May 2014 06:15:28 -0700 (PDT) Received: from [192.168.1.200] (p508F0AE5.dip0.t-ipconnect.de [80.143.10.229]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 524561C103E45; Thu, 29 May 2014 15:15:22 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=windows-1252 From: Michael Tuexen X-Priority: 3 (Normal) In-Reply-To: <91d6b1cb534c805ae128726fdc828c45.squirrel@www.erg.abdn.ac.uk> Date: Thu, 29 May 2014 15:15:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2C1FAE6C-A5B3-4FAC-8544-B65E771164D9@fh-muenster.de> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <5387186C.501080 0@kau.se> <8AD9B5C2-8EE2-4444-B89D-D6C3268367AB@fh-muenster.de> <1D68E0EB-7F18-45A0-9ECB-F39378309E94@fh-muenster.de> <91d6b1cb534c805ae128726fd c828c45.squirrel@www.erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/9fVwjfGgOqS5DWT_Kz_q790KK94 Cc: Anna Brunstrom , Michael Welzl , taps@ietf.org Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:15:30 -0000 On 29 May 2014, at 15:05, gorry@erg.abdn.ac.uk wrote: > I'm not sure I understand the point - are there specific INFO RFCs = that > describe non-standards track RFCs that the group should consider? I'm not aware of any... But I haven't done the scan... I just saw that the scope was made wider: from RFCs coming from TSV area to all RFCs. So I just wanted to make sure the exclusion of Informational ones is still valid. That's all. >=20 > I think the group should prioritise IETF-reviewed specs and wouldn't > particularly like to see too much focus on proprietary documented > protocols (such things are typically published as AD-sponsored INFO > documents in the RFC series). That is fine... So it seems the selection is still on purpose. Best regards Michael >=20 > Gorry >=20 >> On 29 May 2014, at 14:16, gorry@erg.abdn.ac.uk wrote: >>=20 >>> I'd suspect we don't need to go adding wording about INFO specs. The >>> important thing the group needs to include the standards-track = methods. >> Standards track RFCs are as clear as Historic ones. However, = experimental >> are explicitly covered, that is why I wanted to bring up = informational >> ones... I just want to make sure that the selection is on purpose... >>=20 >> Best regards >> Michael >>>=20 >>> Gorry >>>=20 >>>> On 29 May 2014, at 13:56, Michael Welzl wrote: >>>>=20 >>>>> Hi, >>>>>=20 >>>>> Thank you all for your updates! Great work! About this, from = Gorry >>>>> (that Anna agrees with): >>>>>=20 >>>>>> Would work for me too -- but I do think the work should be = confined >>>>>> to >>>>>> transport protocols in the IETF. >>>>>=20 >>>>> This is the original sentence that we're talking about: >>>>>=20 >>>>> *** >>>>> identify services provided by existing IETF transport protocols = and >>>>> congestion control mechanisms, based on Standards-track and >>>>> Experimental >>>>> RFCs that were developed in the IETF's Transport Area. >>>>> *** >>>>>=20 >>>>> The proposal of Toby was to not limit the RFCs to the IETF's >>>>> *Transport >>>>> Area*. Changing this text to "in the IETF" makes it redundant, as >>>>> "IETF >>>>> transport protocols" is already there anyway. So I now changed it = to: >>>>>=20 >>>>> *** >>>>> identify services provided by existing IETF transport protocols = and >>>>> congestion control mechanisms, based on Standards-track and >>>>> Experimental >>>>> RFCs. >>>>> *** >>>> Just to double check: We obviously want to exclude Historic RFCs. = Is >>>> the >>>> same >>>> true for Informational ones? >>>>=20 >>>> Best regards >>>> Michael >>>>>=20 >>>>> I changed this in the text and incorporated all the other = suggested >>>>> changes, please check at >>>>> = https://sites.google.com/site/transportprotocolservices/charter-proposal >>>>> if I didn't make a mistake. >>>>>=20 >>>>> At least one person told me about problems reaching the page, so = I'm >>>>> copying the whole text in at the end of this email too. >>>>>=20 >>>>> Cheers, >>>>> Michael >>>>>=20 >>>>> ****** >>>>>=20 >>>>> Transport Services (TAPS) >>>>>=20 >>>>> Status: Proposed Working Group >>>>> Last Updated: 2014-05-29 >>>>>=20 >>>>> Chair(s): >>>>> TBD >>>>>=20 >>>>> Transport Area Director(s): >>>>> Spencer Dawkins >>>>> Martin Stiemerling >>>>>=20 >>>>> Transport Area Advisor: >>>>> TBD >>>>>=20 >>>>> Mailing Lists: taps@ietf.org >>>>>=20 >>>>>=20 >>>>> Description of Working Group >>>>>=20 >>>>> Conjointly, transport protocols such as SCTP, DCCP, MPTCP, = UDP-Lite >>>>> and >>>>> the LEDBAT congestion control mechanism extend the number of = transport >>>>> services to applications in addition to the long-standing two = services >>>>> provided by TCP and UDP. For example, SCTP provides potentially = faster >>>>> reliable delivery for applications that can accept blocks of data = out >>>>> of >>>>> order, and LEDBAT provides low-priority "scavenger" communication. = For >>>>> an application programmer, it is hard to use protocols other than = TCP >>>>> or >>>>> UDP: not all protocols are available everywhere, hence a fall-back >>>>> solution to e.g. TCP or UDP must be implemented. Some protocols >>>>> provide >>>>> the same services in different ways. Layering decisions must be = made >>>>> (e.g. should a protocol be used natively or over UDP?). Because of >>>>> these >>>>> complications, programmers often resort to either using TCP or >>>>> implementing their own customized solution over UDP, and chances = of >>>>> benefiting from other transport protocols are lost. >>>>>=20 >>>>> There are many ways in which this problem could be addressed; = while it >>>>> may not yet be clear what the best way forward could be, any = approach >>>>> to >>>>> provide a richer set of transport services to applications will = have >>>>> to >>>>> begin with the identification of the services that current = transport >>>>> protocols provide. >>>>>=20 >>>>> The Working Group will: >>>>> =95 identify services provided by existing IETF transport = protocols and >>>>> congestion control mechanisms, based on Standards-track and >>>>> Experimental RFCs. The resulting document will provide guidance on >>>>> making a choice among available mechanisms and protocols to obtain = a >>>>> certain transport service. >>>>> =95 specify a set of transport services that end systems need to >>>>> provide >>>>> and provide guidance on choosing among available mechanisms and >>>>> protocols to obtain a given transport service. >>>>> =95 specify experimental mechanisms to discover the availability = of >>>>> protocols on an interface (both end system and path support), in = order >>>>> to provide a basis for incremental deployment. This will explain = how >>>>> to >>>>> select and engage a protocol to deliver a transport service. >>>>>=20 >>>>> The Working Group will coordinate closely with other Working = Groups >>>>> and/or IRTF Research Groups. >>>>>=20 >>>>> The following topics are out of scope of this Working Group: >>>>> =95 Quality-of-Service (QoS) and tunneling mechanisms and = services >>>>> =95 Definition of new encapsulations and tunneling mechanisms >>>>>=20 >>>>> Deliverables: >>>>> =95 Informational RFC summarizing the services provided by IETF >>>>> transport >>>>> protocols and congestion control mechanisms >>>>> =95 Proposed Standard RFC specifying a set of transport services = that >>>>> end >>>>> systems need to provide >>>>> =95 Experimental RFC specifying how the defined transport = services can >>>>> be >>>>> provided using IETF transports, including the definition of = mechanisms >>>>> to discover the availability of protocols on an interface (end = system >>>>> support and path support). >>>>>=20 >>>>> Milestones: >>>>> =95 M7: Submit summary of the services provided by IETF = transport >>>>> protocols and congestion control mechanisms to IESG as an >>>>> Informational >>>>> RFC. >>>>> =95 M13: Submit end system transport services to IESG as a = Proposed >>>>> Standard. >>>>> =95 M14: Submit specification of how the transport services can = be >>>>> provided to IESG as an Experimental RFC. >>>>>=20 >>>>> _______________________________________________ >>>>> Taps mailing list >>>>> Taps@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/taps >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>>=20 >>>=20 >>>=20 >>=20 >=20 >=20 From nobody Thu May 29 06:31:40 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42B11A091E for ; Thu, 29 May 2014 06:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgPstzebIFBo for ; Thu, 29 May 2014 06:31:36 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B05DE1A0903 for ; Thu, 29 May 2014 06:31:34 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Wq0Qa-0006QK-IG; Thu, 29 May 2014 15:31:28 +0200 Received: from cisne-cn10.upc.es ([147.83.182.10] helo=[10.82.30.79]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Wq0Qa-00076X-2Y; Thu, 29 May 2014 15:31:28 +0200 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=windows-1252 From: Michael Welzl X-Priority: 3 (Normal) In-Reply-To: <2C1FAE6C-A5B3-4FAC-8544-B65E771164D9@fh-muenster.de> Date: Thu, 29 May 2014 15:31:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <5387186C.501080 0@kau.se> <8AD9B5C2-8EE2-4444-B89D-D6C3268367AB@fh-muenster.de> <1D68E0EB-7F18-45A0-9ECB-F39378309E94@fh-muenster.de> <91d6b1cb534c805ae128726fd c828c45.squirrel@www.erg.abdn.ac.uk> <2C1FAE6C-A5B3-4FAC-8544-B65E771164D9@fh-muenster.de> To: Michael Tuexen X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 6 sum msgs/h 1 total rcpts 16943 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 437B94E5638D6C974703AF6CE3BAFAAD087B0A7B X-UiO-SPAM-Test: remote_host: 147.83.182.10 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 24 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/JPctfDFfc4wgxy9g4gUEM6lNI3A Cc: "gorry@erg.abdn.ac.uk \(erg\)" , Anna Brunstrom , taps@ietf.org Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:31:39 -0000 On 29. mai 2014, at 15:15, Michael Tuexen wrote: > On 29 May 2014, at 15:05, gorry@erg.abdn.ac.uk wrote: >=20 >> I'm not sure I understand the point - are there specific INFO RFCs = that >> describe non-standards track RFCs that the group should consider? > I'm not aware of any... But I haven't done the scan... > I just saw that the scope was made wider: from RFCs coming from > TSV area to all RFCs. I don't think it's actually a (much?) wider scope: after all it's only = about "transport protocols and congestion control mechanisms". BTW given the previous discussion on multicast where I think we ended up = agreeing that we exclude it for now, shall we include the word "unicast" = in this sentence?? > So I just wanted to make sure the exclusion > of Informational ones is still valid. That's all. >>=20 >> I think the group should prioritise IETF-reviewed specs and wouldn't >> particularly like to see too much focus on proprietary documented >> protocols (such things are typically published as AD-sponsored INFO >> documents in the RFC series). > That is fine... So it seems the selection is still on purpose. I dug through the archives: https://sympa.uio.no/ifi.uio.no/arc/transport-services to see what caused this restraint on Experimental / Standards Track. We = had a discussion in September 2013 that led to it. This discussion = started with the proposal to limit not necessarily to RFCs but to things = that are out there and widely deployed. We then discussed how to define = "widely deployed" - and this culminated in deciding that we go with = standards track RFCs. Then, this was extended to include Experimental = RFCs too, because some of them are in fact widely deployed too. We never = discussed including Informational, and we should probably keep the = constraint. Cheers, Michael From nobody Thu May 29 06:41:26 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A70C1A0910 for ; Thu, 29 May 2014 06:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QR-0rV_IPuef for ; Thu, 29 May 2014 06:41:22 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 85DE41A0909 for ; Thu, 29 May 2014 06:41:22 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 48BD62B4044; Thu, 29 May 2014 14:41:17 +0100 (BST) Received: from 137.50.160.179 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Thu, 29 May 2014 14:41:17 +0100 Message-ID: In-Reply-To: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <5387186C.501080 0@kau.se> <8AD9B5C2-8EE2-4444-B89D-D6C3268367AB@fh-muenster.de> <1D68E0EB-7F18-45A0-9ECB-F39378309E94@fh-muenster.de> <91d6b1cb534c805ae128726fdc828c45.squirrel@www.erg.abdn.ac.uk> <2C1FAE6C-A5B3-4FAC-8544-B65E771164D9@fh-muenster.de> Date: Thu, 29 May 2014 14:41:17 +0100 From: gorry@erg.abdn.ac.uk To: "Michael Welzl" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/taps/nxl3xv2pj7WaqA-pChbOGrq6iiY Cc: "gorry@erg.abdn.ac.uk \(erg\)" , Michael Tuexen , Anna Brunstrom , taps@ietf.org Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 13:41:24 -0000 I'd personally avoid constraining the Charter to unicast (it's not essential to progress and in principle multicast could be included in future, say if enough expertise and a good use-case established) we could constrain the milestones to exclude multicast, but not sure we even need to explicitly state this. Gorry > > On 29. mai 2014, at 15:15, Michael Tuexen wrote: > >> On 29 May 2014, at 15:05, gorry@erg.abdn.ac.uk wrote: >> >>> I'm not sure I understand the point - are there specific INFO RFCs >>> that >>> describe non-standards track RFCs that the group should consider? >> I'm not aware of any... But I haven't done the scan... >> I just saw that the scope was made wider: from RFCs coming from >> TSV area to all RFCs. > > I don't think it's actually a (much?) wider scope: after all it's only > about "transport protocols and congestion control mechanisms". > > BTW given the previous discussion on multicast where I think we ended up > agreeing that we exclude it for now, shall we include the word "unicast" > in this sentence?? > > >> So I just wanted to make sure the exclusion >> of Informational ones is still valid. That's all. >>> >>> I think the group should prioritise IETF-reviewed specs and wouldn't >>> particularly like to see too much focus on proprietary documented >>> protocols (such things are typically published as AD-sponsored INFO >>> documents in the RFC series). >> That is fine... So it seems the selection is still on purpose. > > I dug through the archives: > https://sympa.uio.no/ifi.uio.no/arc/transport-services > to see what caused this restraint on Experimental / Standards Track. We > had a discussion in September 2013 that led to it. This discussion started > with the proposal to limit not necessarily to RFCs but to things that are > out there and widely deployed. We then discussed how to define "widely > deployed" - and this culminated in deciding that we go with standards > track RFCs. Then, this was extended to include Experimental RFCs too, > because some of them are in fact widely deployed too. We never discussed > including Informational, and we should probably keep the constraint. > > Cheers, > Michael > From nobody Thu May 29 07:23:29 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 946771A0983 for ; Thu, 29 May 2014 07:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 gERnrK-uIVCV for ; Thu, 29 May 2014 07:23:18 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522A41A0977 for ; Thu, 29 May 2014 07:23:18 -0700 (PDT) Received: from [192.168.1.200] (p508F0AE5.dip0.t-ipconnect.de [80.143.10.229]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 90CBC1C0E9801; Thu, 29 May 2014 16:23:12 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen X-Priority: 3 (Normal) In-Reply-To: Date: Thu, 29 May 2014 16:23:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <874867E1-E24D-4202-9A4C-86698674508E@fh-muenster.de> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <5387186C.501080 0@kau.se> <8AD9B5C2-8EE2-4444-B89D-D6C3268367AB@fh-muenster.de> <1D68E0EB-7F18-45A0-9ECB-F39378309E94@fh-muenster.de> <91d6b1cb534c805ae128726fd c828c45.squirrel@www.erg.abdn.ac.uk> <2C1FAE6C-A5B3-4FAC-8544-B65E771164D9@fh-muenster.de> To: Michael Welzl X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/ryXb7FMR6tmuIZgFNB5AGY8iq7c Cc: Gorry Fairhurst , Anna Brunstrom , taps@ietf.org Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:23:19 -0000 On 29 May 2014, at 15:31, Michael Welzl wrote: >=20 > On 29. mai 2014, at 15:15, Michael Tuexen = wrote: >=20 >> On 29 May 2014, at 15:05, gorry@erg.abdn.ac.uk wrote: >>=20 >>> I'm not sure I understand the point - are there specific INFO RFCs = that >>> describe non-standards track RFCs that the group should consider? >> I'm not aware of any... But I haven't done the scan... >> I just saw that the scope was made wider: from RFCs coming from >> TSV area to all RFCs. >=20 > I don't think it's actually a (much?) wider scope: after all it's only = about "transport protocols and congestion control mechanisms". Some people use transport protocol in other semantics as we do: http://tools.ietf.org/html/rfc3550 >=20 > BTW given the previous discussion on multicast where I think we ended = up agreeing that we exclude it for now, shall we include the word = "unicast" in this sentence?? >=20 >=20 >> So I just wanted to make sure the exclusion >> of Informational ones is still valid. That's all. >>>=20 >>> I think the group should prioritise IETF-reviewed specs and wouldn't >>> particularly like to see too much focus on proprietary documented >>> protocols (such things are typically published as AD-sponsored INFO >>> documents in the RFC series). >> That is fine... So it seems the selection is still on purpose. >=20 > I dug through the archives: > https://sympa.uio.no/ifi.uio.no/arc/transport-services > to see what caused this restraint on Experimental / Standards Track. = We had a discussion in September 2013 that led to it. This discussion = started with the proposal to limit not necessarily to RFCs but to things = that are out there and widely deployed. We then discussed how to define = "widely deployed" - and this culminated in deciding that we go with = standards track RFCs. Then, this was extended to include Experimental = RFCs too, because some of them are in fact widely deployed too. We never = discussed including Informational, and we should probably keep the = constraint. OK. See let's keep it that way. Best regards Michael >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps >=20 From nobody Thu May 29 07:26:25 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 75BEF1A0980 for ; Thu, 29 May 2014 07:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KFbiZhBYBM7 for ; Thu, 29 May 2014 07:26:13 -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 0868F1A098B for ; Thu, 29 May 2014 07:26:03 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Wq1HI-0001Fg-Re; Thu, 29 May 2014 16:25:56 +0200 Received: from cisne-cn10.upc.es ([147.83.182.10] helo=[10.82.30.79]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1Wq1HH-0003Qo-Ox; Thu, 29 May 2014 16:25:56 +0200 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_A5A2C38B-7312-4DF7-8123-DFBB4A341C37" From: Michael Welzl X-Priority: 3 (Normal) In-Reply-To: <874867E1-E24D-4202-9A4C-86698674508E@fh-muenster.de> Date: Thu, 29 May 2014 16:25:52 +0200 Message-Id: <18429EF6-30BA-46FE-BC85-F5AA0D90BF05@ifi.uio.no> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <5387186C.501080 0@kau.se> <8AD9B5C2-8EE2-4444-B89D-D6C3268367AB@fh-muenster.de> <1D68E0EB-7F18-45A0-9ECB-F39378309E94@fh-muenster.de> <91d6b1cb534c805ae128726fd c828c45.squirrel@www.erg.abdn.ac.uk> <2C1FAE6C-A5B3-4FAC-8544-B65E771164D9@fh-muenster.de> <874867E1-E24D-4202-9A4C-86698674508E@fh-muenster.de> To: Michael Tuexen X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 6 sum msgs/h 1 total rcpts 16947 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 54E5878131089EE4AECE880866D5F2475ADF035E X-UiO-SPAM-Test: remote_host: 147.83.182.10 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 25 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/FwIG1ApWmKNPgCYm37RdHsTToNQ Cc: "gorry@erg.abdn.ac.uk \(erg\)" , Anna Brunstrom , taps@ietf.org Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 14:26:19 -0000 --Apple-Mail=_A5A2C38B-7312-4DF7-8123-DFBB4A341C37 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 29. mai 2014, at 16:23, Michael Tuexen wrote: > On 29 May 2014, at 15:31, Michael Welzl wrote: >=20 >>=20 >> On 29. mai 2014, at 15:15, Michael Tuexen = wrote: >>=20 >>> On 29 May 2014, at 15:05, gorry@erg.abdn.ac.uk wrote: >>>=20 >>>> I'm not sure I understand the point - are there specific INFO RFCs = that >>>> describe non-standards track RFCs that the group should consider? >>> I'm not aware of any... But I haven't done the scan... >>> I just saw that the scope was made wider: from RFCs coming from >>> TSV area to all RFCs. >>=20 >> I don't think it's actually a (much?) wider scope: after all it's = only about "transport protocols and congestion control mechanisms". > Some people use transport protocol in other semantics as we do: > http://tools.ietf.org/html/rfc3550 Argh YES!!!! VERY good point! Can we please put the TSV area = constraint back in? It was there for a reason... Cheers, Michael --Apple-Mail=_A5A2C38B-7312-4DF7-8123-DFBB4A341C37 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 29. mai 2014, at 16:23, Michael = Tuexen <tuexen@fh-muenster.de> = wrote:

On 29 May 2014, at 15:31, Michael = Welzl <michawe@ifi.uio.no>= wrote:


On 29. mai 2014, at 15:15, = Michael Tuexen <tuexen@fh-muenster.de> = wrote:

On 29 May 2014, at 15:05, gorry@erg.abdn.ac.uk wrote:

I'm not sure I understand the point -  are there = specific INFO RFCs that
describe non-standards track RFCs that the = group should consider?
I'm not aware of any... But I = haven't done the scan...
I just saw that the scope was made wider: = from RFCs coming from
TSV area to all RFCs.

I = don't think it's actually a (much?) wider scope: after all it's only = about "transport protocols and congestion control = mechanisms".
Some people use transport protocol in other = semantics as we do:
http://tools.ietf.org/html/rfc= 3550

Argh YES!!!!   VERY = good point!  Can we please put the TSV area constraint back in? It = was there for a = reason...

Cheers,
Michael
= --Apple-Mail=_A5A2C38B-7312-4DF7-8123-DFBB4A341C37-- From nobody Thu May 29 08:15:29 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679191A6F57 for ; Thu, 29 May 2014 08:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QxjVwWlE2Q5l for ; Thu, 29 May 2014 08:15:23 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 898071A6F59 for ; Thu, 29 May 2014 08:15:22 -0700 (PDT) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Wq232-0007JJ-FA; Thu, 29 May 2014 17:15:16 +0200 Received: from cisne-cn10.upc.es ([147.83.182.10] helo=[10.82.30.79]) by mail-mx4.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Wq231-000726-TH; Thu, 29 May 2014 17:15:16 +0200 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=iso-8859-1 From: Michael Welzl X-Priority: 3 (Normal) In-Reply-To: Date: Thu, 29 May 2014 17:15:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <5387186C.501080 0@kau.se> <8AD9B5C2-8EE2-4444-B89D-D6C3268367AB@fh-muenster.de> <1D68E0EB-7F18-45A0-9ECB-F39378309E94@fh-muenster.de> <91d6b1cb534c805ae128726fdc828c45.squirrel@www.erg.abdn.ac.uk> <2C1FAE6C-A5B3-4FAC-8544-B65E771164D9@fh-muenster.de> To: "gorry@erg.abdn.ac.uk (erg)" X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 7 sum msgs/h 1 total rcpts 16951 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 3827EB97EE7B38A18FA751AE9CCE099A190E174C X-UiO-SPAM-Test: remote_host: 147.83.182.10 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 26 max/h 5 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/oBybvaeNcuCP4sluhlE-OpwA4K4 Cc: Michael Tuexen , Anna Brunstrom , taps@ietf.org Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 15:15:26 -0000 Fine by me to leave things as they are; it was just a thought. True, if = the expertise is there, we may not want to exclude it. On 29. mai 2014, at 15:41, gorry@erg.abdn.ac.uk wrote: > I'd personally avoid constraining the Charter to unicast (it's not > essential to progress and in principle multicast could be included in > future, say if enough expertise and a good use-case established) we = could > constrain the milestones to exclude multicast, but not sure we even = need > to explicitly state this. >=20 > Gorry >=20 >>=20 >> On 29. mai 2014, at 15:15, Michael Tuexen = wrote: >>=20 >>> On 29 May 2014, at 15:05, gorry@erg.abdn.ac.uk wrote: >>>=20 >>>> I'm not sure I understand the point - are there specific INFO RFCs >>>> that >>>> describe non-standards track RFCs that the group should consider? >>> I'm not aware of any... But I haven't done the scan... >>> I just saw that the scope was made wider: from RFCs coming from >>> TSV area to all RFCs. >>=20 >> I don't think it's actually a (much?) wider scope: after all it's = only >> about "transport protocols and congestion control mechanisms". >>=20 >> BTW given the previous discussion on multicast where I think we ended = up >> agreeing that we exclude it for now, shall we include the word = "unicast" >> in this sentence?? >>=20 >>=20 >>> So I just wanted to make sure the exclusion >>> of Informational ones is still valid. That's all. >>>>=20 >>>> I think the group should prioritise IETF-reviewed specs and = wouldn't >>>> particularly like to see too much focus on proprietary documented >>>> protocols (such things are typically published as AD-sponsored INFO >>>> documents in the RFC series). >>> That is fine... So it seems the selection is still on purpose. >>=20 >> I dug through the archives: >> https://sympa.uio.no/ifi.uio.no/arc/transport-services >> to see what caused this restraint on Experimental / Standards Track. = We >> had a discussion in September 2013 that led to it. This discussion = started >> with the proposal to limit not necessarily to RFCs but to things that = are >> out there and widely deployed. We then discussed how to define = "widely >> deployed" - and this culminated in deciding that we go with standards >> track RFCs. Then, this was extended to include Experimental RFCs too, >> because some of them are in fact widely deployed too. We never = discussed >> including Informational, and we should probably keep the constraint. >>=20 >> Cheers, >> Michael >>=20 >=20 From nobody Thu May 29 09:16:43 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 CEC481A6FC3 for ; Thu, 29 May 2014 09:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEz7ipsy5-aD for ; Thu, 29 May 2014 09:16:40 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0B21A6FBF for ; Thu, 29 May 2014 09:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=588; q=dns/txt; s=iport; t=1401380167; x=1402589767; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KDSLH4oEZsx1H/USIzxuy0znGArgkl4tw7ZytCjUMXs=; b=HEGKoOGQgkLcp5r80I5tlvCkWP85E0yVoalvTU1mt7xlrj4WJmi0h7jE dS08VmDqBKqOEikG0eB/tPJY87NgGtLdAMci5U06rC7PRsmGmtqe3NJnp +J65jpiWVdMvdYBW6eghC6pdYF/Ck9vllZu/Kx5Tj1G/fy1TZ6WyFOM8R M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuoHABNdh1OtJA2J/2dsb2JhbABZgweBKoJrpycBAQEBAQEFAZgYARlzFnSCJgEBBCMRRRACAQgODAImAgICMBUQAgQBDQWIQrIwpSAXgSqEK4hKMweCdYFLAQOZdZMpgziCLw X-IronPort-AV: E=Sophos;i="4.98,934,1392163200"; d="scan'208";a="328894292" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-5.cisco.com with ESMTP; 29 May 2014 16:15:47 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s4TGFltT026249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 May 2014 16:15:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Thu, 29 May 2014 11:15:46 -0500 From: "Joe Hildebrand (jhildebr)" To: Michael Welzl , Michael Tuexen Thread-Topic: [Taps] IETF journal article update - CHARTER Thread-Index: AQHPeyBuY8+dT8k2N0mb8+jRLcB485tXsHwAgAAEaYCAAAFfgIAAArWAgAAFGgCAAAmPgIAAA6SAgAAB6YCAAArRAIAAAvWAgAACsYCAAAR+gIAADnSAgAAAwgD//7ojgA== Date: Thu, 29 May 2014 16:15:45 +0000 Message-ID: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <8AD9B5C2-8EE2-4444-B89D-D6C3268367AB@fh-muenster.de> <1D68E0EB-7F18-45A0-9ECB-F39378309E94@fh-muenster.de> <2C1FAE6C-A5B3-4FAC-8544-B65E771164D9@fh-muenster.de> <874867E1-E24D-4202-9A4C-86698674508E@fh-muenster.de> <18429EF6-30BA-46FE-BC85-F5AA0D90BF05@ifi.uio.no> In-Reply-To: <18429EF6-30BA-46FE-BC85-F5AA0D90BF05@ifi.uio.no> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: <0D862AA1EF094048AA89644E123FC4D9@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/fJCsL1zY0RJS18oNA2N4N_uMSC8 Cc: "gorry@erg.abdn.ac.uk \(erg\)" , Anna Brunstrom , "taps@ietf.org" Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 16:16:42 -0000 T24gNS8yOS8xNCwgODoyNSBBTSwgIk1pY2hhZWwgV2VsemwiIDxtaWNoYXdlQGlmaS51aW8ubm8+ IHdyb3RlOg0KDQo+QXJnaCBZRVMhISEhICAgVkVSWSBnb29kIHBvaW50ISAgQ2FuIHdlIHBsZWFz ZSBwdXQgdGhlIFRTViBhcmVhDQo+Y29uc3RyYWludCBiYWNrIGluPyBJdCB3YXMgdGhlcmUgZm9y IGEgcmVhc29uLi4uDQoNCkknZCBzZWUgdGhhdCBhcyBhbiB1bm5lY2Vzc2FyeSBwYXJvY2hpYWxp c20uICBSVFAgaGFzIGlkZWFzLiAgRFRMUyBoYXMNCmlkZWFzLiAgQkVFUCBoYXMgaWRlYXMuICBX aHkgZG8geW91IGNhcmUgdGhhdCB0aGV5IGRpZG4ndCBjb21lIGZyb20gVFNWPw0KV2h5IHNob3Vs ZCB3ZSBjYXJlIGlmIHRoZXkncmUgYWN0dWFsbHkgKnJlYWwqIGxheWVyIDQgcHJvdG9jb2xzPw0K DQotLSANCkpvZSBIaWxkZWJyYW5kDQoNCg0KDQo= From nobody Thu May 29 09:19:25 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 06E761A09E6 for ; Thu, 29 May 2014 09:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StblgBxGnnxw for ; Thu, 29 May 2014 09:19:14 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 817B41A6FD9 for ; Thu, 29 May 2014 09:19:00 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ravage.cl.cam.ac.uk ([128.232.1.17]:64765) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1Wq32c-0001Ru-YB (Exim 4.82_3-c0e5623) (return-path ); Thu, 29 May 2014 17:18:54 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Toby Moncaster In-Reply-To: Date: Thu, 29 May 2014 17:18:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <01166D12-AF60-477B-851D-7957154484F2@cl.cam.ac.uk> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <8AD9B5C2-8EE2-4444-B89D-D6C3268367AB@fh-muenster.de> <1D68E0EB-7F18-45A0-9ECB-F39378309E94@fh-muenster.de> <2C1FAE6C-A5B3-4FAC-8544-B65E771164D9@fh-muenster.de> <874867E1-E24D-4202-9A4C-86698674508E@fh-muenster.de> <18429EF6-30BA-46FE-BC85-F5AA0D90BF05@ifi.uio.no> To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1878.2) Sender: "T. Moncaster" Archived-At: http://mailarchive.ietf.org/arch/msg/taps/seZjBggttITZ0DA7fSDP2zQt4ws Cc: "gorry@erg.abdn.ac.uk \(erg\)" , Michael Tuexen , Anna Brunstrom , Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 16:19:17 -0000 I agree that unnecessarily limiting this in the charter seems wrong = which is why I suggested the wording change.=20 On 29 May 2014, at 17:15, Joe Hildebrand (jhildebr) = wrote: > On 5/29/14, 8:25 AM, "Michael Welzl" wrote: >=20 >> Argh YES!!!! VERY good point! Can we please put the TSV area >> constraint back in? It was there for a reason... >=20 > I'd see that as an unnecessary parochialism. RTP has ideas. DTLS has > ideas. BEEP has ideas. Why do you care that they didn't come from = TSV? > Why should we care if they're actually *real* layer 4 protocols? >=20 > --=20 > Joe Hildebrand >=20 >=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Thu May 29 09:31:23 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECF3E1A6FFE for ; Thu, 29 May 2014 09:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slIWiBN2Q5_b for ; Thu, 29 May 2014 09:31:06 -0700 (PDT) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7574D1A6FD3 for ; Thu, 29 May 2014 09:30:59 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1Wq3E9-0006lm-99; Thu, 29 May 2014 18:30:49 +0200 Received: from cisne-cn09.upc.es ([147.83.182.9] helo=72.xarxa-10-83-59.eduroam.upc.edu) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1Wq3E8-0006ae-IW; Thu, 29 May 2014 18:30:49 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <01166D12-AF60-477B-851D-7957154484F2@cl.cam.ac.uk> Date: Thu, 29 May 2014 18:30:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1625A5CF-1FDB-4230-B6E4-B23E47CF2D04@ifi.uio.no> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <8AD9B5C2-8EE2-4444-B89D-D6C3268367AB@fh-muenster.de> <1D68E0EB-7F18-45A0-9ECB-F39378309E94@fh-muenster.de> <2C1FAE6C-A5B3-4FAC-8544-B65E771164D9@fh-muenster.de> <874867E1-E24D-4202-9A4C-86698674508E@fh-muenster.de> <18429EF6-30BA-46FE-BC85-F5AA0D90BF05@ifi.uio.no> <01166D12-AF60-477B-851D-7957154484F2@cl.cam.ac.uk> To: Toby Moncaster X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 8 msgs/h 2 sum rcpts/h 11 sum msgs/h 2 total rcpts 16959 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 9967BFA903C55FA0E690753508059BCDD33F0C26 X-UiO-SPAM-Test: remote_host: 147.83.182.9 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 16 max/h 6 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/2rOv5gQuF4emYfwKtUHJeBZelqo Cc: "gorry@erg.abdn.ac.uk \(erg\)" , Michael Tuexen , Anna Brunstrom , "Joe Hildebrand \(jhildebr\)" , "taps@ietf.org" Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 16:31:12 -0000 Well, my concern is about document length. The usefulness of a 200-pager = is limited because somehow this complexity is the problem that we want = to address here... but yes, perhaps one needs to have the full beast = laid out first, no matter how long it gets. The usefulness is also = limited if we make it short but exclude these things, and then have = folks coming and saying "but RTP offers this". So, I agree. But the fun factor of this work has just been reduced :-) On 29. mai 2014, at 18:18, Toby Moncaster = wrote: > I agree that unnecessarily limiting this in the charter seems wrong = which is why I suggested the wording change.=20 >=20 > On 29 May 2014, at 17:15, Joe Hildebrand (jhildebr) = wrote: >=20 >> On 5/29/14, 8:25 AM, "Michael Welzl" wrote: >>=20 >>> Argh YES!!!! VERY good point! Can we please put the TSV area >>> constraint back in? It was there for a reason... >>=20 >> I'd see that as an unnecessary parochialism. RTP has ideas. DTLS = has >> ideas. BEEP has ideas. Why do you care that they didn't come from = TSV? >> Why should we care if they're actually *real* layer 4 protocols? >>=20 >> --=20 >> Joe Hildebrand >>=20 >>=20 >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 From nobody Thu May 29 09:34:50 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 1A4F31A6FB9 for ; Thu, 29 May 2014 09:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvpH7SVhYkAI for ; Thu, 29 May 2014 09:34:47 -0700 (PDT) Received: from ppsw-51.csi.cam.ac.uk (ppsw-51-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02721A0177 for ; Thu, 29 May 2014 09:34:47 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from ravage.cl.cam.ac.uk ([128.232.1.17]:64907) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1Wq3Hu-0003c2-YO (Exim 4.82_3-c0e5623) (return-path ); Thu, 29 May 2014 17:34:42 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Toby Moncaster In-Reply-To: <1625A5CF-1FDB-4230-B6E4-B23E47CF2D04@ifi.uio.no> Date: Thu, 29 May 2014 17:34:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4525C17C-ED1B-42E6-A3D1-018A10FD514A@cl.cam.ac.uk> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <8AD9B5C2-8EE2-4444-B89D-D6C3268367AB@fh-muenster.de> <1D68E0EB-7F18-45A0-9ECB-F39378309E94@fh-muenster.de> <2C1FAE6C-A5B3-4FAC-8544-B65E771164D9@fh-muenster.de> <874867E1-E24D-4202-9A4C-86698674508E@fh-muenster.de> <18429EF6-30BA-46FE-BC85-F5AA0D90BF05@ifi.uio.no> <01166D12-AF60-477B-851D-7957154484F2@cl.cam.ac.uk> <1625A5CF-1FDB-4230-B6E4-B23E47CF2D04@ifi.uio.no> To: Michael Welzl X-Mailer: Apple Mail (2.1878.2) Sender: "T. Moncaster" Archived-At: http://mailarchive.ietf.org/arch/msg/taps/cfWidebf2PSBeFGU0AQRtN2oo4U Cc: "gorry@erg.abdn.ac.uk \(erg\)" , Michael Tuexen , Anna Brunstrom , "Joe Hildebrand \(jhildebr\)" , "taps@ietf.org" Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 16:34:49 -0000 My idea was to not exclude these during charter, but to choose to = exclude them or not when it comes to actually producing the document.=20 Toby On 29 May 2014, at 17:30, Michael Welzl wrote: > Well, my concern is about document length. The usefulness of a = 200-pager is limited because somehow this complexity is the problem that = we want to address here... but yes, perhaps one needs to have the full = beast laid out first, no matter how long it gets. The usefulness is also = limited if we make it short but exclude these things, and then have = folks coming and saying "but RTP offers this". >=20 > So, I agree. But the fun factor of this work has just been reduced = :-) >=20 >=20 > On 29. mai 2014, at 18:18, Toby Moncaster = wrote: >=20 >> I agree that unnecessarily limiting this in the charter seems wrong = which is why I suggested the wording change.=20 >>=20 >> On 29 May 2014, at 17:15, Joe Hildebrand (jhildebr) = wrote: >>=20 >>> On 5/29/14, 8:25 AM, "Michael Welzl" wrote: >>>=20 >>>> Argh YES!!!! VERY good point! Can we please put the TSV area >>>> constraint back in? It was there for a reason... >>>=20 >>> I'd see that as an unnecessary parochialism. RTP has ideas. DTLS = has >>> ideas. BEEP has ideas. Why do you care that they didn't come from = TSV? >>> Why should we care if they're actually *real* layer 4 protocols? >>>=20 >>> --=20 >>> Joe Hildebrand >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >=20 From nobody Thu May 29 09:36:50 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 067EC1A09CC for ; Thu, 29 May 2014 09:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSct59avfQkN for ; Thu, 29 May 2014 09:36:41 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E43D1A0177 for ; Thu, 29 May 2014 09:36:41 -0700 (PDT) Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1Wq3Jg-00089L-Vo; Thu, 29 May 2014 18:36:32 +0200 Received: from cisne-cn09.upc.es ([147.83.182.9] helo=72.xarxa-10-83-59.eduroam.upc.edu) by mail-mx1.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1Wq3Jg-0000Bt-BK; Thu, 29 May 2014 18:36:32 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <4525C17C-ED1B-42E6-A3D1-018A10FD514A@cl.cam.ac.uk> Date: Thu, 29 May 2014 18:36:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <8AD9B5C2-8EE2-4444-B89D-D6C3268367AB@fh-muenster.de> <1D68E0EB-7F18-45A0-9ECB-F39378309E94@fh-muenster.de> <2C1FAE6C-A5B3-4FAC-8544-B65E771164D9@fh-muenster.de> <874867E1-E24D-4202-9A4C-86698674508E@fh-muenster.de> <18429EF6-30BA-46FE-BC85-F5AA0D90BF05@ifi.uio.no> <01166D12-AF60-477B-851D-7957154484F2@cl.cam.ac.uk> <1625A5CF-1FDB-4230-B6E4-B23E47CF2D04@ifi.uio.no> <4525C17C-ED1B-42E6-A3D1-018A10FD514A@cl.cam.ac.uk> To: Toby Moncaster X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 14 msgs/h 3 sum rcpts/h 17 sum msgs/h 3 total rcpts 16965 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 0F4B45FE723C63DC4B6FEA00FE01B34B800C4152 X-UiO-SPAM-Test: remote_host: 147.83.182.9 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 17 max/h 6 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/nrlRZi7OfTg5AsdOF9OewdeM9Aw Cc: "gorry@erg.abdn.ac.uk \(erg\)" , Michael Tuexen , Anna Brunstrom , "Joe Hildebrand \(jhildebr\)" , "taps@ietf.org" Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 16:36:46 -0000 Fine by me! On 29. mai 2014, at 18:34, Toby Moncaster = wrote: > My idea was to not exclude these during charter, but to choose to = exclude them or not when it comes to actually producing the document.=20 >=20 > Toby >=20 > On 29 May 2014, at 17:30, Michael Welzl wrote: >=20 >> Well, my concern is about document length. The usefulness of a = 200-pager is limited because somehow this complexity is the problem that = we want to address here... but yes, perhaps one needs to have the full = beast laid out first, no matter how long it gets. The usefulness is also = limited if we make it short but exclude these things, and then have = folks coming and saying "but RTP offers this". >>=20 >> So, I agree. But the fun factor of this work has just been reduced = :-) >>=20 >>=20 >> On 29. mai 2014, at 18:18, Toby Moncaster = wrote: >>=20 >>> I agree that unnecessarily limiting this in the charter seems wrong = which is why I suggested the wording change.=20 >>>=20 >>> On 29 May 2014, at 17:15, Joe Hildebrand (jhildebr) = wrote: >>>=20 >>>> On 5/29/14, 8:25 AM, "Michael Welzl" wrote: >>>>=20 >>>>> Argh YES!!!! VERY good point! Can we please put the TSV area >>>>> constraint back in? It was there for a reason... >>>>=20 >>>> I'd see that as an unnecessary parochialism. RTP has ideas. DTLS = has >>>> ideas. BEEP has ideas. Why do you care that they didn't come from = TSV? >>>> Why should we care if they're actually *real* layer 4 protocols? >>>>=20 >>>> --=20 >>>> Joe Hildebrand >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>=20 >>=20 >=20 From nobody Thu May 29 09:49:26 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE5A1A0464 for ; Thu, 29 May 2014 09:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ps9zKHLux-Y for ; Thu, 29 May 2014 09:49:21 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57F6A1A0463 for ; Thu, 29 May 2014 09:49:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2752; q=dns/txt; s=iport; t=1401382157; x=1402591757; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=x99VATdABx6uWLwIN/Bcveef9vT0OabbsH1QfxiVKsM=; b=Dw3yBVMdb1U9oy1Uf1JUuX66nv5YG6ol3N4LBP1wLfRvfe0hp2zUmSvq mp+IUsf9mAIBmOtRRqZ1rSxw3KdGFGZeqE21AEFqJKnqP9Z7XFYwjOJNX AEM8gzg37u/kHQRnvuaQS76SVzPBfZX9qeOzis6/TDEwYNV6DTH+mtuAB U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4HAKVjh1OtJV2Q/2dsb2JhbABZDoJ5UliCa6cnAQEBAQEBBQGQX4c5ARlzFnSCJQEBAQQBAQEgEToLEAIBCBgCAiYCAgIlCxUQAgQBDQWIQg2yKKUgEwSBKoQriCVYB4J1gUsEmXWTKYJ4QGyBAUI X-IronPort-AV: E=Sophos;i="4.98,935,1392163200"; d="scan'208";a="328867764" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-2.cisco.com with ESMTP; 29 May 2014 16:49:17 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s4TGnGKp000693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 May 2014 16:49:16 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Thu, 29 May 2014 11:49:16 -0500 From: "Joe Hildebrand (jhildebr)" To: Toby Moncaster , Michael Welzl Thread-Topic: [Taps] IETF journal article update - CHARTER Thread-Index: AQHPeyBuY8+dT8k2N0mb8+jRLcB485tXsHwAgAAEaYCAAAFfgIAAArWAgAAFGgCAAAmPgIAAA6SAgAAB6YCAAArRAIAAAvWAgAACsYCAAAR+gIAADnSAgAAAwgD//7ojgIAAFPoxgABU4YD//5+BgA== Date: Thu, 29 May 2014 16:49:15 +0000 Message-ID: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <8AD9B5C2-8EE2-4444-B89D-D6C3268367AB@fh-muenster.de> <1D68E0EB-7F18-45A0-9ECB-F39378309E94@fh-muenster.de> <2C1FAE6C-A5B3-4FAC-8544-B65E771164D9@fh-muenster.de> <874867E1-E24D-4202-9A4C-86698674508E@fh-muenster.de> <18429EF6-30BA-46FE-BC85-F5AA0D90BF05@ifi.uio.no> <01166D12-AF60-477B-851D-7957154484F2@cl.cam.ac.uk> <1625A5CF-1FDB-4230-B6E4-B23E47CF2D04@ifi.uio.no> <4525C17C-ED1B-42E6-A3D1-018A10FD514A@cl.cam.ac.uk> In-Reply-To: <4525C17C-ED1B-42E6-A3D1-018A10FD514A@cl.cam.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/f42W3GcNyqqg2e_6EhpBR4TkLFw Cc: "gorry@erg.abdn.ac.uk \(erg\)" , Michael Tuexen , Anna Brunstrom , "taps@ietf.org" Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 16:49:23 -0000 KzEuICBIb3dldmVyLCBpZiB5b3UgY2hvb3NlIHRvIGV4Y2x1ZGUgZ29vZCBpZGVhcywgSSBpbWFn aW5lIHRoYXQgd2lsbA0KY29tZSB1cCBkdXJpbmcgbGFzdCBjYWxsLCBzbyBJIHJlY29tbWVuZCBn b2luZyBpbnRvIHRoZSBwcm9qZWN0IHdpdGggdGhlDQppZGVhIHRoYXQgaXQncyBub3QgZ29pbmcg dG8gYmUgZnVuLg0KDQoNCk9uIDUvMjkvMTQsIDEwOjM0IEFNLCAiVG9ieSBNb25jYXN0ZXIiIDx0 b2J5Lm1vbmNhc3RlckBjbC5jYW0uYWMudWs+IHdyb3RlOg0KDQo+TXkgaWRlYSB3YXMgdG8gbm90 IGV4Y2x1ZGUgdGhlc2UgZHVyaW5nIGNoYXJ0ZXIsIGJ1dCB0byBjaG9vc2UgdG8gZXhjbHVkZQ0K PnRoZW0gb3Igbm90IHdoZW4gaXQgY29tZXMgdG8gYWN0dWFsbHkgcHJvZHVjaW5nIHRoZSBkb2N1 bWVudC4NCj4NCj5Ub2J5DQo+DQo+T24gMjkgTWF5IDIwMTQsIGF0IDE3OjMwLCBNaWNoYWVsIFdl bHpsIDxtaWNoYXdlQGlmaS51aW8ubm8+IHdyb3RlOg0KPg0KPj4gV2VsbCwgbXkgY29uY2VybiBp cyBhYm91dCBkb2N1bWVudCBsZW5ndGguIFRoZSB1c2VmdWxuZXNzIG9mIGENCj4+MjAwLXBhZ2Vy IGlzIGxpbWl0ZWQgYmVjYXVzZSBzb21laG93IHRoaXMgY29tcGxleGl0eSBpcyB0aGUgcHJvYmxl bSB0aGF0DQo+PndlIHdhbnQgdG8gYWRkcmVzcyBoZXJlLi4uICBidXQgeWVzLCBwZXJoYXBzIG9u ZSBuZWVkcyB0byBoYXZlIHRoZSBmdWxsDQo+PmJlYXN0IGxhaWQgb3V0IGZpcnN0LCBubyBtYXR0 ZXIgaG93IGxvbmcgaXQgZ2V0cy4gVGhlIHVzZWZ1bG5lc3MgaXMgYWxzbw0KPj5saW1pdGVkIGlm IHdlIG1ha2UgaXQgc2hvcnQgYnV0IGV4Y2x1ZGUgdGhlc2UgdGhpbmdzLCBhbmQgdGhlbiBoYXZl DQo+PmZvbGtzIGNvbWluZyBhbmQgc2F5aW5nICJidXQgUlRQIG9mZmVycyB0aGlzIi4NCj4+IA0K Pj4gU28sIEkgYWdyZWUuIEJ1dCB0aGUgZnVuIGZhY3RvciBvZiB0aGlzIHdvcmsgaGFzIGp1c3Qg YmVlbiByZWR1Y2VkICA6LSkNCj4+IA0KPj4gDQo+PiBPbiAyOS4gbWFpIDIwMTQsIGF0IDE4OjE4 LCBUb2J5IE1vbmNhc3RlciA8dG9ieS5tb25jYXN0ZXJAY2wuY2FtLmFjLnVrPg0KPj53cm90ZToN Cj4+IA0KPj4+IEkgYWdyZWUgdGhhdCB1bm5lY2Vzc2FyaWx5IGxpbWl0aW5nIHRoaXMgaW4gdGhl IGNoYXJ0ZXIgc2VlbXMgd3JvbmcNCj4+PndoaWNoIGlzIHdoeSBJIHN1Z2dlc3RlZCB0aGUgd29y ZGluZyBjaGFuZ2UuDQo+Pj4gDQo+Pj4gT24gMjkgTWF5IDIwMTQsIGF0IDE3OjE1LCBKb2UgSGls ZGVicmFuZCAoamhpbGRlYnIpDQo+Pj48amhpbGRlYnJAY2lzY28uY29tPiB3cm90ZToNCj4+PiAN Cj4+Pj4gT24gNS8yOS8xNCwgODoyNSBBTSwgIk1pY2hhZWwgV2VsemwiIDxtaWNoYXdlQGlmaS51 aW8ubm8+IHdyb3RlOg0KPj4+PiANCj4+Pj4+IEFyZ2ggWUVTISEhISAgIFZFUlkgZ29vZCBwb2lu dCEgIENhbiB3ZSBwbGVhc2UgcHV0IHRoZSBUU1YgYXJlYQ0KPj4+Pj4gY29uc3RyYWludCBiYWNr IGluPyBJdCB3YXMgdGhlcmUgZm9yIGEgcmVhc29uLi4uDQo+Pj4+IA0KPj4+PiBJJ2Qgc2VlIHRo YXQgYXMgYW4gdW5uZWNlc3NhcnkgcGFyb2NoaWFsaXNtLiAgUlRQIGhhcyBpZGVhcy4gIERUTFMg aGFzDQo+Pj4+IGlkZWFzLiAgQkVFUCBoYXMgaWRlYXMuICBXaHkgZG8geW91IGNhcmUgdGhhdCB0 aGV5IGRpZG4ndCBjb21lIGZyb20NCj4+Pj5UU1Y/DQo+Pj4+IFdoeSBzaG91bGQgd2UgY2FyZSBp ZiB0aGV5J3JlIGFjdHVhbGx5ICpyZWFsKiBsYXllciA0IHByb3RvY29scz8NCj4+Pj4gDQo+Pj4+ IC0tIA0KPj4+PiBKb2UgSGlsZGVicmFuZA0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBUYXBzIG1h aWxpbmcgbGlzdA0KPj4+PiBUYXBzQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdGFwcw0KPj4+IA0KPj4gDQo+DQo+DQoNCg0KLS0gDQpKb2UgSGls ZGVicmFuZA0KDQoNCg0K From nobody Thu May 29 11:27:06 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7131A0A04 for ; Thu, 29 May 2014 11:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUporL1Mt3ny for ; Thu, 29 May 2014 11:27:01 -0700 (PDT) Received: from mail-yh0-f71.google.com (mail-yh0-f71.google.com [209.85.213.71]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6430D1A0958 for ; Thu, 29 May 2014 11:27:01 -0700 (PDT) Received: by mail-yh0-f71.google.com with SMTP id 29so3347201yhl.10 for ; Thu, 29 May 2014 11:26:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=HFxBvqpzorPzDp2OjUabt7vwnoT87G/2qaZ7xCE6xk4=; b=lVseWRtWLJn6x4mVfbqR7nnMRp2r3RvvhkIxY/DGIGFELQ8kP1X07tYs9J+2mKqF+D Z5taVoVCSV4ag7+eVRzzCZ7pNtN6O/RegyZQJ9GZ8333RC/VeoNin1e81G3jPBZNxhkO +9ed8j6vEHuRQy29liha4CbpQ4U3MInzB6Vxr/JwY/MIKXvEYuU0Qy6sJAAYiMF3Zsfs GnskdxlAF+kVakP5FZIdyBmg/xhYkB2wLHTxRbUPphT0I3ZCowKxIBG/2Xt8m5HaY+S9 sujnA5aGIm5xJ3uJt1RQbbRZeXfSa2tjWpo2lYv5IjecRZHbAXIYWfOZV1KM9qN+8dfg 05gQ== X-Gm-Message-State: ALoCoQn4jSqscEmCc25SFSwPCYL+c3W3kQ3AgjGlN0YU/1OWP78T5slfUTJ8EjGBEPdCB2NEK/LK X-Received: by 10.58.39.98 with SMTP id o2mr2663697vek.75.1401388017040; Thu, 29 May 2014 11:26:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.84.35 with HTTP; Thu, 29 May 2014 11:26:36 -0700 (PDT) In-Reply-To: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <5387186C.5010800@kau.se> From: Aaron Falk Date: Thu, 29 May 2014 14:26:36 -0400 Message-ID: To: Michael Welzl Content-Type: multipart/alternative; boundary=089e01176febf2d55a04fa8e122b Archived-At: http://mailarchive.ietf.org/arch/msg/taps/xlKsHN0JFfQ-IO-9AMLi5Zacjq0 Cc: Anna Brunstrom , taps@ietf.org Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 18:27:03 -0000 --089e01176febf2d55a04fa8e122b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, May 29, 2014 at 7:56 AM, Michael Welzl wrote: > > The Working Group will: > ... =E2=80=A2 specify a set of transport services that end systems need = to > provide and provide guidance on choosing among available mechanisms and > protocols to obtain a given transport service. > "that end systems need to provide" sounds like this group is adding a MUST to transport protocol stacks. Is that really the intent? Sounds like a big step. And not strictly necessary. Suggest changing "need to" to "may"= . --aaron --089e01176febf2d55a04fa8e122b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, May 29, 2014 at 7:56 AM, Michael Welzl <michawe@ifi.uio.no> wrote:

The Working Group will:
...
= =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 specify a set of transport services th= at end systems need to provide and provide guidance on choosing among avail= able mechanisms and protocols to obtain a given transport service.


"that end systems need= to provide" sounds like this group is adding a MUST to transport prot= ocol stacks. =C2=A0Is that really the intent? =C2=A0Sounds like a big step.= =C2=A0And not strictly necessary. =C2=A0Suggest changing "need to&quo= t; to "may".

--aaron
--089e01176febf2d55a04fa8e122b-- From nobody Thu May 29 11:56:59 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF71F1A0947 for ; Thu, 29 May 2014 11:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.85 X-Spam-Level: X-Spam-Status: No, score=-4.85 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=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXjXxLGsnffr for ; Thu, 29 May 2014 11:56:51 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 61C531A0A41 for ; Thu, 29 May 2014 11:56:51 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id D4F182B4540; Thu, 29 May 2014 19:56:46 +0100 (BST) Received: from [10.10.10.10] (fgrpf.plus.com [212.159.18.54]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPA id 8E0DC2B4044; Thu, 29 May 2014 19:56:45 +0100 (BST) Content-Type: multipart/alternative; boundary=Apple-Mail-0282DC5E-2FF6-4767-BD29-F116CC0FBC7C Mime-Version: 1.0 (1.0) From: Gorry X-Mailer: iPad Mail (11D201) In-Reply-To: Date: Thu, 29 May 2014 19:56:46 +0100 Content-Transfer-Encoding: 7bit Message-Id: <951DFF7C-E2E4-49DA-BC88-7D2EA69A8E94@erg.abdn.ac.uk> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <5387186 C.5010800@kau.se> To: Aaron Falk Archived-At: http://mailarchive.ietf.org/arch/msg/taps/wHEfA0sc47V89loB9a8XZ0ktudM Cc: Anna Brunstrom , Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 18:56:54 -0000 --Apple-Mail-0282DC5E-2FF6-4767-BD29-F116CC0FBC7C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I wrote this word - I really do not mind, if they implement taps they provid= e this, I.e. Need - if they choose to do nothing then they won't provide so t= hey "may" implement taps. I hope everyone will do taps - and it will be grea= t - but that needs to be proven. I don't care if it says "May" (or "need to provide to implement the framewor= k"). gorry Sent from my iPad > On 29 May 2014, at 19:26, Aaron Falk wrote: >=20 >> On Thu, May 29, 2014 at 7:56 AM, Michael Welzl wrote= : >>=20 >> The Working Group will: >> ... >> =E2=80=A2 specify a set of transport services that end systems nee= d to provide and provide guidance on choosing among available mechanisms and= protocols to obtain a given transport service. >=20 >=20 > "that end systems need to provide" sounds like this group is adding a MUST= to transport protocol stacks. Is that really the intent? Sounds like a bi= g step. And not strictly necessary. Suggest changing "need to" to "may". >=20 > --aaron > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail-0282DC5E-2FF6-4767-BD29-F116CC0FBC7C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I wrote this word - I really do n= ot mind, if they implement taps they provide this, I.e. Need - if they choos= e to do nothing then they won't provide so they "may" implement taps. I hope= everyone will do taps - and it will be great -  but that needs to be p= roven.

I don't care if it says "May" (or "need to p= rovide to implement the framework").

gorry
Sent from my iPad

On 29 May 2014, at 19:26, Aaron Falk <falk-ietf@dgftech.com> wrote:<= br>
On Thu, May 29, 2014 at 7:56 AM, Mich= ael Welzl <michawe@ifi.uio.no> wrote:

The Working Group will:
...
&n= bsp;      =E2=80=A2 specify a set of transport services that e= nd systems need to provide and provide guidance on choosing among available m= echanisms and protocols to obtain a given transport service.


"that end systems need to pr= ovide" sounds like this group is adding a MUST to transport protocol stacks.=  Is that really the intent?  Sounds like a big step.  And no= t strictly necessary.  Suggest changing "need to" to "may".

--aaron
____________________= ___________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman= /listinfo/taps
= --Apple-Mail-0282DC5E-2FF6-4767-BD29-F116CC0FBC7C-- From nobody Thu May 29 12:01:39 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E7AE1A047D for ; Thu, 29 May 2014 12:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaIDm5gFwBCk for ; Thu, 29 May 2014 12:01:35 -0700 (PDT) Received: from mail-vc0-f199.google.com (mail-vc0-f199.google.com [209.85.220.199]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A80421A098A for ; Thu, 29 May 2014 12:01:33 -0700 (PDT) Received: by mail-vc0-f199.google.com with SMTP id id10so2284171vcb.10 for ; Thu, 29 May 2014 12:01:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=vv/46owK9uSueKyHH0eepqJ/He9PIDvMxEIP3YO2kAY=; b=lXcQVF5SffPsfTq6dLr6S5DqER8aZ1QN92zDM0+YBcv1prF8ZJ3PXGZIVaeG93aYUh TcVXHfESPSK/yrrFBeYQxCS/Wobm/wLg7CZfr0fuzc9FiKoBGKRe2vOp92VwGHxeyRJB 3YnUGRX9pTwp3ffmuLc++d6oovVijla6Ic+6Q9iaEGRFWep8/c7+FTMrgl29DOOgLJct 9/ast6VO0RlU4LexlMBryTMQNA0P0q2fOxl3tJv1DwrW3o1tKnVXsClthA/SoxNDhZd5 Mftmu2p8bdKfuyjv44h1odcZhsq1sKd3WKTooJWhMZWhOqZABKINgrtnVK4jcX9NhG9B OZ5Q== X-Gm-Message-State: ALoCoQk9AEsc16Pq0TY6IKu7KSOtjiKzKwVW2b3c3hAXgdzXY1brBpQyzoPANcE/yv+Y3sxCTAG+ X-Received: by 10.58.28.205 with SMTP id d13mr3017540veh.55.1401390089128; Thu, 29 May 2014 12:01:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.84.35 with HTTP; Thu, 29 May 2014 12:01:08 -0700 (PDT) In-Reply-To: <951DFF7C-E2E4-49DA-BC88-7D2EA69A8E94@erg.abdn.ac.uk> References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <537CC4CC.50007@250bpm.com> <537E515F.1080305@250bpm.com> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <951DFF7C-E2E4-49DA-BC88-7D2EA69A8E94@erg.abdn.ac.uk> From: Aaron Falk Date: Thu, 29 May 2014 15:01:08 -0400 Message-ID: To: Gorry Content-Type: multipart/alternative; boundary=047d7b6dc1e67461d804fa8e8e0b Archived-At: http://mailarchive.ietf.org/arch/msg/taps/KBLhnbklXDnIUKVJ5E4jLXTFc7Y Cc: Anna Brunstrom , Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 19:01:38 -0000 --047d7b6dc1e67461d804fa8e8e0b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Gorry. That clarifies. I'd suggest "specify a set of transport services that end systems implementing TAPS need to provide". --aaron On Thu, May 29, 2014 at 2:56 PM, Gorry wrote: > I wrote this word - I really do not mind, if they implement taps they > provide this, I.e. Need - if they choose to do nothing then they won't > provide so they "may" implement taps. I hope everyone will do taps - and = it > will be great - but that needs to be proven. > > I don't care if it says "May" (or "need to provide to implement the > framework"). > > gorry > > Sent from my iPad > > On 29 May 2014, at 19:26, Aaron Falk wrote: > > On Thu, May 29, 2014 at 7:56 AM, Michael Welzl wrote= : > >> >> The Working Group will: >> ... > > =E2=80=A2 specify a set of transport services that end systems nee= d to >> provide and provide guidance on choosing among available mechanisms and >> protocols to obtain a given transport service. >> > > > "that end systems need to provide" sounds like this group is adding a MUS= T > to transport protocol stacks. Is that really the intent? Sounds like a > big step. And not strictly necessary. Suggest changing "need to" to "ma= y". > > --aaron > > _______________________________________________ > > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > > --047d7b6dc1e67461d804fa8e8e0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, Gorry. =C2=A0That clarifies. =C2=A0I'd suggest= "specify a set of transport services that end sys= tems implementing TAPS need to provide".

--aaron


On Thu,= May 29, 2014 at 2:56 PM, Gorry <gorry@erg.abdn.ac.uk> wr= ote:
I wrote this wor= d - I really do not mind, if they implement taps they provide this, I.e. Ne= ed - if they choose to do nothing then they won't provide so they "= ;may" implement taps. I hope everyone will do taps - and it will be gr= eat - =C2=A0but that needs to be proven.

I don't care if it says "May" (or "n= eed to provide to implement the framework").

= gorry

Sent from my iPad

On 29= May 2014, at 19:26, Aaron Falk <falk-ietf@dgftech.com> wrote:

On Thu, May 29, 2014 at 7:56 AM, Micha= el Welzl <michawe@ifi.uio.no> wrote:

The Working Group will:
...
= =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 specify a set of transport services th= at end systems need to provide and provide guidance on choosing among avail= able mechanisms and protocols to obtain a given transport service.


"that end systems need= to provide" sounds like this group is adding a MUST to transport prot= ocol stacks. =C2=A0Is that really the intent? =C2=A0Sounds like a big step.= =C2=A0And not strictly necessary. =C2=A0Suggest changing "need to&quo= t; to "may".

--aaron
_______= ________________________________________

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

--047d7b6dc1e67461d804fa8e8e0b-- From nobody Thu May 29 16:13:56 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3035C1A06B7 for ; Thu, 29 May 2014 16:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KfkjSAxkTCI for ; Thu, 29 May 2014 16:13:55 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED2641A0301 for ; Thu, 29 May 2014 16:13:54 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id va2so1059238obc.11 for ; Thu, 29 May 2014 16:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=GvALVVB2PTY0H+zJ0Qu8ayNuwRy1vklc11wseQT38u4=; b=k/LSqV9uf7vnpj/60QHl0FAMz99iX6Pm7AxdStlyxc0LuAWetW2VX6OfCB4kPmj31h s1NNCOYXuWj+1Rgtzxo/E4tJLkSnM+5e9+dB5PgD3/ecn1o6zJCf2qoryd7IQM9Egqlj 46MW2pItduPxKyEPl7kTKCDMFGjBbxkSgh9+nrHYOt7TaGVHtm86yqSmPK1ZdWjOyMFn hE287kIXBY4Bs3buoTEF93MXtlg1CPdZCkL5Ixq8DhXAsFMs69fUjGoEHqK3VewSbFM5 0nicfEOkw9vwKtzM1PhhejMSZw0mW0oF8UzLbu5GFgfMAatkDaBE+ydwaBZcWGiBk35h Jw6g== X-Received: by 10.60.45.130 with SMTP id n2mr12648978oem.12.1401405230661; Thu, 29 May 2014 16:13:50 -0700 (PDT) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id to6sm3678546obb.6.2014.05.29.16.13.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 16:13:50 -0700 (PDT) Message-ID: <5387BF2C.9010201@gmail.com> Date: Thu, 29 May 2014 18:13:48 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: taps@ietf.org References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <5387186C.501080 0@kau.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/E_kQ5V4xM4o5ET1dRdAXXp-lKqA Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 23:13:56 -0000 On 05/29/2014 07:13 AM, Michael Welzl wrote: > On 29. mai 2014, at 14:01, Toby Moncaster wrote: > >> final nit… I think we should say >> >> “…coordinate closely with other Working Group and IRTF Research Groups.” (not and/or) > fixed > > >> Also wasn’t Spencer encouraging us to mention potential IAB interaction? In which case this would be the sentence to say that in… > Since I don't think I'm the right person to decide whether the IAB should be mentioned or not I'll see what happens on the list upon Gorry's response before incorporating text on that. I believe Spencer was encouraging Brian (and it turns out I was using "Brian" as a multicast address that also resolves to "Joe", and any other IAB members who are listening) to tell us if the IAB is likely to have a revised program that we could usefully refer to in the charter any time soon. Unless the answer is some variant of "the IAB just approved a relevant program", it's fine to leave the IAB unmentioned. Thanks, Spencer From nobody Thu May 29 16:20:42 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56FB1A06ED for ; Thu, 29 May 2014 16:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auu8nDYMM3aG for ; Thu, 29 May 2014 16:20:39 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CBA41A06E7 for ; Thu, 29 May 2014 16:20:39 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id wo20so1054882obc.6 for ; Thu, 29 May 2014 16:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=cxFs04IJQdMZYtkuIyX8ZP2I9NQDycLmvVw/3eL6cuk=; b=bj8LBKWwT370coUaVVJ5huFJT8R0P2HfEYkSETAe9nIidU88rxeh68eq3Fz4xEaD76 coyVf1/q5AW9tgPhYUxpdGfhUgbcR5h/3CUuG64YDALzMKZBLehxLNkp8Kin8woXMnoq HaLtZmY+hvfctpwVh90er76aIlDyp8m8gABWMKl6EWGf4qt8IL7EeaO+TmklaeaSbYZN 5uNIHRCtKePVybAG4ELN97G7JZI8SPttCD8zdfUPVmXCSOZl1vPcXuysFmgE1rYqKL1D THj/v5tLjPgvoFHlxsDWzU7l7iTpl4eNjhp/iPadyClejkKfPG2Gh3f2FGJ2I8F3vQbY lmVw== X-Received: by 10.182.38.199 with SMTP id i7mr12663486obk.68.1401405635087; Thu, 29 May 2014 16:20:35 -0700 (PDT) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id tk2sm6988108oeb.2.2014.05.29.16.20.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 16:20:34 -0700 (PDT) Message-ID: <5387C0C1.3030909@gmail.com> Date: Thu, 29 May 2014 18:20:33 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: taps@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/g1So6k8vZYfyEsOs5vApGq_HYkA Subject: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 23:20:41 -0000 The folks on the mailing list who have responded so far, seem to be converging ... Is https://sites.google.com/site/transportprotocolservices/charter-proposal still the most recent charter version? Is it time to do a Mailing List Last Call before I put the charter proposal forward in the datatracker? :-) Spencer, who finally remembered to change the subject field :-) From nobody Thu May 29 23:55: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 7130F1A03A2 for ; Thu, 29 May 2014 23:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guvsc1idxOl8 for ; Thu, 29 May 2014 23:55:32 -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 31FC01A04B6 for ; Thu, 29 May 2014 23:55:32 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WqGis-0002sQ-Kv; Fri, 30 May 2014 08:55:26 +0200 Received: from [84.88.52.198] (helo=[192.168.20.115]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1WqGir-00063U-WB; Fri, 30 May 2014 08:55:26 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: <5387C0C1.3030909@gmail.com> Date: Fri, 30 May 2014 08:55:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <98F56371-A849-45FB-8148-28AACCDE04EC@ifi.uio.no> References: <5387C0C1.3030909@gmail.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 3 sum rcpts/h 10 sum msgs/h 5 total rcpts 16986 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 105862C27E49B694F44B9DFC26C0955622FF24C7 X-UiO-SPAM-Test: remote_host: 84.88.52.198 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 5 max/h 3 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/GIv2lto77DFG7GS1kOd12wmvPj4 Cc: taps@ietf.org Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 06:55:34 -0000 On 30. mai 2014, at 01:20, Spencer Dawkins = wrote: > The folks on the mailing list who have responded so far, seem to be = converging ... >=20 > Is = https://sites.google.com/site/transportprotocolservices/charter-proposal = still the most recent charter version? Yes. > Is it time to do a Mailing List Last Call before I put the charter = proposal forward in the datatracker? :-) I think it's worth a try! Folks, if you have any comments, bring them up = within the next 3 days, including today - i.e. by the end of Sunday. Cheers, Michael From nobody Fri May 30 00:13:18 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 F22B11A0189 for ; Fri, 30 May 2014 00:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUM6dEEf3DUb for ; Fri, 30 May 2014 00:13:14 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 24AD91A0030 for ; Fri, 30 May 2014 00:13:14 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 7AB052B44C8 for ; Fri, 30 May 2014 08:13:09 +0100 (BST) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Fri, 30 May 2014 08:13:09 +0100 Message-ID: <40b7d9afbebeab71f0694e546bb151b7.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <98F56371-A849-45FB-8148-28AACCDE04EC@ifi.uio.no> References: <5387C0C1.3030909@gmail.com> <98F56371-A849-45FB-8148-28AACCDE04EC@ifi.uio.no> Date: Fri, 30 May 2014 08:13:09 +0100 From: gorry@erg.abdn.ac.uk To: taps@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/taps/1siP9GOaAE6C-5NeDsHjcAJ2nRA Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 07:13:16 -0000 This seems like a good Charter to me: https://sites.google.com/site/transportprotocolservices/charter-proposal Gorry > > On 30. mai 2014, at 01:20, Spencer Dawkins > wrote: > >> The folks on the mailing list who have responded so far, seem to be >> converging ... >> >> Is >> https://sites.google.com/site/transportprotocolservices/charter-proposal >> still the most recent charter version? > > Yes. > > >> Is it time to do a Mailing List Last Call before I put the charter >> proposal forward in the datatracker? :-) > > I think it's worth a try! Folks, if you have any comments, bring them up > within the next 3 days, including today - i.e. by the end of Sunday. > > Cheers, > Michael > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Fri May 30 00:41:51 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 7A8651A0968 for ; Fri, 30 May 2014 00:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_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 qpZ8KpfsDkDA for ; Fri, 30 May 2014 00:41:46 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21AE31A08BF for ; Fri, 30 May 2014 00:41:45 -0700 (PDT) Received: from [192.168.1.200] (p508F3F42.dip0.t-ipconnect.de [80.143.63.66]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id C32631C10465C; Fri, 30 May 2014 09:41:37 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen X-Priority: 3 (Normal) In-Reply-To: <40b7d9afbebeab71f0694e546bb151b7.squirrel@www.erg.abdn.ac.uk> Date: Fri, 30 May 2014 09:41:36 +0200 Content-Transfer-Encoding: 7bit Message-Id: <3A2613AA-C958-4FAF-8D4D-4705E0021BF9@fh-muenster.de> References: <5387C0C1.3030909@gmail.com> <98F56371-A849-45FB-8148-28AACCDE04EC@ifi.uio.no> <40b7d9afbebeab71f0694e546bb151b7.squirrel@www.erg.abdn.ac.uk> To: Gorry Fairhurst X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/taps/5VpGDuhJwQScvpMcTOVP2qhafiI Cc: taps@ietf.org Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 07:41:49 -0000 On 30 May 2014, at 09:13, gorry@erg.abdn.ac.uk wrote: > This seems like a good Charter to me: > https://sites.google.com/site/transportprotocolservices/charter-proposal Full ACK. Best regards Michael > > Gorry > >> >> On 30. mai 2014, at 01:20, Spencer Dawkins >> wrote: >> >>> The folks on the mailing list who have responded so far, seem to be >>> converging ... >>> >>> Is >>> https://sites.google.com/site/transportprotocolservices/charter-proposal >>> still the most recent charter version? >> >> Yes. >> >> >>> Is it time to do a Mailing List Last Call before I put the charter >>> proposal forward in the datatracker? :-) >> >> I think it's worth a try! Folks, if you have any comments, bring them up >> within the next 3 days, including today - i.e. by the end of Sunday. >> >> Cheers, >> Michael >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >> > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Fri May 30 01:25:02 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2671A6F12 for ; Fri, 30 May 2014 01:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 1NI0wvBUL-Mn for ; Fri, 30 May 2014 01:24:54 -0700 (PDT) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4503C1A6F0C for ; Fri, 30 May 2014 01:24:54 -0700 (PDT) Received: by mail-qg0-f41.google.com with SMTP id j5so4363685qga.14 for ; Fri, 30 May 2014 01:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HgFeMTlztOVOw/yi7x2eddEWx438+emVufW0EMUZ8qg=; b=080jyE1qtLAXuiacldVSmRKt4qpaRJEqOABYK9wgLEumirEatoCG8CjghpakbdMrgz Qxv4CGuZxlrGfcDPGB+u4dA6WpoV9J/wzik1wsPuOdJ7F+gkhifRx6lydtgZ3XrSWlvG 0d3KJR90Lhmh35LVmJevlhHeEMrb5/6F/j8R2yUdM05MeJUfPGuSDXDZgBmzYxH1VcPb VRH7MdpLKzxiuNBkr85Xxmi7JeJF8Gcsaxmv8oVvoueDjtvlZ2DTbJEYCfMhrp8sITBE CgjNI/E9pVF9jq12FnZXrPU6JEoDJJJohe/lbMXt9VLsUhRPf6ul0nxHVESSgoeEZ2dT I3nA== MIME-Version: 1.0 X-Received: by 10.140.37.135 with SMTP id r7mr17355901qgr.61.1401438289666; Fri, 30 May 2014 01:24:49 -0700 (PDT) Sender: crowcroft@gmail.com Received: by 10.140.48.14 with HTTP; Fri, 30 May 2014 01:24:49 -0700 (PDT) In-Reply-To: <40b7d9afbebeab71f0694e546bb151b7.squirrel@www.erg.abdn.ac.uk> References: <5387C0C1.3030909@gmail.com> <98F56371-A849-45FB-8148-28AACCDE04EC@ifi.uio.no> <40b7d9afbebeab71f0694e546bb151b7.squirrel@www.erg.abdn.ac.uk> Date: Fri, 30 May 2014 09:24:49 +0100 X-Google-Sender-Auth: rVNX6L0_Itcq-OpbfrHp0PrgZPU Message-ID: From: Jon Crowcroft To: Gorry Fairhurst Content-Type: multipart/alternative; boundary=001a11c146d06e2adf04fa99c799 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/qQwOYrazrM5Oyu-LnrcYTSFRQhQ Cc: taps@ietf.org Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 08:24:56 -0000 --001a11c146d06e2adf04fa99c799 Content-Type: text/plain; charset=UTF-8 +1 On Fri, May 30, 2014 at 8:13 AM, wrote: > This seems like a good Charter to me: > https://sites.google.com/site/transportprotocolservices/charter-proposal > > Gorry > > > > > On 30. mai 2014, at 01:20, Spencer Dawkins < > spencerdawkins.ietf@gmail.com> > > wrote: > > > >> The folks on the mailing list who have responded so far, seem to be > >> converging ... > >> > >> Is > >> > https://sites.google.com/site/transportprotocolservices/charter-proposal > >> still the most recent charter version? > > > > Yes. > > > > > >> Is it time to do a Mailing List Last Call before I put the charter > >> proposal forward in the datatracker? :-) > > > > I think it's worth a try! Folks, if you have any comments, bring them up > > within the next 3 days, including today - i.e. by the end of Sunday. > > > > Cheers, > > Michael > > > > _______________________________________________ > > Taps mailing list > > Taps@ietf.org > > https://www.ietf.org/mailman/listinfo/taps > > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > --001a11c146d06e2adf04fa99c799 Content-Type: text/html; charset=UTF-8
+1


On Fri, May 30, 2014 at 8:13 AM, <gorry@erg.abdn.ac.uk> wrote:
This seems like a good Charter to me:
https://sites.google.com/site/transportprotocolservices/charter-proposal

Gorry

>
> On 30. mai 2014, at 01:20, Spencer Dawkins <spencerdawkins.ietf@gmail.com>
> wrote:
>
>> The folks on the mailing list who have responded so far, seem to be
>> converging ...
>>
>> Is
>> https://sites.google.com/site/transportprotocolservices/charter-proposal
>> still the most recent charter version?
>
> Yes.
>
>
>> Is it time to do a Mailing List Last Call before I put the charter
>> proposal forward in the datatracker? :-)
>
> I think it's worth a try! Folks, if you have any comments, bring them up
> within the next 3 days, including today - i.e. by the end of Sunday.
>
> Cheers,
> Michael
>
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps
>


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

--001a11c146d06e2adf04fa99c799-- From nobody Fri May 30 02:23:02 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2851A0385 for ; Fri, 30 May 2014 01:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_5X7XY4z6Pn for ; Fri, 30 May 2014 01:34:39 -0700 (PDT) Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8B51A6F00 for ; Fri, 30 May 2014 01:34:38 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id x48so1566498wes.8 for ; Fri, 30 May 2014 01:34:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:mime-version:in-reply-to :content-type:content-transfer-encoding:message-id:cc:subject:date :to; bh=pUADEpJ35ZvMhYdva6e19NDP79kunBJHXs252az+YhE=; b=A/7JTjyoT10GnQOBd4CZrT9kvZrvOOCzrizOmREuz0Qbu0tK1EvsMr2z6dcle9s8RR W5bpWJOHpDwtCUyvGFfSNKOZHg+lIC13zHpE8r8UIKuvsBocMtBHkxJ/QPh7eoCZfitb h1tRaNvqb13oV7v38Ls9EcW2BlA3fKAklRKPb6w56PB675C7dJyizez8mnel+YU70GKf 4Xw+heYoZ4GPqTeUWUF9bmapuR3b9qE0e5YihOyxT75HrQ/uNccIrK/P9yTZvDdYYPr7 CbQ1j6KkT2F6lWqcTsyBSHLVekRQTbdvFZAIgQ0xpbzjc/3tFxjQl7YyX77hvVxk5vv3 Z0ww== X-Gm-Message-State: ALoCoQng4/AupmpLVPbKFpWEeN5h7wsd5aX+0AsPldvgqixe6Y+anWeg/JHbc2SOWhafsPmInnrb X-Received: by 10.194.201.195 with SMTP id kc3mr19637095wjc.54.1401438873051; Fri, 30 May 2014 01:34:33 -0700 (PDT) Received: from [192.168.0.13] (abo-106-153-68.bdx.modulonet.fr. [85.68.153.106]) by mx.google.com with ESMTPSA id gi8sm4060558wib.8.2014.05.30.01.34.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 May 2014 01:34:31 -0700 (PDT) From: Marie-Jose Montpetit X-Google-Original-From: Marie-Jose Montpetit References: <5387C0C1.3030909@gmail.com> <98F56371-A849-45FB-8148-28AACCDE04EC@ifi.uio.no> <40b7d9afbebeab71f0694e546bb151b7.squirrel@www.erg.abdn.ac.uk> <3A2613AA-C958-4FAF-8D4D-4705E0021BF9@fh-muenster.de> Mime-Version: 1.0 (1.0) In-Reply-To: <3A2613AA-C958-4FAF-8D4D-4705E0021BF9@fh-muenster.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <225FB91B-7D87-46E0-9D58-92C78BBC2C8F@mit.edu> X-Mailer: iPad Mail (11D201) Date: Fri, 30 May 2014 10:34:30 +0200 To: Michael Tuexen Archived-At: http://mailarchive.ietf.org/arch/msg/taps/EzCI193M1FC02_YFm-dyQrg7PA0 X-Mailman-Approved-At: Fri, 30 May 2014 02:23:01 -0700 Cc: Gorry Fairhurst , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 08:34:40 -0000 Good for me Marie-Jos=C3=A9 Montpetit marie@mjmontpetit.com mariejo@mit.edu > On May 30, 2014, at 9:41, Michael Tuexen wrote: >=20 >> On 30 May 2014, at 09:13, gorry@erg.abdn.ac.uk wrote: >>=20 >> This seems like a good Charter to me: >> https://sites.google.com/site/transportprotocolservices/charter-proposal > Full ACK. >=20 > Best regards > Michael >>=20 >> Gorry >>=20 >>>=20 >>> On 30. mai 2014, at 01:20, Spencer Dawkins >>> wrote: >>>=20 >>>> The folks on the mailing list who have responded so far, seem to be >>>> converging ... >>>>=20 >>>> Is >>>> https://sites.google.com/site/transportprotocolservices/charter-proposa= l >>>> still the most recent charter version? >>>=20 >>> Yes. >>>=20 >>>=20 >>>> Is it time to do a Mailing List Last Call before I put the charter >>>> proposal forward in the datatracker? :-) >>>=20 >>> I think it's worth a try! Folks, if you have any comments, bring them up= >>> within the next 3 days, including today - i.e. by the end of Sunday. >>>=20 >>> Cheers, >>> Michael >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri May 30 02:24:02 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9581A075C for ; Fri, 30 May 2014 02:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5dXmBsssRrD for ; Fri, 30 May 2014 02:23:58 -0700 (PDT) Received: from ppsw-41.csi.cam.ac.uk (ppsw-41-v6.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A12661A03C2 for ; Fri, 30 May 2014 02:23:58 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from s235i161.wolfson.cam.ac.uk ([128.232.235.161]:48108 helo=[10.0.1.2]) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpsa (PLAIN:tm444) (TLSv1:AES128-SHA:128) id 1WqJ2X-000548-Pt (Exim 4.82_3-c0e5623) for taps@ietf.org (return-path ); Fri, 30 May 2014 10:23:53 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Toby Moncaster In-Reply-To: <225FB91B-7D87-46E0-9D58-92C78BBC2C8F@mit.edu> Date: Fri, 30 May 2014 10:23:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2AA60096-31CE-4D28-8864-0DC1E9EECB01@cl.cam.ac.uk> References: <5387C0C1.3030909@gmail.com> <98F56371-A849-45FB-8148-28AACCDE04EC@ifi.uio.no> <40b7d9afbebeab71f0694e546bb151b7.squirrel@www.erg.abdn.ac.uk> <3A2613AA-C958-4FAF-8D4D-4705E0021BF9@fh-muenster.de> <225FB91B-7D87-46E0-9D58-92C78BBC2C8F@mit.edu> To: "taps@ietf.org" X-Mailer: Apple Mail (2.1878.2) Sender: "T. Moncaster" Archived-At: http://mailarchive.ietf.org/arch/msg/taps/EBFRMxrjLjpAMKUTj8npxTsn928 Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 09:24:01 -0000 +1 On 30 May 2014, at 09:34, Marie-Jose Montpetit = wrote: > Good for me >=20 > Marie-Jos=E9 Montpetit > marie@mjmontpetit.com > mariejo@mit.edu >=20 >> On May 30, 2014, at 9:41, Michael Tuexen = wrote: >>=20 >>> On 30 May 2014, at 09:13, gorry@erg.abdn.ac.uk wrote: >>>=20 >>> This seems like a good Charter to me: >>> = https://sites.google.com/site/transportprotocolservices/charter-proposal >> Full ACK. >>=20 >> Best regards >> Michael >>>=20 >>> Gorry >>>=20 >>>>=20 >>>> On 30. mai 2014, at 01:20, Spencer Dawkins = >>>> wrote: >>>>=20 >>>>> The folks on the mailing list who have responded so far, seem to = be >>>>> converging ... >>>>>=20 >>>>> Is >>>>> = https://sites.google.com/site/transportprotocolservices/charter-proposal >>>>> still the most recent charter version? >>>>=20 >>>> Yes. >>>>=20 >>>>=20 >>>>> Is it time to do a Mailing List Last Call before I put the charter >>>>> proposal forward in the datatracker? :-) >>>>=20 >>>> I think it's worth a try! Folks, if you have any comments, bring = them up >>>> within the next 3 days, including today - i.e. by the end of = Sunday. >>>>=20 >>>> Cheers, >>>> Michael >>>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>=20 >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri May 30 02:28: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 C0C0C1A0100 for ; Fri, 30 May 2014 02:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCzOlx5gjtpk for ; Fri, 30 May 2014 02:28:08 -0700 (PDT) Received: from nasse.dc.kau.se (smtp.kau.se [193.10.220.39]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BD1C1A075C for ; Fri, 30 May 2014 02:28:08 -0700 (PDT) X-Spam-Processed: mail.kau.se, Fri, 30 May 2014 11:27:57 +0200 (not processed: spam filter heuristic analysis disabled) X-Authenticated-Sender: annabrun@kau.se X-MDRemoteIP: 193.11.155.70 X-Return-Path: anna.brunstrom@kau.se X-Envelope-From: anna.brunstrom@kau.se X-MDaemon-Deliver-To: taps@ietf.org Message-ID: <53884F1D.1020900@kau.se> Date: Fri, 30 May 2014 11:27:57 +0200 From: Anna Brunstrom User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: taps@ietf.org References: <5387C0C1.3030909@gmail.com> <98F56371-A849-45FB-8148-28AACCDE04EC@ifi.uio.no> <40b7d9afbebeab71f0694e546bb151b7.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <40b7d9afbebeab71f0694e546bb151b7.squirrel@www.erg.abdn.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/2lPwGWp0_UZUEB-kqwSLj-E9KL4 Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 09:28:09 -0000 +1 Anna On 2014-05-30 09:13, gorry@erg.abdn.ac.uk wrote: > This seems like a good Charter to me: > https://sites.google.com/site/transportprotocolservices/charter-proposal > > Gorry > >> On 30. mai 2014, at 01:20, Spencer Dawkins >> wrote: >> >>> The folks on the mailing list who have responded so far, seem to be >>> converging ... >>> >>> Is >>> https://sites.google.com/site/transportprotocolservices/charter-proposal >>> still the most recent charter version? >> Yes. >> >> >>> Is it time to do a Mailing List Last Call before I put the charter >>> proposal forward in the datatracker? :-) >> I think it's worth a try! Folks, if you have any comments, bring them up >> within the next 3 days, including today - i.e. by the end of Sunday. >> >> Cheers, >> Michael >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >> > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri May 30 07:29:48 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 D507E1A093A for ; Fri, 30 May 2014 07:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKF7ZUFvSXKO for ; Fri, 30 May 2014 07:29:45 -0700 (PDT) Received: from mail-vc0-f197.google.com (mail-vc0-f197.google.com [209.85.220.197]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA201A0901 for ; Fri, 30 May 2014 07:29:44 -0700 (PDT) Received: by mail-vc0-f197.google.com with SMTP id hq11so564237vcb.8 for ; Fri, 30 May 2014 07:29:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=4xMaCJ8CiyUKDuf52fQ4CqA8eXUTfvx73RZJ/awx280=; b=knrw5EipYje9Z/nPcqA6eyOhLkTmIKpICqCwlmIA9gqtu52Urre7ICmhI/l7EiEJ9v j/TqexEAMozcqaoXhphb1sjaJ/9A8hoUWOFatE7H7DwXW0eJF4Q7qe9CK14J8SeTZ5Pr k25Cye0Kt/jI4VRcbTFRmxgGqaWbX3JRXfY5hiC5mP0Q1vnaTr2PKCZPuOfAihwCC3Lu gDKSWAYjTaSDJJIGeO/voxeHnwhNDoWcXWccS69NGsyEpGQ/bJIjNdS5YGWUxk58MgtT 79fjQSMVAdL2VCJYWniV1YarpNcAFKFqe2zPLSniTwDZjAzHH4Suo4r0wo7nG8GhbnHz hc5g== X-Gm-Message-State: ALoCoQl4QWz/4KzNF1vC0Fsme0FkSrs8xppGm9plg0G4lvJb/d+9At5K533EM6VxOf93twt2QCtd X-Received: by 10.58.207.74 with SMTP id lu10mr13830061vec.15.1401460180133; Fri, 30 May 2014 07:29:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.84.35 with HTTP; Fri, 30 May 2014 07:29:20 -0700 (PDT) In-Reply-To: <98F56371-A849-45FB-8148-28AACCDE04EC@ifi.uio.no> References: <5387C0C1.3030909@gmail.com> <98F56371-A849-45FB-8148-28AACCDE04EC@ifi.uio.no> From: Aaron Falk Date: Fri, 30 May 2014 10:29:20 -0400 Message-ID: To: Michael Welzl Content-Type: multipart/alternative; boundary=047d7b6783ce343ec504fa9ee0f8 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/8iKytk1t6uFZIlvCCeSt7yZy0XA Cc: Spencer Dawkins , taps@ietf.org Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 14:29:47 -0000 --047d7b6783ce343ec504fa9ee0f8 Content-Type: text/plain; charset=UTF-8 My proposed wording change (which at least Gorry accepted) is not in the current draft. Repeating: Revise working group goal #2 to read "specify a set of transport services that end systems **implementing TAPS** need to provide and provide guidance on choosing among available mechanisms and protocols to obtain a given transport service." Otherwise looks good. --aaron On Fri, May 30, 2014 at 2:55 AM, Michael Welzl wrote: > > On 30. mai 2014, at 01:20, Spencer Dawkins > wrote: > > > The folks on the mailing list who have responded so far, seem to be > converging ... > > > > Is > https://sites.google.com/site/transportprotocolservices/charter-proposal > still the most recent charter version? > > Yes. > > > > Is it time to do a Mailing List Last Call before I put the charter > proposal forward in the datatracker? :-) > > I think it's worth a try! Folks, if you have any comments, bring them up > within the next 3 days, including today - i.e. by the end of Sunday. > > Cheers, > Michael > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > --047d7b6783ce343ec504fa9ee0f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My proposed wording change (which at least Gorry accepted)= is not in the current draft. =C2=A0Repeating:

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

Otherwise looks good.

--aaron<= /div>



On Fri, May 30, 2014 at 2:55 AM, Michael Welzl <michawe@ifi.= uio.no> wrote:

On 30. mai 2014, at 01:20, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:

> The folks on the mailing list who have responded so far, seem to be co= nverging ...
>
> Is https://sites.google.com/site/transport= protocolservices/charter-proposal still the most recent charter version= ?

Yes.


> Is it time to do a Mailing List Last Call before I put the charter pro= posal forward in the datatracker? :-)

I think it's worth a try! Folks, if you have any comments, bring = them up within the next 3 days, including today - i.e. by the end of Sunday= .

Cheers,
Michael

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

--047d7b6783ce343ec504fa9ee0f8-- From nobody Fri May 30 07:48:59 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552741A08E6 for ; Fri, 30 May 2014 07:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5-9XaaSpAuX for ; Fri, 30 May 2014 07:48:56 -0700 (PDT) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 885B61A0955 for ; Fri, 30 May 2014 07:48:49 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1WqO6t-0003xB-Td; Fri, 30 May 2014 16:48:43 +0200 Received: from m83-184-127-212.cust.tele2.no ([83.184.127.212]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WqO6s-0003DH-WE; Fri, 30 May 2014 16:48:43 +0200 References: <5387C0C1.3030909@gmail.com> <98F56371-A849-45FB-8148-28AACCDE04EC@ifi.uio.no> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-0380D236-9D86-4347-A3C3-E5BF5BDE69EB Content-Transfer-Encoding: 7bit Message-Id: <90D90035-156C-47A4-8AFE-32A8FAEEF6A7@ifi.uio.no> X-Mailer: iPhone Mail (11D167) From: Michael Welzl Date: Fri, 30 May 2014 16:48:41 +0200 To: Aaron Falk X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 3 msgs/h 1 sum rcpts/h 5 sum msgs/h 2 total rcpts 17004 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 410FE8D196FC74E750DEBF8692E4B5A6D3BEBB20 X-UiO-SPAM-Test: remote_host: 83.184.127.212 spam_score: -49 maxlevel 80 minaction 2 bait 0 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/300tZ2nvK-a7fN0UwV_WmC3rJLI Cc: Spencer Dawkins , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 14:48:58 -0000 --Apple-Mail-0380D236-9D86-4347-A3C3-E5BF5BDE69EB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable sorry, agree too, will fix asap (but can't for a few hours) Sent from my iPhone > On 30. mai 2014, at 16:29, Aaron Falk wrote: >=20 > My proposed wording change (which at least Gorry accepted) is not in the c= urrent draft. Repeating: >=20 > Revise working group goal #2 to read "specify a set of transport services t= hat end systems **implementing TAPS** need to provide and provide guidance o= n choosing among available mechanisms and protocols to obtain a given transp= ort service." >=20 > Otherwise looks good. >=20 > --aaron >=20 >=20 >=20 >> On Fri, May 30, 2014 at 2:55 AM, Michael Welzl wrote= : >>=20 >> On 30. mai 2014, at 01:20, Spencer Dawkins wrote: >>=20 >> > The folks on the mailing list who have responded so far, seem to be con= verging ... >> > >> > Is https://sites.google.com/site/transportprotocolservices/charter-prop= osal still the most recent charter version? >>=20 >> Yes. >>=20 >>=20 >> > Is it time to do a Mailing List Last Call before I put the charter prop= osal forward in the datatracker? :-) >>=20 >> I think it's worth a try! Folks, if you have any comments, bring them up w= ithin the next 3 days, including today - i.e. by the end of Sunday. >>=20 >> Cheers, >> Michael >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 --Apple-Mail-0380D236-9D86-4347-A3C3-E5BF5BDE69EB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
sorry, agree too, will fix asap (but can't for a few hours)

Sent from my iPhone

On 30. mai 2014, at 16:29, Aaron Falk <falk-ietf@dgftech.com> wrote:

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

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

Otherwise looks good.

--aaron



On Fri, May 30, 2014 at 2:55 AM, Michael Welzl <michawe@ifi.uio.no> wrote:

On 30. mai 2014, at 01:20, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:

> The folks on the mailing list who have responded so far, seem to be converging ...
>
> Is https://sites.google.com/site/transportprotocolservices/charter-proposal still the most recent charter version?

Yes.


> Is it time to do a Mailing List Last Call before I put the charter proposal forward in the datatracker? :-)

I think it's worth a try! Folks, if you have any comments, bring them up within the next 3 days, including today - i.e. by the end of Sunday.

Cheers,
Michael

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

--Apple-Mail-0380D236-9D86-4347-A3C3-E5BF5BDE69EB-- From nobody Fri May 30 08:55:48 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 6BDFF1A70FE for ; Fri, 30 May 2014 08:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJIw1z6pQcII for ; Fri, 30 May 2014 08:55:41 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2DC21A7033 for ; Fri, 30 May 2014 08:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=842; q=dns/txt; s=iport; t=1401465337; x=1402674937; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NtiaJvqiLybYNjrCss+tozqkuaissPgOrUwZkP1o61o=; b=VcgbxlnIHSMSnW+3XkJfQxjBqJwFJAWO+iyA089TvCCSDtCw9RrX68M1 cgVli80G54m8a+PiiJi2VXiBauzRRlHmjuetgBYWPht0CSrXDtrrpk+hG 80R48mpp99YqsLez44OVotJTGSiXkAE7HAp80eYfjbp323HMyqD+bFKPB c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8LAO+oiFOtJV2Y/2dsb2JhbABZgweBKoJspy8GmBoBGXAWdIImAQEEIwQNRRACAQgaAiYCAgIwFRACBAENBYhCsjekWReBKoQriEozB4J1gUsBA5l+ky2DOIIv X-IronPort-AV: E=Sophos;i="4.98,941,1392163200"; d="scan'208";a="48690832" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP; 30 May 2014 15:55:36 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s4UFtaJ1007209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 May 2014 15:55:36 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Fri, 30 May 2014 10:55:36 -0500 From: "Joe Hildebrand (jhildebr)" To: Aaron Falk , Michael Welzl Thread-Topic: [Taps] So, is this the -00 charter yet? Thread-Index: AQHPe5Sc/jue/Kq5GUeSg8bXP9PSQJtZBOsAgAB+1AD//7OGgA== Date: Fri, 30 May 2014 15:55:35 +0000 Message-ID: References: <5387C0C1.3030909@gmail.com> <98F56371-A849-45FB-8148-28AACCDE04EC@ifi.uio.no> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/S7a6GHU5w8197JiEeMic3caXvUE Cc: Spencer Dawkins , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 15:55:42 -0000 T24gNS8zMC8xNCwgODoyOSBBTSwgIkFhcm9uIEZhbGsiIDxmYWxrLWlldGZAZGdmdGVjaC5jb20+ IHdyb3RlOg0KDQo+TXkgcHJvcG9zZWQgd29yZGluZyBjaGFuZ2UgKHdoaWNoIGF0IGxlYXN0IEdv cnJ5IGFjY2VwdGVkKSBpcyBub3QgaW4gdGhlDQo+Y3VycmVudCBkcmFmdC4gIFJlcGVhdGluZzoN Cj4NCj4NCj5SZXZpc2Ugd29ya2luZyBncm91cCBnb2FsICMyIHRvIHJlYWQgInNwZWNpZnkgYSBz ZXQgb2YgdHJhbnNwb3J0IHNlcnZpY2VzDQo+dGhhdCBlbmQgc3lzdGVtcyAqKmltcGxlbWVudGlu ZyBUQVBTKiogbmVlZCB0byBwcm92aWRlIGFuZCBwcm92aWRlDQo+Z3VpZGFuY2Ugb24gY2hvb3Np bmcgYW1vbmcgYXZhaWxhYmxlIG1lY2hhbmlzbXMgYW5kIHByb3RvY29scyB0byBvYnRhaW4gYQ0K PmdpdmVuIHRyYW5zcG9ydCBzZXJ2aWNlLiINCg0KVGhlcmUncyBubyBwcm90b2NvbCBmb3IgVEFQ UyB5ZXQsIHNvIG5vYm9keSBpcyBnb2luZyB0byAiaW1wbGVtZW50IFRBUFMiLg0KU3VnZ2VzdGVk IGNoYW5nZTogImVuZCBzeXN0ZW1zIG5lZWQgdG8gcHJvdmlkZSIgLT4gImFwcGxpY2F0aW9ucyB3 YW50IHRvDQp1c2UiLg0KDQotLSANCkpvZSBIaWxkZWJyYW5kDQoNCg0KDQo= From nobody Fri May 30 08:57:52 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 34D401A08EF for ; Fri, 30 May 2014 08:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JKD8IGiezGz for ; Fri, 30 May 2014 08:57:49 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDE861A08E1 for ; Fri, 30 May 2014 08:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1032; q=dns/txt; s=iport; t=1401465465; x=1402675065; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=2Xm3G/ZdC3lMfYiFao7HRvwD7boXqEIAKuzLaV+cejc=; b=JxboK+jvy2/+Qp2p1WVSsrktmHg0xCgReCoy418GEh9GONKK+jEdVx6f SZU1z9A25e+3TGuMgv3cspWpTWbVDFoKccpBfvdtkQ7fXCqFj/sI7Er4G iNqlchntzyrs0EsKuHCPSMuifYM9afQOWKUFvoNdzc2UMTQmD1tyhuCii Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhELAOKpiFOtJA2J/2dsb2JhbABZgwdSWIJspzAGmBoBGXAWdIImAQEEIxE6GwIBCBoCJgICAh8RFRACBAESiC4DEQ2yHZ5JDYYCEwSBKoQrhmeBYzqCdYFLAQOEXwKTJoF3jTqFc4M4gi8 X-IronPort-AV: E=Sophos;i="4.98,941,1392163200"; d="scan'208";a="48701383" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP; 30 May 2014 15:57:45 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s4UFvjlK026776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 May 2014 15:57:45 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Fri, 30 May 2014 10:57:44 -0500 From: "Joe Hildebrand (jhildebr)" To: Spencer Dawkins , "taps@ietf.org" Thread-Topic: [Taps] So, is this the -00 charter yet? Thread-Index: AQHPe5Sc/jue/Kq5GUeSg8bXP9PSQJtZN92A Date: Fri, 30 May 2014 15:57:43 +0000 Message-ID: References: <5387C0C1.3030909@gmail.com> In-Reply-To: <5387C0C1.3030909@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/nw7Ois0mz4WBwHFDs-RRs7vZr4w Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 15:57:51 -0000 T24gNS8yOS8xNCwgNToyMCBQTSwgIlNwZW5jZXIgRGF3a2lucyIgPHNwZW5jZXJkYXdraW5zLmll dGZAZ21haWwuY29tPg0Kd3JvdGU6DQoNCj5UaGUgZm9sa3Mgb24gdGhlIG1haWxpbmcgbGlzdCB3 aG8gaGF2ZSByZXNwb25kZWQgc28gZmFyLCBzZWVtIHRvIGJlDQo+Y29udmVyZ2luZyAuLi4NCj4N Cj5JcyANCj5odHRwczovL3NpdGVzLmdvb2dsZS5jb20vc2l0ZS90cmFuc3BvcnRwcm90b2NvbHNl cnZpY2VzL2NoYXJ0ZXItcHJvcG9zYWwNCj5zdGlsbCB0aGUgbW9zdCByZWNlbnQgY2hhcnRlciB2 ZXJzaW9uPw0KPg0KPklzIGl0IHRpbWUgdG8gZG8gYSBNYWlsaW5nIExpc3QgTGFzdCBDYWxsIGJl Zm9yZSBJIHB1dCB0aGUgY2hhcnRlcg0KPnByb3Bvc2FsIGZvcndhcmQgaW4gdGhlIGRhdGF0cmFj a2VyPyA6LSkNCg0KSSB3b3VsZCBzdWdnZXN0IG1vZGlmeWluZyAjMyB0byBhbGxvdyBmb3Igc3Vj Y2VzcyBvbiB0aGUgY2hhcnRlciBpZiB0aGUNCmV4cGVyaW1lbnRhbCBwcm90b2NvbCBpcyBvdmVy Y29tZSBieSBldmVudHMuICBJJ20gbm90IGNvbnZpbmNlZCwgZm9yDQpleGFtcGxlLCB0aGF0IHB1 Ymxpc2hpbmcgdGhhdCBwcm90b2NvbCBhcyBhbiBSRkMgd2lsbCBoYXZlIHZhbHVlIG92ZXINCnRo ZXJlIGJlaW5nIG11bHRpcGxlIEktRHMgd2l0aCBkaWZmZXJlbnQgaWRlYXMgdW50aWwgd2UgY29t ZSB1cCB3aXRoDQpzb21ldGhpbmcgc3RhbmRhcmRzLXRyYWNrLg0KDQotLSANCkpvZSBIaWxkZWJy YW5kDQoNCg0KDQo= From nobody Fri May 30 09:00:34 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A545B1A08EF for ; Fri, 30 May 2014 09:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCWDvIcm42Hb for ; Fri, 30 May 2014 09:00:28 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8D7D1A6F58 for ; Fri, 30 May 2014 09:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1092; q=dns/txt; s=iport; t=1401465624; x=1402675224; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=GZONSFpFjisxfqjJDLiuOTntjIeOmDBMr94PGL0J/fI=; b=eCMNiFQiyNwlDKMji0yB4FSu9/alrUA9i486A9AuiXOZGnpPL7CWRr3s aWQx3vYZqQlE9fNToE8zWRCducFkk6JlaNikTHuSuotdNIWv7h2EBEdQP goA0AZe/TtkTOfRu9Ja3uvKf+P32SAEsvj44s+bBZAXhCGAiddLZS0nhh E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4LAFKqiFOtJV2Z/2dsb2JhbABZgweBKoJspzAGmBoBGXAWdIImAQEEIxFVAgEIGgImAgICHxEVEAIEARKILgMRsiieSQ2GAheBKoQrhmeBYzqCdYFLAQOYB4F3jTqFc4M4gi8 X-IronPort-AV: E=Sophos;i="4.98,941,1392163200"; d="scan'208";a="326136262" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 30 May 2014 16:00:23 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s4UG0NuD024202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 May 2014 16:00:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Fri, 30 May 2014 11:00:23 -0500 From: "Joe Hildebrand (jhildebr)" To: Spencer Dawkins , "taps@ietf.org" Thread-Topic: [Taps] IETF journal article update - CHARTER Thread-Index: AQHPe5OlY8+dT8k2N0mb8+jRLcB485tZOJoA Date: Fri, 30 May 2014 16:00:22 +0000 Message-ID: References: <87B85695-441C-47F4-BE60-C05A4D54DF86@ifi.uio.no> <538498DE.20806@gmail.com> <1377AC0E-723A-4D48-BF51-4BA2517349EA@trammell.ch> <0E4C6DB1-E058-427D-87BD-DC2A22D3CFD8@ifi.uio.no> <724c3556024b80043f957c86637c819f.squirrel@www.erg.abdn.ac.uk> <5387BF2C.9010201@gmail.com> In-Reply-To: <5387BF2C.9010201@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: <5FDB2246CC022C4D896DF35580EBAF12@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/ZWT1DsWh_nFX9snBuwAfP0AwtUY Subject: Re: [Taps] IETF journal article update - CHARTER X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 16:00:33 -0000 T24gNS8yOS8xNCwgNToxMyBQTSwgIlNwZW5jZXIgRGF3a2lucyIgPHNwZW5jZXJkYXdraW5zLmll dGZAZ21haWwuY29tPg0Kd3JvdGU6DQoNCj5JIGJlbGlldmUgU3BlbmNlciB3YXMgZW5jb3VyYWdp bmcgQnJpYW4gKGFuZCBpdCB0dXJucyBvdXQgSSB3YXMgdXNpbmcNCj4iQnJpYW4iIGFzIGEgbXVs dGljYXN0IGFkZHJlc3MgdGhhdCBhbHNvIHJlc29sdmVzIHRvICJKb2UiLCBhbmQgYW55DQo+b3Ro ZXIgSUFCIG1lbWJlcnMgd2hvIGFyZSBsaXN0ZW5pbmcpIHRvIHRlbGwgdXMgaWYgdGhlIElBQiBp cyBsaWtlbHkgdG8NCj5oYXZlIGEgcmV2aXNlZCBwcm9ncmFtIHRoYXQgd2UgY291bGQgdXNlZnVs bHkgcmVmZXIgdG8gaW4gdGhlIGNoYXJ0ZXINCj5hbnkgdGltZSBzb29uLg0KDQpCcmlhbiBpcyBv ZmZsaW5lIGZvciBhIGNvdXBsZSBvZiBkYXlzLg0KDQo+VW5sZXNzIHRoZSBhbnN3ZXIgaXMgc29t ZSB2YXJpYW50IG9mICJ0aGUgSUFCIGp1c3QgYXBwcm92ZWQgYSByZWxldmFudA0KPnByb2dyYW0i LCBpdCdzIGZpbmUgdG8gbGVhdmUgdGhlIElBQiB1bm1lbnRpb25lZC4NCg0KV2UndmUgZ290IHNv bWUgZW1lcmdpbmcgY29uc2Vuc3VzIG9uIHRoZSBJQUIgb24gd2hhdCB0aGUgcmVsZXZhbnQgcHJv Z3JhbQ0Kd2lsbCBiZSwgYnV0IGFyZSBub3QgcXVpdGUgcmVhZHkgdG8gYW5ub3VuY2UgaXQgeWV0 LiAgSSBzdWdnZXN0IGxlYXZpbmcgYQ0KcGxhY2Vob2xkZXIgdGhhdCB3ZSdsbCBmaWxsIGluIGFz IHRoZSBwcm9jZXNzIHByb2dyZXNzZXMuDQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0KDQoNCg== From nobody Fri May 30 09:15:36 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A861B1A09C8 for ; Fri, 30 May 2014 09:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QM9QPsSsREBN for ; Fri, 30 May 2014 09:15:33 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id EC5B81A08F1 for ; Fri, 30 May 2014 09:15:32 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id B7C102B44C8; Fri, 30 May 2014 17:15:27 +0100 (BST) Received: from 2001:630:241:204:214:51ff:fe63:569f (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Fri, 30 May 2014 17:15:27 +0100 Message-ID: <05c46a173690f08b6f910b090ac974ec.squirrel@www.erg.abdn.ac.uk> In-Reply-To: References: <5387C0C1.3030909@gmail.com> Date: Fri, 30 May 2014 17:15:27 +0100 From: gorry@erg.abdn.ac.uk To: "Joe Hildebrand (jhildebr)" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/taps/2IieQi6ExJsmAOOptuQrWr3Ud8I Cc: Spencer Dawkins , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 16:15:34 -0000 I thought the discovery part the exciting goal of the Charter? I may have misunderstood, the suggested edit, so can you be clearer what you are saying - are you saying if the mechanism is accepted we could directly go to a PS? Gorry > On 5/29/14, 5:20 PM, "Spencer Dawkins" > wrote: > >>The folks on the mailing list who have responded so far, seem to be >>converging ... >> >>Is >>https://sites.google.com/site/transportprotocolservices/charter-proposal >>still the most recent charter version? >> >>Is it time to do a Mailing List Last Call before I put the charter >>proposal forward in the datatracker? :-) > > I would suggest modifying #3 to allow for success on the charter if the > experimental protocol is overcome by events. I'm not convinced, for > example, that publishing that protocol as an RFC will have value over > there being multiple I-Ds with different ideas until we come up with > something standards-track. > > -- > Joe Hildebrand > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Fri May 30 09:18:41 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366171A6EDA for ; Fri, 30 May 2014 09:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3_VuDmQvBlL for ; Fri, 30 May 2014 09:18:38 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 26B8D1A09FD for ; Fri, 30 May 2014 09:18:38 -0700 (PDT) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 629FA2B44C8; Fri, 30 May 2014 17:18:33 +0100 (BST) Received: from 2001:630:241:204:214:51ff:fe63:569f (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Fri, 30 May 2014 17:18:33 +0100 Message-ID: <87aeb0e0917a55f4b49960bb1cb6643f.squirrel@www.erg.abdn.ac.uk> In-Reply-To: References: <5387C0C1.3030909@gmail.com> <98F56371-A849-45FB-8148-28AACCDE04EC@ifi.uio.no> Date: Fri, 30 May 2014 17:18:33 +0100 From: gorry@erg.abdn.ac.uk To: "Joe Hildebrand (jhildebr)" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/taps/CPs0gmmBK3h2pUjJkJkIAezAo8I Cc: Aaron Falk , Spencer Dawkins , Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 16:18:39 -0000 I think that's a big change in what I have seen discussed on this list.. I'm really unclear about what you think doesn't exist in the set of transport specs? Gorry > On 5/30/14, 8:29 AM, "Aaron Falk" wrote: > >>My proposed wording change (which at least Gorry accepted) is not in the >>current draft. Repeating: >> >> >>Revise working group goal #2 to read "specify a set of transport services >>that end systems **implementing TAPS** need to provide and provide >>guidance on choosing among available mechanisms and protocols to obtain a >>given transport service." > > There's no protocol for TAPS yet, so nobody is going to "implement TAPS". > Suggested change: "end systems need to provide" -> "applications want to > use". > > -- > Joe Hildebrand > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > From nobody Fri May 30 09:24:38 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AE91A0991 for ; Fri, 30 May 2014 09:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjgzxcxID9Gm for ; Fri, 30 May 2014 09:24:36 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBDE21A08F1 for ; Fri, 30 May 2014 09:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1248; q=dns/txt; s=iport; t=1401467072; x=1402676672; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UrSdN+F/EBC/wzsmon8KjI0OMUnGNpT2jM+QNEYGxig=; b=XgXhWfIw9KSFhZLhrBER0jlIaKTBxO9jDk7S3u0Ui3jCZmBI83RSP6r5 e5y4DP905bYITgIrEcjTlOJzsDjA3iadInERJy83K6ywBg8vibuszcq9+ IpyT+1zwX/zq1XONXxjCFuQalaq7WtWzpie5OczpYPFYZC/sVzYCJ3I/7 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4LAEWviFOtJV2d/2dsb2JhbABZDoJ5gSqCbKcwBpgaARlwFnSCJgEBBCMRRRACAQgaAiYCAgIwFRACBA4FiEKyJaRXF4EqhCuISjMHgnWBSwEDmX6TLYJ4QIIv X-IronPort-AV: E=Sophos;i="4.98,942,1392163200"; d="scan'208";a="329238620" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 30 May 2014 16:24:31 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s4UGOVjZ002891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 May 2014 16:24:31 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Fri, 30 May 2014 11:24:31 -0500 From: "Joe Hildebrand (jhildebr)" To: "gorry@erg.abdn.ac.uk" Thread-Topic: [Taps] So, is this the -00 charter yet? Thread-Index: AQHPe5Sc/jue/Kq5GUeSg8bXP9PSQJtZN92AgABpiID//53yAA== Date: Fri, 30 May 2014 16:24:30 +0000 Message-ID: References: <5387C0C1.3030909@gmail.com> <05c46a173690f08b6f910b090ac974ec.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <05c46a173690f08b6f910b090ac974ec.squirrel@www.erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: <5B8A443C488C4A42A8C1B7C6A4369C83@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/z7j3v0WDWK8sLMk6nXj1JgCeFZQ Cc: Spencer Dawkins , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 16:24:37 -0000 T24gNS8zMC8xNCwgMTA6MTUgQU0sICJnb3JyeUBlcmcuYWJkbi5hYy51ayIgPGdvcnJ5QGVyZy5h YmRuLmFjLnVrPiB3cm90ZToNCg0KPkkgdGhvdWdodCB0aGUgZGlzY292ZXJ5IHBhcnQgdGhlIGV4 Y2l0aW5nIGdvYWwgb2YgdGhlIENoYXJ0ZXI/DQoNClllcy4gIEJ1dCwgeW91IGRvbid0IG5lZWQg YW4gUkZDIHRvIGRpc2NvdmVyIHRoaW5ncy4gIE9mdGVuIEktRHMgYXJlIGZpbmUNCmZvciB0aGF0 Lg0KDQo+SSBtYXkgaGF2ZSBtaXN1bmRlcnN0b29kLCB0aGUgc3VnZ2VzdGVkIGVkaXQsIHNvIGNh biB5b3UgYmUgY2xlYXJlciB3aGF0DQo+eW91IGFyZSBzYXlpbmcgLSBhcmUgeW91IHNheWluZyBp ZiB0aGUgbWVjaGFuaXNtIGlzIGFjY2VwdGVkIHdlIGNvdWxkDQo+ZGlyZWN0bHkgZ28gdG8gYSBQ Uz8NCg0KVGhhdCdzIG9uZSBwb3NzaWJpbGl0eS4gIFRoZXJlIGFyZSBzZXZlcmFsIG90aGVyIHJl YXNvbnMgeW91IG1pZ2h0IG5vdA0Kd2FudCB0byBwdWJsaXNoIHRoZSB3b3JrIGFzIGFuIFJGQyB3 aGVuIHRoZSB0aW1lIGNvbWVzLg0KDQpUaGUgYmlnZ2VzdCBpc3N1ZSwgaG93ZXZlciwgaXMgdGhh dCBhcyBmYXIgYXMgSSBrbm93LCB0aGVyZSBhcmUgbm8NCmNvbmNyZXRlIHByb3Bvc2FscyBmb3Ig d2hhdCB0aGF0IHByb3RvY29sIHdpbGwgbG9vayBsaWtlLiAgQXMgc3VjaCwNCmhpc3RvcnkgaW4g dGhlIElFVEYgc2hvd3MgdGhhdCB5b3VyIGNoYW5jZXMgb2YgZmFpbHVyZSBpbiB0aGUNCmRlc2ln bi1ieS1jb21taXR0ZWUgcHJvY2VzcyBhcmUgcXVpdGUgaGlnaC4NCg0KPGhhdCB0eXBlPSdJQUIn Pg0KSSdtIHRyeWluZyB0byBlbnN1cmUgdGhhdCB3ZSdyZSBub3Qgc2V0dGluZyBhIHdvcmtpbmcg Z3JvdXAgdXAgdG8gZmFpbC4NCjwvaGF0Pg0KDQotLSANCkpvZSBIaWxkZWJyYW5kDQoNCg0KDQo= From nobody Fri May 30 09:38:37 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE0D1A09AB for ; Fri, 30 May 2014 09:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4at7k8YbbkD for ; Fri, 30 May 2014 09:38:33 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A47491A09A9 for ; Fri, 30 May 2014 09:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1960; q=dns/txt; s=iport; t=1401467909; x=1402677509; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Vw4lcvRcROuFvZAkYQaBh8QanvLNoL4zHiD5DWbFaFw=; b=mrzuM7QqB1NMfKccjFmGoVMWOa89yfkxj7T8Re47hb4qRInz//XMr4g3 JyHGtkkhtjqk7Ids6rF5sdokSOMLqmickU0SpwSeDNjaNkGTN+qV+PNoc YbqLCtcFTpTZWB+kEMd6uWJP9qLhFOgbR0AYMdbAJfqSgNcdvT/tu0Niz 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8LAEWziFOtJA2J/2dsb2JhbABZDoJ5gSqCbKcwBpgaARlwFnSCJQEBAQMBIxFFBQsCAQgaAiYCAgIwFRACBA4FiDoIsjOkWBeBKoQriEozB4J1gUsBA5l+ky2CeECCLw X-IronPort-AV: E=Sophos;i="4.98,942,1392163200"; d="scan'208";a="48719232" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP; 30 May 2014 16:38:29 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s4UGcTYx017678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 May 2014 16:38:29 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Fri, 30 May 2014 11:38:28 -0500 From: "Joe Hildebrand (jhildebr)" To: "gorry@erg.abdn.ac.uk" Thread-Topic: [Taps] So, is this the -00 charter yet? Thread-Index: AQHPe5Sc/jue/Kq5GUeSg8bXP9PSQJtZBOsAgAB+1AD//7OGgIAAav2A//+g/YA= Date: Fri, 30 May 2014 16:38:28 +0000 Message-ID: References: <5387C0C1.3030909@gmail.com> <98F56371-A849-45FB-8148-28AACCDE04EC@ifi.uio.no> <87aeb0e0917a55f4b49960bb1cb6643f.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <87aeb0e0917a55f4b49960bb1cb6643f.squirrel@www.erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: <7347FAFAF4CDBA478A1F25754C4A55D6@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/OLrSaWYyosu_vJ5KtBtmfjmBR_Q Cc: Aaron Falk , Spencer Dawkins , Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 16:38:35 -0000 T24gNS8zMC8xNCwgMTA6MTggQU0sICJnb3JyeUBlcmcuYWJkbi5hYy51ayIgPGdvcnJ5QGVyZy5h YmRuLmFjLnVrPiB3cm90ZToNCg0KPiBJIHRoaW5rIHRoYXQncyBhIGJpZyBjaGFuZ2UgaW4gd2hh dCBJIGhhdmUgc2VlbiBkaXNjdXNzZWQgb24gdGhpcyBsaXN0Li4NCj5JJ20gcmVhbGx5IHVuY2xl YXIgYWJvdXQgd2hhdCB5b3UgdGhpbmsgZG9lc24ndCBleGlzdCBpbiB0aGUgc2V0IG9mDQo+dHJh bnNwb3J0IHNwZWNzPw0KDQpPbmUgdGhhdCBJIGNhbiBkZXBsb3kgaW4gZW5vdWdoIHBsYWNlcyB0 aGF0IGlzbid0IFRDUC4NCg0KLSBTQ1RQIGlzIGF3ZXNvbWUuICBJdCBoYXMgYWxsIG9mIHRoZSBm ZWF0dXJlcyBhbmQgdGhlIGNvcnJlc3BvbmRpbmcNCmNvbXBsZXhpdHkuICBJIHRoaW5rIHdlIGhh dmUgZXZpZGVuY2UgdGhhdCBpdCB3aWxsIG5ldmVyIGRlcGxveSBhdA0KSW50ZXJuZXQgc2NhbGUg ZXhjZXB0IHBlcmhhcHMgd2hlbiBlbmNhcHN1bGF0ZWQgaW4gVURQLg0KDQotIEhvd2V2ZXIsIFVE UCBpcyBibG9ja2VkIG9uIGEgZ29vZCBudW1iZXIgb2YgY29ycG9yYXRlIG5ldHdvcmtzLiAgVGhl DQpyZWFzb24gZ2l2ZW4gaXMgdGhhdCB0aGVyZSBpcyBubyBnb29kIHdheSB0byByZWFzb24gYWJv dXQgZGlyZWN0aW9uYWxpdHkNCm9yIHNlc3Npb24gbGVuZ3RoLiAgVGhlcmUgYXJlIGxpa2VseSBh IGZldyBvdGhlciBiaXRzIG5lZWRlZC4NCg0KLSBNeSByZWNlbnQgYW5hbHlzaXMgb2YgRFRMUyBz dWdnZXN0cyB0aGF0IGVuY2Fwc3VsYXRpbmcgU0NUUCBpbiBEVExTIG92ZXINClVEUCAoYXMgdGhl IFdlYlJUQyBmb2xrcyBhcmUgY3VycmVudGx5IGRvaW5nKSBpcyBub3QgbGlrZWx5IHRvIGFkZCBl bm91Z2gNCnNlc3Npb24gc2VtYW50aWNzIHRvIGdldCBwYXN0IHRoaXMgZGVwbG95bWVudCBpc3N1 ZS4NCg0KLSBOZXcgbGF5ZXIgNCBwcm90b2NvbHMgYXJlIHVubGlrZWx5IHRvIGRvIGJldHRlciB0 aGFuIFNDVFAgaW4gdGVybXMgb2YNCmRlcGxveW1lbnQuICBUaGVyZSBhcmUgbm93IHRvbyBtYW55 IG9sZCBrZXJuZWxzIGFuZCBtaWRkbGVib3hlcyB0aGF0IGtub3cNCm9ubHkgVURQIGFuZCBUQ1Ag dGhhdCB3ZSdyZSB1bmxpa2VseSB0byBldmVyIG1ha2Ugc2lnbmlmaWNhbnQgcHJvZ3Jlc3MNCnVu bGVzcyB3ZSBtaWdyYXRlIGlubm92YXRpb24gaW50byB1bnByaXZpbGVnZWQgdXNlcnNwYWNlLg0K DQpJdCBtYXkgYmUgdGhhdCBvbmUgcG9zc2liaWxpdHkgd291bGQgYmUgdG8gZG8gYSByZWFsIGxh eWVyIDUgcHJvdG9jb2wgb3Zlcg0KVURQLCBhbmQgbW92ZSB0cmFuc3BvcnQtbGlrZSBpbm5vdmF0 aW9uIGFib3ZlIHRoYXQuICBJZiB3ZSBkaWQgYSBwcm90b2NvbA0KbGlrZSB0aGF0LCB3b3VsZCBp dCBzYXRpc2Z5IHRoZSBjdXJyZW50IGNoYXJ0ZXI/DQoNCi0tIA0KSm9lIEhpbGRlYnJhbmQNCg0K DQoNCg== From nobody Fri May 30 09:44:00 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193131A6EDA for ; Fri, 30 May 2014 09:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 094m-1Mkc8hA for ; Fri, 30 May 2014 09:43:48 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6651F1A09A9 for ; Fri, 30 May 2014 09:43:48 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id DE78B2B454C; Fri, 30 May 2014 17:43:43 +0100 (BST) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 3064F2B44C8; Fri, 30 May 2014 17:43:42 +0100 (BST) Message-ID: <5388B53D.1000406@erg.abdn.ac.uk> Date: Fri, 30 May 2014 17:43:41 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" References: <5387C0C1.3030909@gmail.com> <05c46a173690f08b6f910b090ac974ec.squirrel@www.erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/hNWFKNQS0O4GIuU5WKwld7GTEdo Cc: Spencer Dawkins , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 16:43:53 -0000 On 30/05/2014 17:24, Joe Hildebrand (jhildebr) wrote: > On 5/30/14, 10:15 AM, "gorry@erg.abdn.ac.uk" wrote: > >> I thought the discovery part the exciting goal of the Charter? > > Yes. But, you don't need an RFC to discover things. Often I-Ds are fine > for that. > I don't agree - implementing discovery mechanisms for enhanced interop of existing transport protocols based on unpublished IDs seems rather crazy to me. I can't believe the transport area has to limit the number of RFCs to such an extent that a WG can't publish a spec for people to implement techniques - albeit Experimental in status until widespread deployment (if the bar for PS is set that high - as it often is in TSV). >> I may have misunderstood, the suggested edit, so can you be clearer what >> you are saying - are you saying if the mechanism is accepted we could >> directly go to a PS? > > That's one possibility. There are several other reasons you might not > want to publish the work as an RFC when the time comes. > I can believe this for any charter item, but I don't see the argument against this line? > The biggest issue, however, is that as far as I know, there are no > concrete proposals for what that protocol will look like. As such, > history in the IETF shows that your chances of failure in the > design-by-committee process are quite high. > > > I'm trying to ensure that we're not setting a working group up to fail. > > Maybe I am hearing you wrong: My problem is that I'd argue that you are failing the WG before it starts, by somehow saying you can do the analysis and setup the stack, but that the group won't publish the networking specs that allow it to be used across a path to another system? Or are you saying the group shouldn't be chartered until it has a candidate solution for this? - Either way I think either I or you may be confused. Gorry From nobody Fri May 30 09:46:15 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27061A6EDA for ; Fri, 30 May 2014 09:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHA84nCr1YPT for ; Fri, 30 May 2014 09:46:11 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D15661A09A5 for ; Fri, 30 May 2014 09:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=998; q=dns/txt; s=iport; t=1401468366; x=1402677966; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=68XQ/D+QYnyj+ovFGyeC0U+WasAFWReeBy7Os4VBNbA=; b=S+lYhd3eRko7bedwlpwvJdzkSV6FTxgulcsvyzzEZkdTauJb5XvUaHix pQTnHAMKOozsznu/2tSBqmbOkHXHnzu8zWGGBV3QtVNHJNrjKJhRzoYim xXzrG5ne1ASjmeMqyAebmWH+o/yRSAx0FnaR51rl6oOLbaA7LszHU+Pqt k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8LAGa0iFOtJA2K/2dsb2JhbABZDoJ5gSqCbKcwBpgaARlwFnSCJgEBBCMRRRACAQgaAiYCAgIwFRACBA4FG4gnsjWkWReBKoQriH0HgnWBSwEDmX6TLYJ4QIIv X-IronPort-AV: E=Sophos;i="4.98,942,1392163200"; d="scan'208";a="329190699" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP; 30 May 2014 16:46:06 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s4UGk6Wl029511 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 30 May 2014 16:46:06 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Fri, 30 May 2014 11:46:06 -0500 From: "Joe Hildebrand (jhildebr)" To: "gorry@erg.abdn.ac.uk" Thread-Topic: [Taps] So, is this the -00 charter yet? Thread-Index: AQHPe5Sc/jue/Kq5GUeSg8bXP9PSQJtZN92AgABpiID//53yAIAAafGA//+cGAA= Date: Fri, 30 May 2014 16:46:05 +0000 Message-ID: References: <5387C0C1.3030909@gmail.com> <05c46a173690f08b6f910b090ac974ec.squirrel@www.erg.abdn.ac.uk> <5388B53D.1000406@erg.abdn.ac.uk> In-Reply-To: <5388B53D.1000406@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [10.129.24.156] Content-Type: text/plain; charset="utf-8" Content-ID: <3D4BB9A4D66E9E469B590485B62C607B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/7Xk2e0pQr4NH_IPQcaq3AmEu0NI Cc: Spencer Dawkins , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 16:46:12 -0000 T24gNS8zMC8xNCwgMTA6NDMgQU0sICJHb3JyeSBGYWlyaHVyc3QiIDxnb3JyeUBlcmcuYWJkbi5h Yy51az4gd3JvdGU6DQoNCj5NYXliZSBJIGFtIGhlYXJpbmcgeW91IHdyb25nOiBNeSBwcm9ibGVt IGlzIHRoYXQgSSdkIGFyZ3VlIHRoYXQgeW91IGFyZQ0KPmZhaWxpbmcgdGhlIFdHIGJlZm9yZSBp dCBzdGFydHMsIGJ5IHNvbWVob3cgc2F5aW5nIHlvdSBjYW4gZG8gdGhlDQo+YW5hbHlzaXMgYW5k IHNldHVwIHRoZSBzdGFjaywgYnV0IHRoYXQgdGhlIGdyb3VwIHdvbid0IHB1Ymxpc2ggdGhlDQo+ bmV0d29ya2luZyBzcGVjcyB0aGF0IGFsbG93IGl0IHRvIGJlIHVzZWQgYWNyb3NzIGEgcGF0aCB0 byBhbm90aGVyDQo+c3lzdGVtPyBPciBhcmUgeW91IHNheWluZyB0aGUgZ3JvdXAgc2hvdWxkbid0 IGJlIGNoYXJ0ZXJlZCB1bnRpbCBpdCBoYXMNCj5hIGNhbmRpZGF0ZSBzb2x1dGlvbiBmb3IgdGhp cz8gLSBFaXRoZXIgd2F5IEkgdGhpbmsgZWl0aGVyIEkgb3IgeW91IG1heQ0KPmJlIGNvbmZ1c2Vk Lg0KDQpObywgSSdtIHN1Z2dlc3RpbmcgdGhlIGdyb3VwIHJlY2hhcnRlciB3aGVuIGl0IGhhcyBh IGNhbmRpZGF0ZSBzb2x1dGlvbi4NClJlY2hhcnRlcmluZyBpcyByZWxhdGl2ZWx5IGVhc3ksIHBh cnRpY3VsYXJseSBpZiB5b3UncmUgc2hvd2luZyBzaWducyBvZg0Kc3VjY2VzcyBvbiB0aGUgZXhp c3RpbmcgY2hhcnRlci4NCg0KLS0gDQpKb2UgSGlsZGVicmFuZA0KDQoNCg0K From nobody Fri May 30 10:27:15 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214271A0A0F for ; Fri, 30 May 2014 10:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fj2WrKJsL5yD for ; Fri, 30 May 2014 10:27:11 -0700 (PDT) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 205651A03C6 for ; Fri, 30 May 2014 10:27:09 -0700 (PDT) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 7DECA2B4555; Fri, 30 May 2014 18:27:04 +0100 (BST) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id CF3352B4520; Fri, 30 May 2014 18:27:01 +0100 (BST) Message-ID: <5388BF65.9020506@erg.abdn.ac.uk> Date: Fri, 30 May 2014 18:27:01 +0100 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" References: <5387C0C1.3030909@gmail.com> <98F56371-A849-45FB-8148-28AACCDE04EC@ifi.uio.no> <87aeb0e0917a55f4b49960bb1cb6643f.squirrel@www.erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/6gXASHI-ni8CRRaoWROJqfhe8R4 Cc: Aaron Falk , Spencer Dawkins , Michael Welzl , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 17:27:13 -0000 On 30/05/2014 17:38, Joe Hildebrand (jhildebr) wrote: > On 5/30/14, 10:18 AM, "gorry@erg.abdn.ac.uk" wrote: > >> I think that's a big change in what I have seen discussed on this list.. >> I'm really unclear about what you think doesn't exist in the set of >> transport specs? > > One that I can deploy in enough places that isn't TCP. > > - SCTP is awesome. It has all of the features and the corresponding > complexity. I think we have evidence that it will never deploy at > Internet scale except perhaps when encapsulated in UDP. > > - However, UDP is blocked on a good number of corporate networks. The > reason given is that there is no good way to reason about directionality > or session length. There are likely a few other bits needed. > > - My recent analysis of DTLS suggests that encapsulating SCTP in DTLS over > UDP (as the WebRTC folks are currently doing) is not likely to add enough > session semantics to get past this deployment issue. > > - New layer 4 protocols are unlikely to do better than SCTP in terms of > deployment. There are now too many old kernels and middleboxes that know > only UDP and TCP that we're unlikely to ever make significant progress > unless we migrate innovation into unprivileged userspace. > > It may be that one possibility would be to do a real layer 5 protocol over > UDP, and move transport-like innovation above that. If we did a protocol > like that, would it satisfy the current charter? > On the last point - I'm not going to comment on the issues with your proposed approach - because that's a different topic. I don't recall this being brought up at the BOF at all, and I personally don't see that as the initial goal of this group. Others may feel completely different though, I'll let them comment. I still don't get your point: Are you saying that you think the WG needs to recharter before it designs a *NEW* transport protocol working over UDP? - I'd agree to that. Designing a new protocol over UDP is a serious task. You seem to suggest the "new protocol" is going to magically work where for instance SCTP/UDP was doomed never to work. I don't buy the argument you can make a magic protocol that all middlebox vendors will love. An interesting debate, and I think your analysis is really interesting - but surely one to be started in the IRTF? So what technical reason do we have for not allowing the group to look at mechanisms and find solutions that can be published in the RFC series? Gorry From nobody Fri May 30 11:31:12 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186621A0452 for ; Fri, 30 May 2014 11:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PuVlssuXU39 for ; Fri, 30 May 2014 11:31:08 -0700 (PDT) Received: from mail-out2.uio.no (mail-out2.uio.no [IPv6:2001:700:100:10::58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A5321A043F for ; Fri, 30 May 2014 11:31:08 -0700 (PDT) Received: from mail-mx6.uio.no ([129.240.10.40]) by mail-out2.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WqRa0-0005E3-1n; Fri, 30 May 2014 20:31:00 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx6.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80.1) (envelope-from ) id 1WqRZz-0000dc-8c; Fri, 30 May 2014 20:30:59 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: Date: Fri, 30 May 2014 20:30:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5387C0C1.3030909@gmail.com> <98F56371-A849-45FB-8148-28AACCDE04EC@ifi.uio.no> <87aeb0e0917a55f4b49960bb1cb6643f.squirrel@www.erg.abdn.ac.uk> To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 2 sum rcpts/h 8 sum msgs/h 2 total rcpts 17010 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: C9ADBDB43FA367C8141D4022A4F2DBEEC150748C X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 1522 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/vgSE4m2InirVgsDgJZDnjDrZPAo Cc: "gorry@erg.abdn.ac.uk \(erg\)" , Aaron Falk , Spencer Dawkins , "taps@ietf.org" Subject: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 18:31:11 -0000 Hi, On 30. mai 2014, at 18:38, Joe Hildebrand (jhildebr) = wrote: > On 5/30/14, 10:18 AM, "gorry@erg.abdn.ac.uk" = wrote: >=20 >> I think that's a big change in what I have seen discussed on this = list.. >> I'm really unclear about what you think doesn't exist in the set of >> transport specs? >=20 > One that I can deploy in enough places that isn't TCP. >=20 > - SCTP is awesome. It has all of the features and the corresponding > complexity. I think we have evidence that it will never deploy at > Internet scale except perhaps when encapsulated in UDP. >=20 > - However, UDP is blocked on a good number of corporate networks. The > reason given is that there is no good way to reason about = directionality > or session length. There are likely a few other bits needed. >=20 > - My recent analysis of DTLS suggests that encapsulating SCTP in DTLS = over > UDP (as the WebRTC folks are currently doing) is not likely to add = enough > session semantics to get past this deployment issue. >=20 > - New layer 4 protocols are unlikely to do better than SCTP in terms = of > deployment. There are now too many old kernels and middleboxes that = know > only UDP and TCP that we're unlikely to ever make significant progress > unless we migrate innovation into unprivileged userspace. So - what you write here reflects one line of thinking. I come from an = entirely different line of thinking: the IETF is ultra-conservative in = what it supports because everything has to work *across the whole = Internet*. There may well be many, many paths out there that support a = great deal of the things you mention below - and many won't. You = shouldn't have to worry about a non-supportive path if you're on a = supportive path! The Internet has, however, never been good with = downward-compatibility: *trying* things, and using something else = otherwise. Now, why is that? Because we bind applications to protocols with a thick = rope, and thus an application programmer has to implement all the logic = of trying e.g. "native SCTP, oh, doesn't work, what about SCTP/UDP? oh, = doesn't work either, ok, TCP then" - which, of course, noone does. It's = just too much work - the pain vs. gain trade-off isn't right for the app = programmer. If we stop binding applications to protocols, the machinery = underneath could be trying protocol #1 and falling back to protocol #2 = etc. In a **best effort** world (and that was the point of my = presentation at the IAB workshop on Internet Technology Adoption and = Transition), that's not a problem for many of the services - you just = end up with a less efficient implementation: unordered delivery =3D> = fine to get it in order. Special type of congestion control =3D> not = cool but okay if you get AIMD instead. Partial reliability =3D> well = full reliability isn't as performant, but your application won't break = if it assumes best effort. And so forth! Why isn't this happening today, given that apps aren't necessarily using = the socket interface? As Brian mentioned in one of his recent emails, that's not quite true - = middleware developers are using the socket interface. Their thinking is guided by what this interface gives them today: TCP, = UDP. If one was to build a better middleware (which could well help = applications - see draft-hurtig-tsvwg-transport-apis-00 for some = reasoning), where would we start? With identifying the services that = protocols provide today. > It may be that one possibility would be to do a real layer 5 protocol = over > UDP, and move transport-like innovation above that. If we did a = protocol > like that, would it satisfy the current charter? I'll call this one possibility #2 and throw a third possibility on the = table to make this open enough: Minion. You make everything look like = TCP on the wire. For all three possibilities, it's a useful starting point to identify = all the services provided by today's protocols (charter item #1) - after = all, even if you were to build everything yourself, these services are = in there for a reason. There was preceding IETF debate. This doesn't = mean that your possibility #2 needs to implement all of them, but surely = knowing which ones are now a part of the protocols is useful for = guidance. For all three possibilities, it's useful to have a narrower set of = services that really should be made available The third part, discovery, isn't useful for possibility #2 and #3. Well = okay. It still is useful for possibility #1 which is what I propose and = what the group has pretty much been about. Cheers, Michael From nobody Fri May 30 11:49:16 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77CF1A018F for ; Fri, 30 May 2014 11:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Akp75eB6tHaI for ; Fri, 30 May 2014 11:49:12 -0700 (PDT) Received: from mail-out1.uio.no (mail-out1.uio.no [IPv6:2001:700:100:10::57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59DBB1A0164 for ; Fri, 30 May 2014 11:49:12 -0700 (PDT) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out1.uio.no with esmtp (Exim 4.75) (envelope-from ) id 1WqRrU-0001uc-Jf; Fri, 30 May 2014 20:49:04 +0200 Received: from 59.115.34.95.customer.cdi.no ([95.34.115.59] helo=[192.168.0.114]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from ) id 1WqRrT-0008IU-Qu; Fri, 30 May 2014 20:49:04 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Michael Welzl In-Reply-To: Date: Fri, 30 May 2014 20:49:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <37F174AA-588E-469D-9A37-58A769C16352@ifi.uio.no> References: <5387C0C1.3030909@gmail.com> <98F56371-A849-45FB-8148-28AACCDE04EC@ifi.uio.no> <87aeb0e0917a55f4b49960bb1cb6643f.squirrel@www.erg.abdn.ac.uk> To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1878.2) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 11 msgs/h 3 sum rcpts/h 13 sum msgs/h 3 total rcpts 17015 max rcpts/h 44 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: A6EB15A243FD1FE5FBF74BD86663429B54EADC6E X-UiO-SPAM-Test: remote_host: 95.34.115.59 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 1523 max/h 14 blacklist 0 greylist 0 ratelimit 0 Archived-At: http://mailarchive.ietf.org/arch/msg/taps/IQIQOczNhvqvK44gIRI2NeAKHsk Cc: "gorry@erg.abdn.ac.uk \(erg\)" , Aaron Falk , Spencer Dawkins , "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 18:49:15 -0000 ... I forgot to include a point which is important to the argument: why is e.g. native SCTP not supported much? at least one good reason not to support it is: noone uses it (except for = telephony signaling). why isn't anyone using it? see below. Without such a "try, else fall-back" scheme (which is what we'd specify = in item 3 of the charter), SCTP/UDP isn't going to be deployed either, = except for special cases in special ways (rtcweb). I'd argue it's even = less about the encapsulation and more about making the protocol easy and = robust to use.=20 Cheers, Michael On 30. mai 2014, at 20:30, Michael Welzl wrote: > Hi, >=20 > On 30. mai 2014, at 18:38, Joe Hildebrand (jhildebr) = wrote: >=20 >> On 5/30/14, 10:18 AM, "gorry@erg.abdn.ac.uk" = wrote: >>=20 >>> I think that's a big change in what I have seen discussed on this = list.. >>> I'm really unclear about what you think doesn't exist in the set of >>> transport specs? >>=20 >> One that I can deploy in enough places that isn't TCP. >>=20 >> - SCTP is awesome. It has all of the features and the corresponding >> complexity. I think we have evidence that it will never deploy at >> Internet scale except perhaps when encapsulated in UDP. >>=20 >> - However, UDP is blocked on a good number of corporate networks. = The >> reason given is that there is no good way to reason about = directionality >> or session length. There are likely a few other bits needed. >>=20 >> - My recent analysis of DTLS suggests that encapsulating SCTP in DTLS = over >> UDP (as the WebRTC folks are currently doing) is not likely to add = enough >> session semantics to get past this deployment issue. >>=20 >> - New layer 4 protocols are unlikely to do better than SCTP in terms = of >> deployment. There are now too many old kernels and middleboxes that = know >> only UDP and TCP that we're unlikely to ever make significant = progress >> unless we migrate innovation into unprivileged userspace. >=20 >=20 > So - what you write here reflects one line of thinking. I come from an = entirely different line of thinking: the IETF is ultra-conservative in = what it supports because everything has to work *across the whole = Internet*. There may well be many, many paths out there that support a = great deal of the things you mention below - and many won't. You = shouldn't have to worry about a non-supportive path if you're on a = supportive path! The Internet has, however, never been good with = downward-compatibility: *trying* things, and using something else = otherwise. >=20 > Now, why is that? Because we bind applications to protocols with a = thick rope, and thus an application programmer has to implement all the = logic of trying e.g. "native SCTP, oh, doesn't work, what about = SCTP/UDP? oh, doesn't work either, ok, TCP then" - which, of course, = noone does. It's just too much work - the pain vs. gain trade-off isn't = right for the app programmer. If we stop binding applications to = protocols, the machinery underneath could be trying protocol #1 and = falling back to protocol #2 etc. In a **best effort** world (and that = was the point of my presentation at the IAB workshop on Internet = Technology Adoption and Transition), that's not a problem for many of = the services - you just end up with a less efficient implementation: = unordered delivery =3D> fine to get it in order. Special type of = congestion control =3D> not cool but okay if you get AIMD instead. = Partial reliability =3D> well full reliability isn't as performant, but = your application won't break if it assumes best e > ffort. And so forth! >=20 > Why isn't this happening today, given that apps aren't necessarily = using the socket interface? >=20 > As Brian mentioned in one of his recent emails, that's not quite true = - middleware developers are using the socket interface. > Their thinking is guided by what this interface gives them today: TCP, = UDP. If one was to build a better middleware (which could well help = applications - see draft-hurtig-tsvwg-transport-apis-00 for some = reasoning), where would we start? With identifying the services that = protocols provide today. >=20 >=20 >> It may be that one possibility would be to do a real layer 5 protocol = over >> UDP, and move transport-like innovation above that. If we did a = protocol >> like that, would it satisfy the current charter? >=20 > I'll call this one possibility #2 and throw a third possibility on the = table to make this open enough: Minion. You make everything look like = TCP on the wire. >=20 > For all three possibilities, it's a useful starting point to identify = all the services provided by today's protocols (charter item #1) - after = all, even if you were to build everything yourself, these services are = in there for a reason. There was preceding IETF debate. This doesn't = mean that your possibility #2 needs to implement all of them, but surely = knowing which ones are now a part of the protocols is useful for = guidance. >=20 > For all three possibilities, it's useful to have a narrower set of = services that really should be made available >=20 > The third part, discovery, isn't useful for possibility #2 and #3. = Well okay. It still is useful for possibility #1 which is what I propose = and what the group has pretty much been about. >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri May 30 14:47:12 2014 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538921A8872 for ; Fri, 30 May 2014 14:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_3yNV3OQBBi for ; Fri, 30 May 2014 14:47:10 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ADD81A886F for ; Fri, 30 May 2014 14:47:09 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id l6so2478583oag.4 for ; Fri, 30 May 2014 14:47:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=U++n48LxrYF3Yn6v1oMKtrb7Muy/uI5ZqmCOXIs46FY=; b=Td/ZAwckasl0IB4wYf8eX2/Btr4TCLFhUAJJS0+1/scAXSoewjL/i+R5rAwfYEw7+S NTsMUfol/W/Cv9nisXGbdnuGHgHkptgygfF3nEYMe00VA/bZlH/bnLNEmSKXvkAEcAII kJ0MSADIMpP3rZgX6tH82whsL4StDRJlLfpEzUeinCHhdV38ROBoob1TBh9lkMe9foSz z9B66PhNm9SnZqAg6D/GzfTNF8G7/SbK6cLI2ZbA3FPGWWBhOpFMjDfWuBE0cVgrpECN tXzzpygS6wyDTjCMsNOPtti0rwylT+ZamV1TaX9sE6+5KMFh4stNOPpO+jZmhraPviFt ZxVw== X-Received: by 10.60.161.6 with SMTP id xo6mr20715946oeb.78.1401486425496; Fri, 30 May 2014 14:47:05 -0700 (PDT) Received: from [192.168.0.13] (cpe-76-187-7-89.tx.res.rr.com. [76.187.7.89]) by mx.google.com with ESMTPSA id tz6sm9273283obc.10.2014.05.30.14.47.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 May 2014 14:47:05 -0700 (PDT) Message-ID: <5388FC56.6000705@gmail.com> Date: Fri, 30 May 2014 16:47:02 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" , "gorry@erg.abdn.ac.uk" References: <5387C0C1.3030909@gmail.com> <05c46a173690f08b6f910b090ac974ec.squirrel@www.erg.abdn.ac.uk> <5388B53D.1000406@erg.abdn.ac.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/taps/nARDI-rjSYBm816NymKaDHFokH0 Cc: "taps@ietf.org" Subject: Re: [Taps] So, is this the -00 charter yet? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 21:47:11 -0000 On 05/30/2014 11:46 AM, Joe Hildebrand (jhildebr) wrote: > On 5/30/14, 10:43 AM, "Gorry Fairhurst" wrote: > >> Maybe I am hearing you wrong: My problem is that I'd argue that you are >> failing the WG before it starts, by somehow saying you can do the >> analysis and setup the stack, but that the group won't publish the >> networking specs that allow it to be used across a path to another >> system? Or are you saying the group shouldn't be chartered until it has >> a candidate solution for this? - Either way I think either I or you may >> be confused. > No, I'm suggesting the group recharter when it has a candidate solution. > Rechartering is relatively easy, particularly if you're showing signs of > success on the existing charter. Hi, Joe et al. So I'm not quite visualizing the proposal. Even rough text would help. Guessing in anticipation of text arriving ... is the idea that the working group to be would develop however many proposals as seem useful, and then IF one is blindingly obvious as the right thing to do THEN publish as PS ELSE IF people are willing to "experiment" with drafts THEN experiment, and publish what works as PS ELSE publish one or more Experimental RFCs and let 100 implementations bloom? Or, if not, could you clue me in? Thanks, Spencer, who is quite pleased with the discussion so far