From nobody Tue May 10 06:51:17 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C2A12D17C; Tue, 10 May 2016 06:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqH0RdamyIjQ; Tue, 10 May 2016 06:51:05 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D57D12D6CA; Tue, 10 May 2016 06:51:02 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id f66so16500138vkh.2; Tue, 10 May 2016 06:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc; bh=COeMMyxZK6xzlu68oedZBuY8Hyv0oBCVpPj0VK8E3CI=; b=V+eOgSuwvtQLwaHDpkUBVii8AlNFqLO/RV6BDfBcMjmJxEL+7E8KbaFVTi+NkfWyfJ xOREEuJ36C0/5KHwtSUPICoiR7ThZfCTNONPuT7elJA7sizk1nGJ3NostlIu0sBw/TzA GSOgA4R7CVKXF21yFGlSu6C3cHCEKdfxpl9wR7xIpukWi94yHWAaItO/7/bOi6stbe6y cqid32csIBFqGoKSwdExh230ziT0OWBf3TH09yL5CuoHYQU97kTZyO+2KMZgEX7VULSt XEWfJZFzpZGSf5Gz+mOkLduZh5lcV3adlqvOB3nbujA59E0PbS8k+DZuImURMs1BoQLu aIlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=COeMMyxZK6xzlu68oedZBuY8Hyv0oBCVpPj0VK8E3CI=; b=N3QalvnWs5QZ/qzj6Plhgvx1nKUy+t9PuMEPxeqBK0A9Pok7UnGwbiSskWgRpZ+7d4 4pez+Z05jgH4Kj/JVWPkrNgAC3XSzTwkmIawOfFK/S0TpA1DGCcJE3hYXI47XG/1Pn3l 5f8A+dV9CUphFkPRPsYr/jA2WjrCYog7FB6sCWosMNZo7giMEoMFHvRxt/kq0f1HrnPj 4cndC0mO959ufiRliwCFj5e5tZlUMKqXeEB/PdjwLJUEmYvUmKCiODPp+Us9tnVYMczJ DG7B/hOmqp6PEb1VKsle//ptNWHWTam2ExnYmMCgKHQU5b5g51s/yR7x5TzHaGDq8pqb GOgw== X-Gm-Message-State: AOPr4FXzfSj3EWwas+Yk1W2fOQyLMIgVgOX3vwBf7jtWEbo2dL5ZvnhN0IBdNKbGlAZw8CUklDEDWPaiA4Pckw== MIME-Version: 1.0 X-Received: by 10.31.98.135 with SMTP id w129mr8793192vkb.106.1462888261130; Tue, 10 May 2016 06:51:01 -0700 (PDT) Received: by 10.31.98.195 with HTTP; Tue, 10 May 2016 06:51:01 -0700 (PDT) Date: Tue, 10 May 2016 15:51:01 +0200 Message-ID: From: Naeem Khademi To: Uta@ietf.org, tls@ietf.org Content-Type: multipart/alternative; boundary=94eb2c094e6826a71505327d37f3 Archived-At: Cc: taps@ietf.org Subject: [Taps] Minimal API for the basic (D)TLS operation? (concerns draft-ietf-taps-transports-usage) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 13:51:10 -0000 --94eb2c094e6826a71505327d37f3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi I am writing this as one of the authors of the draft-ietf-taps-transports-usage and as a result of our WG discussions during the TAPS meeting in Buenos Aires. This draft tries to derive a list of transport service features and primitives (function-calls) provided by the transport protocols to the application. This is an initial milestone for building a TAPS system. It proposes a 3-pass process as a systematic way to derive the primitives and transport service features based on the IETF-based (abstract) APIs of transport protocols that are currently covered by the draft. - The draft can be found here (currently covering TCP and SCTP only): https://tools.ietf.org/html/draft-ietf-taps-transports-usage-00 - A companion draft covering UDP/UDP-Lite (to be merged with above draft eventually): https://tools.ietf.org/html/draft-fairhurst-taps-transports-usage-udp-01 The WG=E2=80=99s plan is to have (D)TLS included, initially as an independe= nt draft which applies the same exact process (Appendix B of draft-ietf-taps-transports-usage-00) and eventually merging into our draft as it matures. However we have some questions with regards to this: *A) Is there a definition of minimal API available that covers the basic operation? B) If not, is there enough energy in the WG(s) (UTA, TLS) to define such an API? * To clarify: we would like to make our lives easier by being able to just say that (D)TLS can run OVER our TAPS system - but then it may make sense to layer (D)TLS under a transport that we would base the TAPS system on, so this is why things get a bit more complicated here. Cheers, Naeem --94eb2c094e6826a71505327d37f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi=C2=A0

I am writing this as one = of the authors of the draft-ietf-taps-transports-usage and as a result of o= ur WG discussions during the TAPS meeting in Buenos Aires. This draft tries= to derive a list of transport service features and primitives (function-ca= lls) provided by the transport protocols to the application. This is an ini= tial milestone for building a TAPS system. It proposes a 3-pass process as = a systematic way to derive the primitives and transport service features ba= sed on the IETF-based (abstract) APIs of transport protocols that are curre= ntly covered by the draft.=C2=A0
The WG=E2=80=99s plan is to have (D)TLS included, initial= ly as an independent draft which applies the same exact process (Appendix B= of draft-ietf-taps-transports-usage-00) and eventually merging into our dr= aft as it matures. However we have some questions with regards to this:=C2= =A0

<= span style=3D"color:rgb(0,0,0);font-family:Helvetica;font-size:12px">A) Is = there a definition of minimal API available that covers the basic ope= ration?=C2=A0

B) If not, is there enough energy in the WG(s) (UTA, TLS) to define= such an API?=C2=A0

To clarify: we would like to make our lives easier by being able= to just say that (D)TLS can run OVER our TAPS system - but then it may mak= e sense to layer (D)TLS under a transport that we would base the TAPS syste= m on, so this is why things get a bit more complicated here.

Cheers,
Naeem
--94eb2c094e6826a71505327d37f3-- From nobody Tue May 24 11:00:37 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55ED412D13A for ; Tue, 24 May 2016 11:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UD2cmeBmZvvO for ; Tue, 24 May 2016 11:00:33 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D7D12D141 for ; Tue, 24 May 2016 11:00:32 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id f66so32484121vkh.2 for ; Tue, 24 May 2016 11:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=QvjpGb+9WUpRPUgYek2XWEOOqHMukEtCBohHmqG4saQ=; b=OtN7ihaNIUeJXvx9baRmrbZAD0fS/nsP8zmkfU1/vSMmrEWZiPjsnK7/N8xyd7NQWa cchCcYGdYfYFCj/OtV36lzmf7lSAViTKrV4mVivAtPTvGC/HzGsx2p6mP4LlNpGwrpph DU4vpcXoUtJZdJkJ80HjrxipE6IFL7xZq6dqHiJ99mweDiIHRe0x4Yf5GGdvWdxquMHV Q+yEdoiHrMlGzQYYccjuR3xC2+gXXSGcy7n0zZeLiPF8RYLaFbnBgWPRjrdZCg/sErIx LQuZ08pYOqOh1ux2rFDBFfpcXM+ua6x5hDJoLnuhgx+z9C1fitqE2eWmcVzVhPaorqwl geHQ== 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; bh=QvjpGb+9WUpRPUgYek2XWEOOqHMukEtCBohHmqG4saQ=; b=iqEUKxdEnNC7/rKzVZzXNoErh0MAHCU4QiT05tJMnLW1jjsU4C+9d/0v2LP7UJPPUn MZP36cZ/4RhSuG1I5sYEoFuTSGxGh8emAtdumSO4ZQbSmEHCJID/cHsqNsy33fbKYnp/ RP3GuaCG9K8d3UY+f+9QF8BnhBZ+TIdt2LMvILN7YeaXPwNZMJI4TcK0XL5PT1pTGWQm jeqUAh3EGxP/Ei4O6Qn6jkfRnCj/FWQwT3HutyD9Mv2TG7VbfWVoMZckjZi/WvVBh0OR UD6Naw6ZdvsadTbHwxTHo4W8PWPCuawsNB9KiG6EdUv3myCXtgcrvGs7rLJft14MrsPm xPcw== X-Gm-Message-State: ALyK8tJcU4jAQOvv7nsOSXmNRNgduyY//TWzln9NFIox9LLQocBnt3FgHpYteKYGIycTTdx4JZROEmmPVX5iHQ== X-Received: by 10.31.88.196 with SMTP id m187mr3300209vkb.37.1464112831584; Tue, 24 May 2016 11:00:31 -0700 (PDT) MIME-Version: 1.0 From: Aaron Falk Date: Tue, 24 May 2016 18:00:21 +0000 Message-ID: To: "taps@ietf.org" Content-Type: multipart/alternative; boundary=001a114e21163ce19005339a55e9 Archived-At: Subject: [Taps] Berlin planning - conflicts? X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 18:00:35 -0000 --001a114e21163ce19005339a55e9 Content-Type: text/plain; charset=UTF-8 I'm about to submit a request for a meeting slot at IETF-96 in Berlin. I seem to recall we had an unfortunate conflict during our last meeting. Can anyone recall what it was? Or any other contributions to the conflict avoidance list? --aaron --001a114e21163ce19005339a55e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm about to submit a request for a meeting slot at IE= TF-96 in Berlin.=C2=A0 I seem to recall we had an unfortunate conflict duri= ng our last meeting.=C2=A0 Can anyone recall what it was?=C2=A0 Or any othe= r contributions to the conflict avoidance list?=C2=A0

--= aaron
--001a114e21163ce19005339a55e9-- From nobody Wed May 25 08:42:29 2016 Return-Path: X-Original-To: taps@ietf.org Delivered-To: taps@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C438812D5AB; Wed, 25 May 2016 08:42:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160525154227.18257.2639.idtracker@ietfa.amsl.com> Date: Wed, 25 May 2016 08:42:27 -0700 Archived-At: Cc: falk-ietf@dgftech.com, taps-chairs@ietf.org, spencerdawkins.ietf@gmail.com, taps@ietf.org Subject: [Taps] taps - New Meeting Session Request for IETF 96 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussions on Transport Services List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 15:42:28 -0000 A new meeting session request has just been submitted by Aaron Falk, a Chair of the taps working group. --------------------------------------------------------- Working Group Name: Transport Services Area Name: Transport Area Session Requester: Aaron Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: apparea appsawg tsvarea aqm rmcat ippm tsvwg iccrg tcpm dispatch Second Priority: webpush tcpinc nvo3 mptcp icnrg httpbis irtfopen Third Priority: mmusic tram Special Requests: --------------------------------------------------------- From nobody Thu May 26 00:44:56 2016 Return-Path: X-Original-To: taps@ietfa.amsl.com Delivered-To: taps@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC5B12D59D for ; Thu, 26 May 2016 00:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvC5uuaCzz8x for ; Thu, 26 May 2016 00:44:50 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id C1F9B12D13B for ; Thu, 26 May 2016 00:44:50 -0700 (PDT) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 583191B00250 for ; Thu, 26 May 2016 08:57:08 +0100 (BST) Message-ID: <5746A96F.7020204@erg.abdn.ac.uk> Date: Thu, 26 May 2016 08:44:47 +0100 From: Gorry Fairhurst Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: taps@ietf.org References: <20160526073801.14530.72394.idtracker@ietfa.amsl.com> In-Reply-To: <20160526073801.14530.72394.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20160526073801.14530.72394.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Taps] : New Version Notification for draft-fairhurst-taps-transports-usage-udp-02.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 26 May 2016 07:44:54 -0000 We have submitted a new version of the UDP Usage document. This incorporates changes to fix some details, but more importantly a set of changes that were motivatd by review comments for the 01 version. The authors hope this version now incorporates all details needed to allow the TAPS WG to proceed with consideration of the UDP protocol. Comments and corrections are of course welcome, Gorry & Tom --- A new version of I-D, draft-fairhurst-taps-transports-usage-udp-02.txt has been successfully submitted by Godred Fairhurst and posted to the IETF repository. Name: draft-fairhurst-taps-transports-usage-udp Revision: 02 Title: Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- Lite) Transport Protocols Document date: 2016-05-26 Group: Individual Submission Pages: 25 URL: https://www.ietf.org/internet-drafts/draft-fairhurst-taps-transports-usage-udp-02.txt Status: https://datatracker.ietf.org/doc/draft-fairhurst-taps-transports-usage-udp/ Htmlized: https://tools.ietf.org/html/draft-fairhurst-taps-transports-usage-udp-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-fairhurst-taps-transports-usage-udp-02 Abstract: This document describes how the User Datagram Protocol (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport protocols expose services to applications and how an application can configure and use the features offered by the transport service. The document is intended as a contribution to the Transport Services (TAPS) working group to assist in analysis of the UDP and UDP-Lite transport interface. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat