From nobody Mon Oct 1 12:58:08 2018 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 9FD0D1293FB; Mon, 1 Oct 2018 12:57:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.85.1 Auto-Submitted: auto-generated Precedence: bulk Cc: draft-ietf-taps-minset@ietf.org, Theresa Enghardt , theresa@inet.tu-berlin.de, The IESG , taps-chairs@ietf.org, spencerdawkins.ietf@gmail.com, rfc-editor@rfc-editor.org, taps@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <153842387664.22347.9369861988734877305.idtracker@ietfa.amsl.com> Date: Mon, 01 Oct 2018 12:57:56 -0700 Archived-At: Subject: [Taps] Document Action: 'A Minimal Set of Transport Services for End Systems' to Informational RFC (draft-ietf-taps-minset-11.txt) X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2018 19:57:57 -0000 The IESG has approved the following document: - 'A Minimal Set of Transport Services for End Systems' (draft-ietf-taps-minset-11.txt) as Informational RFC This document is the product of the Transport Services Working Group. The IESG contact persons are Mirja Kühlewind and Spencer Dawkins. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-minset/ Technical Summary This document recommends a minimal set of transport services offered by end systems, based on the set of existing transport protocol features surveyed in RFC 8303. It summarizes which transport features are worth exposing to an application, in contrast to those which can be automated within a transport system. Furthermore, the document gives guidance on choosing among the available mechanisms and protocols. Working Group Summary As this document generalizes and categorizes primitives that are already standardized in the RFC series, there was little controversy about them. Much of the discussion was about coming up with consistent terminology and about finding the right scope, which now focuses on features of existing transport protocols that can be implemented over TCP, or UDP if certain limitations are put in place. It was discussed whether to include security features, and finally after broadening the TAPS charter, they were put in a separate document. Document Quality Initially, there was not a lot of interest in this deliverable, but eventually the document was extensively reviewed and discussed by half a dozen active Working Group participants. In addition, during WGLC the body of the document was reviewed by Mikael Abrahamsson, who had not read the document before, who found it easy to understand and ready for publication. Personnel The document shepherd is Theresa Enghardt. The responsible Area Director is Spencer Dawkins. From nobody Tue Oct 9 07:16:25 2018 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 DB1C0130E06 for ; Tue, 9 Oct 2018 07:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 m2fAfMASP7LF for ; Tue, 9 Oct 2018 07:16:22 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 BC60A13132E for ; Tue, 9 Oct 2018 07:16:19 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id e22-v6so1745991qto.6 for ; Tue, 09 Oct 2018 07:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version; bh=k6Eoow4oL5JohWMmTQQmTFmcc7NaGINVbB4xMcRw5TI=; b=OFQ78to7/mDRd/HykLIGXt9voYhDog050xPaPHqCDYY2DaEpy2QFr+q1L76qI/EG14 efV7jMdI1vwvTEfBiR7V3VAkQJUigfBa4eXuUDEJzQezzJ5rIO00YQXKU7DztjJuQhYv 85U1F5BGZLtmel+0O2nniDetnO6mBEzYiHaj2s3ftr08ZGGSbKR6VOn70K1EtIpoXxv1 4mgPDe+9CeGT4TxDqDPRk0sRDHx0hQ/UkJhD4jcns+o6o/D1W0A7t0yiuIRaxqVn33Sd qv4sdwxbdcw5Y+u3rUhR1fkh0DecirFuG8wngZuwvIlfwFylCx+r5+T4nnMdVrGpMqIM jIPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version; bh=k6Eoow4oL5JohWMmTQQmTFmcc7NaGINVbB4xMcRw5TI=; b=UgzxoRqJsHhFCPwZjfAfenQxTBe4wEtpVepuD9ExhLFDFXHfeOa7RTvzBezCG+SYyy 6S1jq7feRAbNuTYF0ODaztCJSQhFNEK3kPU3+CZNqOuioQFL3ARtUGXEK8Aggcrjf/Ee ar57UK7iYBtgl9R5R5IPlXe0wskYeAtccmfTPwkOweSmcpQbiA6T5mArO6jQnZJeayg0 hrpHsWuMzYffxHZgIUkYCXLs/lRLlzWO408+494O2iWbtx0cCkkX7pA+QL8dJMelf+ks GAnugqZGDZ5lNiWMr67Vxr+9o+xud6AqN1D7OWa/kTN5CHipbty1t2RtQo3cqyO1twiv Qk4g== X-Gm-Message-State: ABuFfogFwVhrG5BunykAkXu3kdGK3t4nMMAV/W9bWDwCin5FDALe3Z+b /5MnWBVxLzJSN+rDQ0aX/in0IMhk X-Google-Smtp-Source: ACcGV60msi5qTJbjlUpbZgqklF/HL41rpg5GCzX7L4WM7DORe9YqG3BacdMj3a/TJYU164bK4D1pVg== X-Received: by 2002:ad4:41cc:: with SMTP id a12mr5389810qvq.55.1539094578506; Tue, 09 Oct 2018 07:16:18 -0700 (PDT) Received: from [172.19.34.62] ([2001:4878:a000:3000:80fa:befe:41b0:e35]) by smtp.gmail.com with ESMTPSA id s71-v6sm10928914qkl.86.2018.10.09.07.16.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Oct 2018 07:16:17 -0700 (PDT) From: "Aaron Falk" To: "TAPS WG IETF list" Cc: "Zaheduzzaman Sarker" Date: Tue, 09 Oct 2018 10:16:16 -0400 X-Mailer: MailMate (1.12r5525) Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_8EBFB342-6FB2-4A7D-AE90-0BBC41E98074_=" Archived-At: Subject: [Taps] call for TAPS agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2018 14:16:24 -0000 --=_MailMate_8EBFB342-6FB2-4A7D-AE90-0BBC41E98074_= Content-Type: text/plain; format=flowed; markup=markdown If you haven't looked at the [draft IETF agenda](https://datatracker.ietf.org/meeting/103/agenda.html) yet, you can now and notice that we have a 2hr slot first thing Monday morning. What should we discuss? --aaron --=_MailMate_8EBFB342-6FB2-4A7D-AE90-0BBC41E98074_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

If you haven't looked at the draft IETF a= genda yet, you can now and notice that we have a 2hr slot first thing= Monday morning. What should we discuss?

--aaron

--=_MailMate_8EBFB342-6FB2-4A7D-AE90-0BBC41E98074_=-- From nobody Wed Oct 10 23:20:36 2018 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 11F9C130E39 for ; Wed, 10 Oct 2018 23:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKiNdKpsbqsz for ; Wed, 10 Oct 2018 23:20:32 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E107130E35 for ; Wed, 10 Oct 2018 23:20:31 -0700 (PDT) Received: from mail-mx01.uio.no ([129.240.10.26]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gAUKi-0000oA-VP for taps@ietf.org; Thu, 11 Oct 2018 08:20:28 +0200 Received: from 235.34.213.193.static.cust.telenor.com ([193.213.34.235] helo=[10.0.1.7]) by mail-mx01.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1gAUKg-0004qd-IZ for taps@ietf.org; Thu, 11 Oct 2018 08:20:28 +0200 From: Michael Welzl Content-Type: multipart/alternative; boundary="Apple-Mail=_92DF8A72-0EFB-40CC-89F8-A4D3DF8AAFFF" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <71E6690F-44E7-4E5C-AC84-F8BDDB12F852@ifi.uio.no> Date: Thu, 11 Oct 2018 08:20:23 +0200 To: "taps@ietf.org" X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx01.uio.no: 193.213.34.235 is neither permitted nor denied by domain of ifi.uio.no) client-ip=193.213.34.235; envelope-from=michawe@ifi.uio.no; helo=[10.0.1.7]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: DF0C2C212A3EDC44A99C78A386D5C179506853B0 Archived-At: Subject: [Taps] QUIC API for WebRTC X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 06:20:35 -0000 --Apple-Mail=_92DF8A72-0EFB-40CC-89F8-A4D3DF8AAFFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, I just thought that it=E2=80=99s good for this group to be aware about = this API: https://w3c.github.io/webrtc-quic/ Sadly, not transport protocol independent=E2=80=A6 Cheers, Michael --Apple-Mail=_92DF8A72-0EFB-40CC-89F8-A4D3DF8AAFFF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

I = just thought that it=E2=80=99s good for this group to be aware about = this API:
https://w3c.github.io/webrtc-quic/
Sadly, not transport protocol = independent=E2=80=A6

Cheers,
Michael

= --Apple-Mail=_92DF8A72-0EFB-40CC-89F8-A4D3DF8AAFFF-- From nobody Thu Oct 11 14:15:11 2018 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 2C54112426A for ; Thu, 11 Oct 2018 14:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKWdTMtgsBzb for ; Thu, 11 Oct 2018 14:15:08 -0700 (PDT) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (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 10F8F12777C for ; Thu, 11 Oct 2018 14:15:08 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.22/8.16.0.22) with SMTP id w9BLCEKI062608; Thu, 11 Oct 2018 14:15:00 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=wsTlA/0Kp0zTOiyQffNw/xvsc3tthpTfjHEQd3kX7rA=; b=MhoXtLzDofC9kafpqHZhYUpO1/w/HRUd0r+yB0YGgA3g//Wk15BGpNNghvLy6OCtzPk9 o2dMK2dxucmkiVaKLdC8Mk0PM0Vn0ZJKcxEO/E6oEfyVn9m4KEL09UyiHmhwnPXuCVhA t5zBan76FyYBEDwGYw3O8m4GF8P9BdSqixCBUTIXEOA/dhweV8vmlA/ssiMZz49cMUoh WukjdADJQsr2bVhcIA0AKJEF3L96i/gAecYb3ltAQjIiTm0gn1oX72JEx9NxxFaxMGfZ zwEIFnQY5xNTjqER3l412h3JhR7QXZEo28Fl86BRWFGih11Ix0DpxC8jDOKT2ezKgDch KA== Received: from ma1-mtap-s02.corp.apple.com (ma1-mtap-s02.corp.apple.com [17.40.76.6]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2mxskc8tbp-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 11 Oct 2018 14:15:00 -0700 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_j4kq/I/vF3Y4MnUceO3sig)" Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by ma1-mtap-s02.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PGG005KIDOYS3D0@ma1-mtap-s02.corp.apple.com>; Thu, 11 Oct 2018 14:14:59 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PGG00C00D96D400@nwk-mmpp-sz13.apple.com>; Thu, 11 Oct 2018 14:14:58 -0700 (PDT) X-Va-A: X-Va-T-CD: 91949cb67ad5a17194231cf3cf1e09f7 X-Va-E-CD: 63013081a6a18f67a6b5985da63079b3 X-Va-R-CD: 093da20303732465ced0230bd12ee60d X-Va-CD: 0 X-Va-ID: 06aeabb7-0aa8-4930-a582-6a6d25ed9990 X-V-A: X-V-T-CD: 91949cb67ad5a17194231cf3cf1e09f7 X-V-E-CD: 63013081a6a18f67a6b5985da63079b3 X-V-R-CD: 093da20303732465ced0230bd12ee60d X-V-CD: 0 X-V-ID: 96f1643b-a5c9-4332-afa4-8943bd352b49 Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PGG00C00D8PCJ00@nwk-mmpp-sz13.apple.com>; Thu, 11 Oct 2018 14:14:57 -0700 (PDT) Authentication-results: corp.apple.com; spf=pass smtp.mailfrom=tpauly@apple.com; dmarc=pass header.from=apple.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-11_09:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp17.corp.apple.com-10000_instance1 Received: from [17.234.110.84] (unknown [17.234.110.84]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PGG002VTDOXV880@nwk-mmpp-sz13.apple.com>; Thu, 11 Oct 2018 14:14:57 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Thu, 11 Oct 2018 14:14:46 -0700 In-reply-to: <71E6690F-44E7-4E5C-AC84-F8BDDB12F852@ifi.uio.no> Cc: "taps@ietf.org" , youenn fablet , Colin Perkins To: Michael Welzl References: <71E6690F-44E7-4E5C-AC84-F8BDDB12F852@ifi.uio.no> X-Mailer: Apple Mail (2.3445.100.36) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-11_09:, , signatures=0 Archived-At: Subject: Re: [Taps] QUIC API for WebRTC X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2018 21:15:10 -0000 --Boundary_(ID_j4kq/I/vF3Y4MnUceO3sig) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Michael, Thanks for sharing! We recently saw this too, and my impression is = similar. Ideally, from a WebRTC application's perspective, we should = have a TAPS system that helps set up ICE, determines which protocol = stack to use (SCTP/DTLS, SRTP, QUIC, etc), and lets the application = interact with the the TAPS API regardless of the protocol. At the very least, as an intermediate point before we go full TAPS, we = should push for a model in which the API is transport independent and we = use the surveys/minset of TAPS to guide the API surface. I'm adding Youenn to the thread, who is participating in the W3C WG = that's discussing this. Perhaps we can give some suggestions for = feedback? I think this also brings up a point that it may be good to have a = discussion in Bangkok with the group about getting a bit more in detail = to how TAPS can best serve WebRTC use cases, and make that aspect of the = API really concrete. Thanks, Tommy > On Oct 10, 2018, at 11:20 PM, Michael Welzl = wrote: >=20 > Hi, >=20 > I just thought that it=E2=80=99s good for this group to be aware about = this API: > https://w3c.github.io/webrtc-quic/ = >=20 > Sadly, not transport protocol independent=E2=80=A6 >=20 > Cheers, > Michael >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Boundary_(ID_j4kq/I/vF3Y4MnUceO3sig) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hi = Michael,

Thanks for = sharing! We recently saw this too, and my impression is similar. = Ideally, from a WebRTC application's perspective, we should have a TAPS = system that helps set up ICE, determines which protocol stack to use = (SCTP/DTLS, SRTP, QUIC, etc), and lets the application interact with the = the TAPS API regardless of the protocol.

At the very least, as an intermediate = point before we go full TAPS, we should push for a model in which the = API is transport independent and we use the surveys/minset of TAPS to = guide the API surface.

I'm adding Youenn to the thread, who is participating in the = W3C WG that's discussing this. Perhaps we can give some suggestions for = feedback?

I = think this also brings up a point that it may be good to have a = discussion in Bangkok with the group about getting a bit more in detail = to how TAPS can best serve WebRTC use cases, and make that aspect of the = API really concrete.

Thanks,
Tommy

On Oct 10, 2018, at 11:20 PM, Michael Welzl <michawe@ifi.uio.no> = wrote:

Hi,

I just thought that = it=E2=80=99s good for this group to be aware about this API:
https://w3c.github.io/webrtc-quic/
Sadly, not transport protocol = independent=E2=80=A6

Cheers,
Michael

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

= --Boundary_(ID_j4kq/I/vF3Y4MnUceO3sig)-- From nobody Thu Oct 11 23:20:13 2018 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 AB1781292F1 for ; Thu, 11 Oct 2018 23:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pkg3Kd9i4pGa for ; Thu, 11 Oct 2018 23:20:09 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3850130DFB for ; Thu, 11 Oct 2018 23:20:08 -0700 (PDT) Received: from mail-mx10.uio.no ([129.240.10.27]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gAqnt-0004R6-Ap; Fri, 12 Oct 2018 08:20:05 +0200 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx10.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1gAqns-000Bqb-T9; Fri, 12 Oct 2018 08:20:05 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Michael Welzl In-Reply-To: Date: Fri, 12 Oct 2018 08:20:00 +0200 Cc: "taps@ietf.org" , youenn fablet , Colin Perkins Content-Transfer-Encoding: quoted-printable Message-Id: <04D9C9F3-5013-43FE-89EB-4BB19AD57B7A@ifi.uio.no> References: <71E6690F-44E7-4E5C-AC84-F8BDDB12F852@ifi.uio.no> To: Tommy Pauly X-Mailer: Apple Mail (2.3445.9.1) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx10.uio.no: 129.240.68.135 is neither permitted nor denied by domain of ifi.uio.no) client-ip=129.240.68.135; envelope-from=michawe@ifi.uio.no; helo=boomerang.ifi.uio.no; 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: 3F94219D266DC092A7475C6A655F6F7304A0E1E3 Archived-At: Subject: Re: [Taps] QUIC API for WebRTC X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 06:20:12 -0000 > On 11 Oct 2018, at 23:14, Tommy Pauly wrote: >=20 > Hi Michael, >=20 > Thanks for sharing! We recently saw this too, and my impression is = similar. Ideally, from a WebRTC application's perspective, we should = have a TAPS system that helps set up ICE, determines which protocol = stack to use (SCTP/DTLS, SRTP, QUIC, etc), and lets the application = interact with the the TAPS API regardless of the protocol. >=20 > At the very least, as an intermediate point before we go full TAPS, we = should push for a model in which the API is transport independent and we = use the surveys/minset of TAPS to guide the API surface. I agree - also, it seems to me that the original WebRTC API was more = abstract, starting with the concept of channels and such... > I'm adding Youenn to the thread, who is participating in the W3C WG = that's discussing this. Perhaps we can give some suggestions for = feedback? >=20 > I think this also brings up a point that it may be good to have a = discussion in Bangkok with the group about getting a bit more in detail = to how TAPS can best serve WebRTC use cases, and make that aspect of the = API really concrete. To me, that seems like a very good suggestion! Cheers, Michael From nobody Fri Oct 12 12:48:47 2018 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 26088130DC8 for ; Fri, 12 Oct 2018 12:48:45 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 BUplkooqC3w7 for ; Fri, 12 Oct 2018 12:48:43 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 669671286E3 for ; Fri, 12 Oct 2018 12:48:43 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id d21-v6so2722210qtq.2 for ; Fri, 12 Oct 2018 12:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=wBkO9U2DgqbabfXSEAlCYfx8tl1t07hVEeBM0VhW91s=; b=WeegEmrC3ms6mtAHNEaNbXPEeVRCrzb1gcWRB5hcbKSYsTB5Hb3p25iaHylyxqQ4YH Wbh+W1qAEaMNiQ6DKd69X0UTSQMa9Oep6frJ7Z8F/fMcVSUSGuIQ73qy7Y8UMxJ2l0jD iIdZs2pm+ksB+033HdF+XYOXAeVGH9PY/DI2XJNoPSRWzUi5Xw+OooFmJigMEl/vWcJx dsDpmafRkjcdVlYh9WLwzt+FuMyTR/vV776fGBQviutVzD723TKtlwlRRAIkVzRwt9gC dEJRv62uesWbKpP1VW4JTrgVlJvvaegH6sSd8imVkJWDTZkvDhmDEBGqKU4rRBi2lvys v+Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=wBkO9U2DgqbabfXSEAlCYfx8tl1t07hVEeBM0VhW91s=; b=I8rfCtgY7uJbfB9CNc2UMazo8H8n6GpLzFR7QKWqtZFUD1kMl17Y0D2DfbUgiCiNPx g7VM2siK37yL3JvOSypQG7gTaEbogUuGp6hDMGLmFVkD4Tk4sxlkUzfhxpBUq2U941oQ Vo6Bzi+UoKJQ2C1uAYINb0F9f/23yvUpsQcMX6WY0kMeJt/MnPEN1KvsAbOkxhz9uxk+ V8wfTUfSml6CyQDJjxUCY4FKcV15i1wB2lc/MpYie3pq8xHb+djQslL/Uy50nWE+PPsx XhME+30e/O1VuLxzh1MpTyKwr8Y0BOzK5BRsuT2wItYSu0XMtWbRVKjfwPnrrCYj1Gby uO/w== X-Gm-Message-State: ABuFfojj+dGoXdroLNyL4hX8hVKxVGpOKGlR6J4dSWaVr4aA3ZLkmRAm zg0/x6VOo2cS8PVRAdzD5jg= X-Google-Smtp-Source: ACcGV612PzPkVd36FbcrIUUmA2phJ5mIBrgQDgre/qD0cVaGuHb5edbx152SU0g8ilwOKrtk9sElCA== X-Received: by 2002:a0c:f889:: with SMTP id u9mr7405910qvn.131.1539373722041; Fri, 12 Oct 2018 12:48:42 -0700 (PDT) Received: from [172.19.34.158] ([2001:4878:a000:3000:89be:6b3b:35aa:4be3]) by smtp.gmail.com with ESMTPSA id v54-v6sm2108843qtc.81.2018.10.12.12.48.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Oct 2018 12:48:41 -0700 (PDT) From: "Aaron Falk" To: "Tommy Pauly" Cc: "Michael Welzl" , "youenn fablet" , "Colin Perkins" , taps@ietf.org Date: Fri, 12 Oct 2018 15:48:39 -0400 X-Mailer: MailMate (1.12r5525) Message-ID: In-Reply-To: References: <71E6690F-44E7-4E5C-AC84-F8BDDB12F852@ifi.uio.no> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_A06A52E8-1F87-4038-A533-85E73B8689A0_=" Archived-At: Subject: Re: [Taps] QUIC API for WebRTC X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 19:48:45 -0000 --=_MailMate_A06A52E8-1F87-4038-A533-85E73B8689A0_= Content-Type: text/plain; format=flowed; markup=markdown On 11 Oct 2018, at 17:14, Tommy Pauly wrote: > I think this also brings up a point that it may be good to have a > discussion in Bangkok with the group about getting a bit more in > detail to how TAPS can best serve WebRTC use cases, and make that > aspect of the API really concrete. Are you thinking an offline discussion or would you like to spend some agenda time on the topic? I could invite the authors to present. --aaron --=_MailMate_A06A52E8-1F87-4038-A533-85E73B8689A0_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">On 11 Oct 2018, at 17:14, Tommy Pauly wrote:

I think this also brings up a point= that it may be good to have a discussion in Bangkok with the group about= getting a bit more in detail to how TAPS can best serve WebRTC use cases= , and make that aspect of the API really concrete.

Are you thinking an offline discussion or wo= uld you like to spend some agenda time on the topic? I could invite the = authors to present.

--aaron

--=_MailMate_A06A52E8-1F87-4038-A533-85E73B8689A0_=-- From nobody Fri Oct 12 12:53:07 2018 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 4BF4B130DC8 for ; Fri, 12 Oct 2018 12:53:05 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5YAIoN7yFOs for ; Fri, 12 Oct 2018 12:53:03 -0700 (PDT) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (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 A058B1286E3 for ; Fri, 12 Oct 2018 12:53:03 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.22/8.16.0.22) with SMTP id w9CJpeuX056465; Fri, 12 Oct 2018 12:52:56 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=f93lIZX1Gjd++DNc+zlBestPz082MOste959qypKqEI=; b=S4Rr4WF58F+2GKbOVPUnDLTOIGvAq2qkUtAydKUpmR2Pv5NiRJhMsO4Qs8/062Dmwv8p 8rT0PEdDvftqcL4CVl8gEqjyeRFkgneM1hKTKzyk//AZ++ydI4+EfmtbB7vI5uVfQQi9 pz3zz+LPxeDkriJi7GmDVV79Xyxsaea4sJpwUMbN3F64rLDstfFJFGn690OHiLHYIeyE PlaCPdghwJk+JVeilSl2bB+LOV64WXqu40dMnfEtRmCE6yiCyOhVR0tAzeb+ni/rtYDG Xgh+9vYJSVA5FVF9+2Tuo+qVf/WXJVxvA3NDgS/XfUG9SxR31E9FDAX1TJ3ow6xZPVvZ nQ== Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2mxskdar5e-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 12 Oct 2018 12:52:56 -0700 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_tHHQgJbS5kZQKqBxX+LzWg)" Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PGI000WS4K6VAE0@ma1-mtap-s01.corp.apple.com>; Fri, 12 Oct 2018 12:52:55 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PGI0040043RC500@nwk-mmpp-sz10.apple.com>; Fri, 12 Oct 2018 12:52:54 -0700 (PDT) X-Va-A: X-Va-T-CD: 0325f276f41c42fd3b0ac081f7f3f808 X-Va-E-CD: 63013081a6a18f67a6b5985da63079b3 X-Va-R-CD: 093da20303732465ced0230bd12ee60d X-Va-CD: 0 X-Va-ID: ef8da63b-1d64-4899-9b29-d176514532ea X-V-A: X-V-T-CD: 9ea90e61654dad0c8920388428deae70 X-V-E-CD: 63013081a6a18f67a6b5985da63079b3 X-V-R-CD: 093da20303732465ced0230bd12ee60d X-V-CD: 0 X-V-ID: c6ffebe2-d2bd-4c57-9ac7-7d07ccf3a40e Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PGI008004GCL600@nwk-mmpp-sz10.apple.com>; Fri, 12 Oct 2018 12:52:54 -0700 (PDT) Authentication-results: corp.apple.com; spf=softfail smtp.mailfrom=tpauly@apple.com; dmarc=none header.from=apple.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-12_13:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp15.corp.apple.com-10000_instance1 Received: from [17.234.88.48] (unknown [17.234.88.48]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PGI00I2C4K5NS60@nwk-mmpp-sz10.apple.com>; Fri, 12 Oct 2018 12:52:53 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Fri, 12 Oct 2018 12:52:42 -0700 In-reply-to: Cc: Michael Welzl , youenn fablet , Colin Perkins , taps@ietf.org To: Aaron Falk References: <71E6690F-44E7-4E5C-AC84-F8BDDB12F852@ifi.uio.no> X-Mailer: Apple Mail (2.3445.100.36) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-12_13:, , signatures=0 Archived-At: Subject: Re: [Taps] QUIC API for WebRTC X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Oct 2018 19:53:06 -0000 --Boundary_(ID_tHHQgJbS5kZQKqBxX+LzWg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT I think it would be useful to have agenda time in TAPS to discuss both: - Transport API mappings for QUIC - TAPS API mappings for WebRTC Having input on the requirements and background for WebRTC + QUIC would be great. Thanks, Tommy > On Oct 12, 2018, at 12:48 PM, Aaron Falk wrote: > > On 11 Oct 2018, at 17:14, Tommy Pauly wrote: > > I think this also brings up a point that it may be good to have a discussion in Bangkok with the group about getting a bit more in detail to how TAPS can best serve WebRTC use cases, and make that aspect of the API really concrete. > > Are you thinking an offline discussion or would you like to spend some agenda time on the topic? I could invite the authors to present. > > --aaron > --Boundary_(ID_tHHQgJbS5kZQKqBxX+LzWg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT I think it would be useful to have agenda time in TAPS to discuss both:

- Transport API mappings for QUIC
- TAPS API mappings for WebRTC

Having input on the requirements and background for WebRTC + QUIC would be great.

Thanks,
Tommy

On Oct 12, 2018, at 12:48 PM, Aaron Falk <aaron.falk@gmail.com> wrote:

On 11 Oct 2018, at 17:14, Tommy Pauly wrote:

I think this also brings up a point that it may be good to have a discussion in Bangkok with the group about getting a bit more in detail to how TAPS can best serve WebRTC use cases, and make that aspect of the API really concrete.

Are you thinking an offline discussion or would you like to spend some agenda time on the topic? I could invite the authors to present.

--aaron


--Boundary_(ID_tHHQgJbS5kZQKqBxX+LzWg)-- From nobody Mon Oct 15 07:53:19 2018 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 F0B93130E84 for ; Mon, 15 Oct 2018 07:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 S1g0xXzyRPxl for ; Mon, 15 Oct 2018 07:53:16 -0700 (PDT) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 0EE62130E7E for ; Mon, 15 Oct 2018 07:53:16 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id f18-v6so9440390plr.1 for ; Mon, 15 Oct 2018 07:53:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=fqgVOwWbbESgEfADMkWlUahcuN9SBmelnAoQGId5d/Q=; b=prIMHiuwittW37Ie5CVpyAX2bGOx01MkJnrDgjXJVTotQ61eM3F8pXucc4rk0XZzXY fmKNemQCeAQmJkdthiERIHt1dZ6+kOVe1ixOIlu05JTUPBrWbtA01o+IWxbOEDuF3XE3 Wf7Vu7cIEA4boBjUhKpLOc40fXReDyAKFG/ZN008bjsVy0+cbE9xWGRIJlNQmmydVYVN g6igVmt9NgsEik8KAwGel3lLAXJf0N+LDFIvtPnXGbmC7c+qAWVjfHLoiqNQE1zJ2xG1 MI8Qdk6f+V75UopARsD9DviYEaCP5q7M7qkvjWIuB8e0YqQy5dMtqpT766zpor82l8hE HZaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=fqgVOwWbbESgEfADMkWlUahcuN9SBmelnAoQGId5d/Q=; b=oawwsN9ZL3gqc9Voi0BX1RjGBrEQNlWPGSH83e4P+wiEQWYDqqkIQEyjsoGuRISElM dQeR2knfUZ2ogwEbgznh89Ibqq5mhlg12Nso0cMguf86J8SH9ag2mUvcrReY2/FT3fh6 K8gssDCAUN7+7R+X5FNSK3Z/8OLVh0VYHNgCLx9R458TQ7lmLBRPklp4JRV7uvT/+t3g 5JjcuetfoLJUvIwunQzySyoyc/ZiWwDAVNnSexgNu3HMeG0zhPq+pssCGJkVI6Ive+WL jfZUfjwsqoSLCVfRZ6xqckhHI0TyXW8ZG0CRHKigtuv7bmCiuAHYnq24EZN8wVdGo39s 4McA== X-Gm-Message-State: ABuFfogA1i82dr3Wkj5wb7RTNmD4l2OvJKba890mMF6iy/5J7sVoj93T UIPqwlvziM3WFrRcMvPVehfaMUSo X-Google-Smtp-Source: ACcGV609giKVrqhXVNvav06WDLeEclFqEEmXIH4LgjxWXhf/HlwHXQU0DpimoxsZbgSbgNZhmNuVtQ== X-Received: by 2002:a17:902:3181:: with SMTP id x1-v6mr17119459plb.71.1539615194877; Mon, 15 Oct 2018 07:53:14 -0700 (PDT) Received: from [172.19.117.74] (g2001-4878-8103-0102-0100-0000-0000-04e3.deploy.static.akamaitechnologies.com. [2001:4878:8103:102:100::4e3]) by smtp.gmail.com with ESMTPSA id v38-v6sm18571930pgn.57.2018.10.15.07.53.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Oct 2018 07:53:13 -0700 (PDT) From: "Aaron Falk" To: "TAPS WG IETF list" Cc: "Zaheduzzaman Sarker" Date: Mon, 15 Oct 2018 10:53:11 -0400 X-Mailer: MailMate (1.12r5525) Message-ID: <4F5008B6-6A36-4440-AFAB-93263743559B@gmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_63233E78-7D25-4AAA-AC32-60AA6EA9DB80_=" Archived-At: Subject: Re: [Taps] call for TAPS agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2018 14:53:18 -0000 --=_MailMate_63233E78-7D25-4AAA-AC32-60AA6EA9DB80_= Content-Type: text/plain; format=flowed; markup=markdown The final agenda moved TAPS to Weds Afternoon II and 90 minutes. Here are the issues raised on the list for discussion in Bangkok: * TAPS Registry - Phillip * W3C QUIC API for WebRTC - TBD from the authors * Transport API mappings for QUIC * TAPS API mappings for WebRTC Tommy, are you planning to lead the two API discussions? All, do we need to revisit any of the other topics discussed on the interim call? * Partial Send/Receive * 0-RTT * Connection & Message Properties * Implementation & testing Also, what's going on with draft-ietf-taps-transport-security? --aaron On 9 Oct 2018, at 10:16, Aaron Falk wrote: > If you haven't looked at the [draft IETF > agenda](https://datatracker.ietf.org/meeting/103/agenda.html) yet, you > can now and notice that we have a 2hr slot first thing Monday morning. > What should we discuss? > > --aaron --=_MailMate_63233E78-7D25-4AAA-AC32-60AA6EA9DB80_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

The final agenda moved TAPS to Weds Afternoon II and 90 m= inutes.

Here are the issues raised on the list for discussion in = Bangkok:

  • TAPS Registry - Phillip
  • W3C QUIC API for WebRTC - TBD from the authors
  • Transport API mappings for QUIC
  • TAPS API mappings for WebRTC

Tommy, are you planning to lead the two API discussions?<= /p>

All, do we need to revisit any of the other topics discus= sed on the interim call?

  • Partial Send/Receive
  • 0-RTT
  • Connection & Message Properties
  • Implementation & testing

Also, what's going on with draft-ietf-taps-transport-secu= rity?

--aaron

On 9 Oct 2018, at 10:16, Aaron Falk wrote:

If you haven't looked at the draft IETF agen= da yet, you can now and notice that we have a 2hr slot first thing Mo= nday morning. What should we discuss?

--aaron

--=_MailMate_63233E78-7D25-4AAA-AC32-60AA6EA9DB80_=-- From nobody Mon Oct 15 21:00:12 2018 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 CA04C127B92 for ; Mon, 15 Oct 2018 19:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZqAHJsoqcaQ for ; Mon, 15 Oct 2018 19:27:59 -0700 (PDT) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (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 1EB97127AC2 for ; Mon, 15 Oct 2018 19:27:59 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.22/8.16.0.22) with SMTP id w9G2QxEI026132; Mon, 15 Oct 2018 19:27:51 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=QxImJwY7980xpE2PtthLt3ld41Yc+40+5xidpOp0ZIA=; b=WzjqtWoGfa2nlXQsd7RgEKvtJU12DG6xhL4E/t7fCa1cmV14y+/VClRHlaHYAOjby3/8 6MSS1NcLdg2aoeYTgMKLMHKgOQPf4w/94a+gMlkh3Pu6WtPTr3vH9L2qV3FFFu3TslwF jLyRIista7XPqr9DaXaf+GeYeT6prXuAKqvNfSxHhfWFwDcPOXZtjm1u8riRXbsMrtie +Fm4R7+uwD3XmPlPalKDUNWRY5tF2kx6QIBiGX0zaXnesoHvJ1JBAAnYMi0Nt6nYjYSb AZkQjMtSiBZ22jsI26DZ3p5TdKfQTfR/v3CTuU6rS/9jCUCKjfb5HatvTKYvpZz2zTaA 5Q== Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2n3d89f8tw-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 15 Oct 2018 19:27:51 -0700 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_GsoVpesf2iOlUJXrRzMmTQ)" Received: from ma1-mmpp-sz10.apple.com (ma1-mmpp-sz10.apple.com [17.171.128.150]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PGO007536UFOR00@mr2-mtap-s02.rno.apple.com>; Mon, 15 Oct 2018 19:27:51 -0700 (PDT) Received: from process_viserion-daemon.ma1-mmpp-sz10.apple.com by ma1-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PGO00G0067BQ600@ma1-mmpp-sz10.apple.com>; Mon, 15 Oct 2018 19:27:51 -0700 (PDT) X-Va-A: X-Va-T-CD: b6bb457c0a685d707884d44453bef0d4 X-Va-E-CD: 60e05dbaa660b1a1d1872b99f54c2fe5 X-Va-R-CD: 2b427da21ffe06b137f8b53fe585f690 X-Va-CD: 0 X-Va-ID: 77c4aed4-fca5-4154-ad66-57ba30d89a3f X-V-A: X-V-T-CD: e0b4e3205114c910a61d426831c8e828 X-V-E-CD: 60e05dbaa660b1a1d1872b99f54c2fe5 X-V-R-CD: 2b427da21ffe06b137f8b53fe585f690 X-V-CD: 0 X-V-ID: 92fb9207-5e47-43bb-9653-3c3b6cef16f3 Received: from process_milters-daemon.ma1-mmpp-sz10.apple.com by ma1-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PGO00C005WROO00@ma1-mmpp-sz10.apple.com>; Mon, 15 Oct 2018 19:27:50 -0700 (PDT) Authentication-results: corp.apple.com; spf=softfail smtp.mailfrom=yfablet@apple.com; dmarc=none header.from=apple.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-15_14:,, signatures=0 X-Proofpoint-Scanner-Instance: ma-grpmailp-qapp22.corp.apple.com-10000_instance1 Received: from [17.234.142.5] (unknown [17.234.142.5]) by ma1-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PGO0039W6UBBV80@ma1-mmpp-sz10.apple.com>; Mon, 15 Oct 2018 19:27:50 -0700 (PDT) Sender: youenn@apple.com From: youenn fablet Message-id: Date: Mon, 15 Oct 2018 19:27:45 -0700 In-reply-to: Cc: Aaron Falk , Michael Welzl , Colin Perkins , taps@ietf.org To: Tommy Pauly References: <71E6690F-44E7-4E5C-AC84-F8BDDB12F852@ifi.uio.no> X-Mailer: Apple Mail (2.3445.100.42) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-16_01:, , signatures=0 Archived-At: X-Mailman-Approved-At: Mon, 15 Oct 2018 21:00:10 -0700 Subject: Re: [Taps] QUIC API for WebRTC X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Oct 2018 02:28:01 -0000 --Boundary_(ID_GsoVpesf2iOlUJXrRzMmTQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT FWIW, this topic might also be discussed during next TPAC within the WebRC WG (https://docs.google.com/document/d/1N8Px_UfBRkvVJbRT3pQMiYKVDmg9grPQIrsOkgFoDWM/edit ). What Pauly suggests makes sense to me. Having some discussion during next IETF meeting seems beneficial. I would hope we could define a data channel API/QUIC mapping based on TAPS. Understanding the shortcomings of current data channels would be useful. I can see some cases that might be interesting to study further: - Use the same QUIC connection for both media exchange and data channel - Use an existing QUIC/HTTP connection for data channel: Web Socket or SCTP data channel replacement Y > On Oct 12, 2018, at 12:52 PM, Tommy Pauly wrote: > > I think it would be useful to have agenda time in TAPS to discuss both: > > - Transport API mappings for QUIC > - TAPS API mappings for WebRTC > > Having input on the requirements and background for WebRTC + QUIC would be great. > > Thanks, > Tommy > >> On Oct 12, 2018, at 12:48 PM, Aaron Falk > wrote: >> >> On 11 Oct 2018, at 17:14, Tommy Pauly wrote: >> >> I think this also brings up a point that it may be good to have a discussion in Bangkok with the group about getting a bit more in detail to how TAPS can best serve WebRTC use cases, and make that aspect of the API really concrete. >> >> Are you thinking an offline discussion or would you like to spend some agenda time on the topic? I could invite the authors to present. >> >> --aaron >> > --Boundary_(ID_GsoVpesf2iOlUJXrRzMmTQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
FWIW, this topic might also be discussed during next TPAC = within the WebRC WG (https://docs.google.com/document/d/1N8Px_UfBRkvVJbRT3pQMiYKVDmg= 9grPQIrsOkgFoDWM/edit).

What Pauly suggests makes sense to me. Having some discussion = during next IETF meeting seems beneficial.
I would = hope we could define a data channel API/QUIC mapping based on = TAPS.

Understanding the shortcomings of current data channels would = be useful.
I can see some cases that might be = interesting to study further:
- Use the same QUIC = connection for both media exchange and data channel
-= Use an existing QUIC/HTTP connection for data channel: Web Socket or = SCTP data channel replacement

Y

On Oct 12, 2018, at 12:52 PM, = Tommy Pauly <tpauly@apple.com> wrote:

I think it would be = useful to have agenda time in TAPS to discuss both:

- Transport API mappings for = QUIC
- TAPS API mappings for WebRTC

Having input on the = requirements and background for WebRTC + QUIC would be great.

Thanks,
Tommy

On Oct = 12, 2018, at 12:48 PM, Aaron Falk <aaron.falk@gmail.com> wrote:

On 11 = Oct 2018, at 17:14, Tommy Pauly wrote:

I think = this also brings up a point that it may be good to have a discussion in = Bangkok with the group about getting a bit more in detail to how TAPS = can best serve WebRTC use cases, and make that aspect of the API really = concrete.

Are you thinking an offline = discussion or would you like to spend some agenda time on the topic? I = could invite the authors to present.

--aaron



= --Boundary_(ID_GsoVpesf2iOlUJXrRzMmTQ)-- From nobody Fri Oct 19 10:42:47 2018 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 7F9D1130F91 for ; Fri, 19 Oct 2018 10:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 xnfUBxyayLzI for ; Fri, 19 Oct 2018 10:42:44 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 9C4BA130F88 for ; Fri, 19 Oct 2018 10:42:44 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id d14-v6so39219511qto.4 for ; Fri, 19 Oct 2018 10:42:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=lD6DUKDOMPf5mo0rMgBsE6R9zwSBeutFx/paxQ0TLew=; b=Yz9ikUyTMR5EtBWLrqXkjlSia9/iiYCYkR5cPG6wWshfqi4Z0FpC1/tcmjxCRpzQy4 NAbyYe0dOPM+FbzOaufrjye8VTR/yA2FZbESJa0YzE5hcNbv61E3Z6EiTvnKNO5Js/Sk 0h9968TKfytwb0nXc9xlYXo8KSyg/OP/fil4fiXHqrQ4XrvD94392V6J55ALYCpBon32 xU3uecGC3YpyfM3Vaj6vVbLV6vVXx5wtRSipwfoZQQnPo4+nw9C/7pYfafcjL0W9GhWl Jm/JnTzUJxxdGEAcrWhT1QQMUS2sDaAsrO4enfKxlQVbx+u3r7eUanqFeKQSMiVHd2Rg Sr0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=lD6DUKDOMPf5mo0rMgBsE6R9zwSBeutFx/paxQ0TLew=; b=qdWew3ovyDo1o9jQujbI7HYs1b79q2pZxuQZZUCnnzf4Lf6IPNC9U8UinOeA7b4gcU v0ri6+j2oYg5knZG6tUw5ycPD97t8d+wjeUpB34ssKQXE9Ucs2s0TwIQGk6L7o0czb14 qvC7qk1xi8q7PlfRqFGgcIQ1l0jpH+RKpxZA28WG12M9x0B19ocJlAq6FBtadJp93eAV 2h1aO+HWRPF798dOH/H7fGMTGlv3Y2RUMjfLrd53sxbt+lZp08/XUB4fMjby9q/JIXSV NF4DqyPUhDWRC+kjjrhEds4BmWu1pxfk9djDw5rtx6faXXW//5CnwGJrYrUByFNZUngW 7Zzg== X-Gm-Message-State: ABuFfoh9lbEd+soYq53FNRMbqr8UMBedKWBsLcwEMUKSUkSbv+qVNM/0 +tnK2CbKz686A4sxERfslWilslwF X-Google-Smtp-Source: ACcGV63Ayrn91J0/lHy/CWLE1WAlY/QHXmyjQLE5z9Vb3ovS5bTk5Ucwd2+naP2TXNl92raTPaeWqQ== X-Received: by 2002:a0c:c901:: with SMTP id r1mr35545467qvj.170.1539970963210; Fri, 19 Oct 2018 10:42:43 -0700 (PDT) Received: from [172.19.33.170] ([2001:4878:a000:3000:31c3:c516:5850:6bf5]) by smtp.gmail.com with ESMTPSA id o28-v6sm18446030qtf.72.2018.10.19.10.42.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Oct 2018 10:42:42 -0700 (PDT) From: "Aaron Falk" To: "TAPS WG IETF list" Cc: "Zaheduzzaman Sarker" Date: Fri, 19 Oct 2018 13:42:40 -0400 X-Mailer: MailMate (1.12r5525) Message-ID: <3F9B75EC-8FAD-47AF-A175-0D58448E9FBB@gmail.com> In-Reply-To: <4F5008B6-6A36-4440-AFAB-93263743559B@gmail.com> References: <4F5008B6-6A36-4440-AFAB-93263743559B@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_ACAD4516-742C-4582-936A-CB508963A928_=" Archived-At: Subject: Re: [Taps] call for TAPS agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 17:42:47 -0000 --=_MailMate_ACAD4516-742C-4582-936A-CB508963A928_= Content-Type: text/plain; format=flowed; markup=markdown 3rd prod for Bangkok agenda items... On 15 Oct 2018, at 10:53, Aaron Falk wrote: > The final agenda moved TAPS to Weds Afternoon II and 90 minutes. > > Here are the issues raised on the list for discussion in Bangkok: > > * TAPS Registry - Phillip > * W3C QUIC API for WebRTC - TBD from the authors > * Transport API mappings for QUIC > * TAPS API mappings for WebRTC > > Tommy, are you planning to lead the two API discussions? > > All, do we need to revisit any of the other topics discussed on the > interim call? > > * Partial Send/Receive > * 0-RTT > * Connection & Message Properties > * Implementation & testing > > Also, what's going on with draft-ietf-taps-transport-security? > > --aaron > > On 9 Oct 2018, at 10:16, Aaron Falk wrote: > >> If you haven't looked at the [draft IETF >> agenda](https://datatracker.ietf.org/meeting/103/agenda.html) yet, >> you can now and notice that we have a 2hr slot first thing Monday >> morning. What should we discuss? >> >> --aaron --=_MailMate_ACAD4516-742C-4582-936A-CB508963A928_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

3rd prod for Bangkok agenda items...

On 15 Oct 2018, at 10:53, Aaron Falk wrote:

The final agenda moved TAPS to Weds Afternoon II and 90 m= inutes.

Here are the issues raised on the list for discussion in = Bangkok:

  • TAPS Registry - Phillip
  • W3C QUIC API for WebRTC - TBD from the authors
  • Transport API mappings for QUIC
  • TAPS API mappings for WebRTC

Tommy, are you planning to lead the two API discussions?<= /p>

All, do we need to revisit any of the other topics discus= sed on the interim call?

  • Partial Send/Receive
  • 0-RTT
  • Connection & Message Properties
  • Implementation & testing

Also, what's going on with draft-ietf-taps-transport-secu= rity?

--aaron

On 9 Oct 2018, at 10:16, Aaron Falk wrote:

If you haven't looked at the draft IETF agen= da yet, you can now and notice that we have a 2hr slot first thing Mo= nday morning. What should we discuss?

--aaron

--=_MailMate_ACAD4516-742C-4582-936A-CB508963A928_=-- From nobody Fri Oct 19 10:49:16 2018 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 5809A130DC4 for ; Fri, 19 Oct 2018 10:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.063 X-Spam-Level: X-Spam-Status: No, score=-2.063 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdDH6ZaAlQyt for ; Fri, 19 Oct 2018 10:49:13 -0700 (PDT) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.68]) (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 BD4DF130F91 for ; Fri, 19 Oct 2018 10:49:12 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.22/8.16.0.22) with SMTP id w9JHkbBP061172; Fri, 19 Oct 2018 10:49:09 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=NEVpKtzyaFN9I3H00hMSnVnMU4mA65GBTDhw0u5pBpk=; b=fEhLeAw0p9R0fxr1V96/yv1gLuOxRmcBII/KmSfrV0jfjFuyzoTSc70y4Ph7gnBz2SCr sSiTyhBpsfmXFGIkTdwRuCAw8rTEBpW0MK3Lswxrn3pv6ET7ZYbxndoC9ZmJZxZK14Il Y/8MHBJ84RtiJ8WTmLp6EZqsHwUZyNPZzFP3h3q3mqSUAi2P4+LFaoO1HF9Fol1s8qUZ CKgZGMwX8uCTr/iH0EqoPXuNphD/ASg0d2E4WuyvsvlyLPWnCtXdkOsBGNnzyu3nI0Uy t8uiLp58QHMU3bsC+ZTjL8RVTUa/tCe7UtMrBnt/PctNARkTZ2gVra1IuhYNC3CaD2cl ug== Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com [17.179.226.133]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2n7jk298jc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 19 Oct 2018 10:49:09 -0700 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_y9FVTiiCjo8DSH+I68Qpnw)" Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PGU00IYRXHRNB30@mr2-mtap-s01.rno.apple.com>; Fri, 19 Oct 2018 10:49:03 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PGU00I00X6V5Q00@nwk-mmpp-sz10.apple.com>; Fri, 19 Oct 2018 10:49:03 -0700 (PDT) X-Va-A: X-Va-T-CD: 2dabc87b1d0e43f7700f5d93520770c0 X-Va-E-CD: e9fe70da591e25c3305d530a551289c9 X-Va-R-CD: d70fff4c6a20f6c192217937ca11ec98 X-Va-CD: 0 X-Va-ID: 3eebc7d0-54db-4c5f-91da-4c6fdacdddca X-V-A: X-V-T-CD: b32c745edf5e160faecfcff1692433d0 X-V-E-CD: e9fe70da591e25c3305d530a551289c9 X-V-R-CD: d70fff4c6a20f6c192217937ca11ec98 X-V-CD: 0 X-V-ID: 78543052-55de-4f5b-8dc2-0561e3ab6c2f Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PGU00G00X31VU00@nwk-mmpp-sz10.apple.com>; Fri, 19 Oct 2018 10:48:59 -0700 (PDT) Authentication-results: corp.apple.com; spf=softfail smtp.mailfrom=tpauly@apple.com; dmarc=quarantine header.from=apple.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-10-19_08:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp18.corp.apple.com-10000_instance1 Received: from [17.234.78.215] (unknown [17.234.78.215]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PGU002KIXHMZD10@nwk-mmpp-sz10.apple.com>; Fri, 19 Oct 2018 10:48:58 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <082F111F-66D1-46B9-BB97-8E3215487695@apple.com> Date: Fri, 19 Oct 2018 10:48:56 -0700 In-reply-to: <3F9B75EC-8FAD-47AF-A175-0D58448E9FBB@gmail.com> Cc: TAPS WG IETF list , Zaheduzzaman Sarker To: Aaron Falk , Chris Wood References: <4F5008B6-6A36-4440-AFAB-93263743559B@gmail.com> <3F9B75EC-8FAD-47AF-A175-0D58448E9FBB@gmail.com> X-Mailer: Apple Mail (2.3445.100.36) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-19_08:, , signatures=0 Archived-At: Subject: Re: [Taps] call for TAPS agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 17:49:15 -0000 --Boundary_(ID_y9FVTiiCjo8DSH+I68Qpnw) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > On Oct 19, 2018, at 10:42 AM, Aaron Falk wrote: > > 3rd prod for Bangkok agenda items... > > On 15 Oct 2018, at 10:53, Aaron Falk wrote: > > The final agenda moved TAPS to Weds Afternoon II and 90 minutes. > > Here are the issues raised on the list for discussion in Bangkok: > > TAPS Registry - Phillip > W3C QUIC API for WebRTC - TBD from the authors > Transport API mappings for QUIC > TAPS API mappings for WebRTC > Tommy, are you planning to lead the two API discussions? > > I can certainly lead or help organize these two items (QUIC and WebRTC mappings. > All, do we need to revisit any of the other topics discussed on the interim call? > > Partial Send/Receive > 0-RTT > Connection & Message Properties > Implementation & testing The next rev of the drafts should have updates on Connection & Message Properties as well as some Cached State policies, which would be good to discuss > Also, what's going on with draft-ietf-taps-transport-security? > > Chris, can you provide an update on this? I think this would be a good item to address and try to move forward. Perhaps we could have a discussion also on any adjustments or formalization we should make to the Working Group GitHub process? Thanks, Tommy > --aaron > > On 9 Oct 2018, at 10:16, Aaron Falk wrote: > > If you haven't looked at the draft IETF agenda yet, you can now and notice that we have a 2hr slot first thing Monday morning. What should we discuss? > > --aaron > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Boundary_(ID_y9FVTiiCjo8DSH+I68Qpnw) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT

On Oct 19, 2018, at 10:42 AM, Aaron Falk <aaron.falk@gmail.com> wrote:

3rd prod for Bangkok agenda items...

On 15 Oct 2018, at 10:53, Aaron Falk wrote:

The final agenda moved TAPS to Weds Afternoon II and 90 minutes.

Here are the issues raised on the list for discussion in Bangkok:

  • TAPS Registry - Phillip
  • W3C QUIC API for WebRTC - TBD from the authors
  • Transport API mappings for QUIC
  • TAPS API mappings for WebRTC

Tommy, are you planning to lead the two API discussions?


I can certainly lead or help organize these two items (QUIC and WebRTC mappings.

All, do we need to revisit any of the other topics discussed on the interim call?

  • Partial Send/Receive
  • 0-RTT
  • Connection & Message Properties
  • Implementation & testing

The next rev of the drafts should have updates on Connection & Message Properties as well as some Cached State policies, which would be good to discuss

Also, what's going on with draft-ietf-taps-transport-security?


Chris, can you provide an update on this? I think this would be a good item to address and try to move forward.

Perhaps we could have a discussion also on any adjustments or formalization we should make to the Working Group GitHub process?

Thanks,
Tommy

--aaron

On 9 Oct 2018, at 10:16, Aaron Falk wrote:

If you haven't looked at the draft IETF agenda yet, you can now and notice that we have a 2hr slot first thing Monday morning. What should we discuss?

--aaron

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

--Boundary_(ID_y9FVTiiCjo8DSH+I68Qpnw)-- From nobody Fri Oct 19 12:04:11 2018 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 F1DC1131149; Fri, 19 Oct 2018 11:56:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: spencerdawkins.ietf@gmail.com, taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153997540198.6592.1367710657251230076.idtracker@ietfa.amsl.com> Date: Fri, 19 Oct 2018 11:56:41 -0700 Archived-At: Subject: [Taps] taps - Requested session has been scheduled for IETF 103 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2018 18:56:50 -0000 Dear Aaron Falk, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. taps Session 1 (2:00 requested) Wednesday, 7 November 2018, Afternoon Session II 1540-1710 Room Name: Meeting 2 size: 150 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/103/sessions/taps.ics Request Information: --------------------------------------------------------- Working Group Name: Transport Services Area Name: Transport Area Session Requester: Aaron Falk Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: httpbis ipsecme rtcweb avtcore capport tls panrg quic tsvarea rmcat ippm tsvwg iccrg tcpm dispatch maprg cfrg Second Priority: tcpinc mptcp saag mmusic tram irtfopen People who must be present: Aaron Falk Spencer Dawkins Brian Trammell Zaheduzzaman Sarker Anna Brunstrom Tommy Pauly Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Oct 20 10:31:09 2018 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 9227F128CF2 for ; Sat, 20 Oct 2018 10:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 Q2ji0cd4oCpN for ; Sat, 20 Oct 2018 10:31:06 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 181B3130DCC for ; Sat, 20 Oct 2018 10:31:06 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id q15so12917740vso.1 for ; Sat, 20 Oct 2018 10:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yT6vSheMU+C86U04dQaPAL/sPBjbLdkimlocmwijRyI=; b=LBQrZcWyGtLaxA0bImpphI3BmCMfImyV0Pqr4bbUqMgRodX8x+GipgkdW5SB/9JXJF G0m61WYY081/d+UAkj6JemWpWOltI+UyCA6HxP4sFMKmmRtrZ3m9brEXRGy+pgAfNfqY HkTQGMDa75DhVmkJlWsv4V19kyw/6ZmFFcOtnk6xui7M1K1UD+kEfmsYXXJJddLjxeUr Xs4Mzf1d1GSnBCx5RoxmQWV0D4PyhUkTr9+oOgui0HBB6J2L/mvZ1IgFuqLunGl+TFYR WjxC1Q4Um+KcOF43yYn4tIEVsAnbtxkOx/JQnECsJIzqCnx2/r1WHOlclq9L6YgKf9A1 GtgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yT6vSheMU+C86U04dQaPAL/sPBjbLdkimlocmwijRyI=; b=Bdp4wKGhHVc0An9NiJ+B/CodLTWBg716ukkHZr9y4JqRYNJe/cK6d6EJbcj9QQena8 rO74JdMbEL4qzFFOtbLn3ily0mGOngOyRFKK5epWyFl8elpfzr/pGZNrB8TmL3Pyd/AG W3BZRWVZuaGZHQBcrJscSvbwbTkIedoqVqmxjy6sIX8hKycA65l97NPCeFsCI3zB1hgw dEJ7Htm0rZmdAVAuio2zBSmtQpSZDPcyXAQf442iaDi1O2lm6mhi/Fgd6HucviVmZoz6 LUIbTM7gEemV8Jq3t9IEdngTRqGGyT1qlmHRbykbz/PaOz2vSuwOdJwCDmEYG6+VdPqH ATQA== X-Gm-Message-State: ABuFfoiOgQ2ycYU7+Acqi31cbG1Ao3WrGbWREQtIDUG6y12ufkNrksE9 G3wOPajfcaJ+643IMyYItk8/1diADSAHVJJN+O8= X-Google-Smtp-Source: ACcGV634RWcvB/Fq+NXLoghG8VneqQmRhbqrvezU5t4b23t6+wVJGTUpOxzxsE3yfKraYa9H/ojGSdannTEr77Av564= X-Received: by 2002:a67:4e90:: with SMTP id j16mr16369470vsg.216.1540056665007; Sat, 20 Oct 2018 10:31:05 -0700 (PDT) MIME-Version: 1.0 References: <4F5008B6-6A36-4440-AFAB-93263743559B@gmail.com> <3F9B75EC-8FAD-47AF-A175-0D58448E9FBB@gmail.com> <082F111F-66D1-46B9-BB97-8E3215487695@apple.com> In-Reply-To: <082F111F-66D1-46B9-BB97-8E3215487695@apple.com> From: Christopher Wood Date: Sat, 20 Oct 2018 10:30:51 -0700 Message-ID: To: Tommy Pauly Cc: Aaron Falk , Christopher Wood , Zaheduzzaman Sarker , taps WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Taps] call for TAPS agenda items X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2018 17:31:09 -0000 On Fri, Oct 19, 2018 at 10:49 AM Tommy Pauly wrote: > > > > On Oct 19, 2018, at 10:42 AM, Aaron Falk wrote: > > 3rd prod for Bangkok agenda items... > > On 15 Oct 2018, at 10:53, Aaron Falk wrote: > > The final agenda moved TAPS to Weds Afternoon II and 90 minutes. > > Here are the issues raised on the list for discussion in Bangkok: > > TAPS Registry - Phillip > W3C QUIC API for WebRTC - TBD from the authors > Transport API mappings for QUIC > TAPS API mappings for WebRTC > > Tommy, are you planning to lead the two API discussions? > > > I can certainly lead or help organize these two items (QUIC and WebRTC mappings. > > All, do we need to revisit any of the other topics discussed on the interim call? > > Partial Send/Receive > 0-RTT > Connection & Message Properties > Implementation & testing > > > The next rev of the drafts should have updates on Connection & Message Properties as well as some Cached State policies, which would be good to discuss > > Also, what's going on with draft-ietf-taps-transport-security? > > > Chris, can you provide an update on this? I think this would be a good item to address and try to move forward. We'll rev the draft before the deadline, though I don't expect there to be any substantial differences. It might then be a good time to start the last call process. Best, Chris From nobody Mon Oct 22 07:28:08 2018 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 7B877130EE0; Mon, 22 Oct 2018 07:27:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: taps@ietf.org Message-ID: <154021847443.6529.8841516061186104159@ietfa.amsl.com> Date: Mon, 22 Oct 2018 07:27:54 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-arch-02.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 14:27:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : An Architecture for Transport Services Authors : Tommy Pauly Brian Trammell Anna Brunstrom Godred Fairhurst Colin Perkins Philipp S. Tiesel Chris Wood Filename : draft-ietf-taps-arch-02.txt Pages : 24 Date : 2018-10-22 Abstract: This document provides an overview of the architecture of Transport Services, a system for exposing the features of transport protocols to applications. This architecture serves as a basis for Application Programming Interfaces (APIs) and implementations that provide flexible transport networking services. It defines the common set of terminology and concepts to be used in more detailed discussion of Transport Services. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-arch/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-arch-02 https://datatracker.ietf.org/doc/html/draft-ietf-taps-arch-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-arch-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 22 07:28:14 2018 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 737D4130EBD; Mon, 22 Oct 2018 07:27:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: taps@ietf.org Message-ID: <154021847439.6212.4300607363474593721@ietfa.amsl.com> Date: Mon, 22 Oct 2018 07:27:54 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-interface-02.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 14:27:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : An Abstract Application Layer Interface to Transport Services Authors : Brian Trammell Michael Welzl Theresa Enghardt Godred Fairhurst Mirja Kuehlewind Colin Perkins Philipp S. Tiesel Chris Wood Filename : draft-ietf-taps-interface-02.txt Pages : 53 Date : 2018-10-22 Abstract: This document describes an abstract programming interface to the transport layer, following the Transport Services Architecture. It supports the asynchronous, atomic transmission of messages over transport protocols and network paths dynamically selected at runtime. It is intended to replace the traditional BSD sockets API as the lowest common denominator interface to the transport layer, in an environment where endpoints have multiple interfaces and potential transport protocols to select from. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-interface/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-interface-02 https://datatracker.ietf.org/doc/html/draft-ietf-taps-interface-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-interface-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 22 07:36:56 2018 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 021C912870E for ; Mon, 22 Oct 2018 07:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 1JmQheNKsUXI for ; Mon, 22 Oct 2018 07:36:52 -0700 (PDT) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8DCE130E97 for ; Mon, 22 Oct 2018 07:36:45 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 8A954341BB2 for ; Mon, 22 Oct 2018 16:36:44 +0200 (CEST) X-Iway-Path: 0 Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/20439.27054); Mon, 22 Oct 2018 16:36:44 +0200 (CEST) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS for ; Mon, 22 Oct 2018 16:36:44 +0200 (CEST) Received: from [195.176.111.22] (account ietf@trammell.ch HELO public-docking-cx-2490.ethz.ch) by switchplus-mail.ch (CommuniGate Pro SMTP 6.2.8) with ESMTPSA id 71187442 for taps@ietf.org; Mon, 22 Oct 2018 16:36:44 +0200 From: "Brian Trammell (IETF)" Content-Type: multipart/signed; boundary="Apple-Mail=_EAB42DA4-37E4-486E-A8FD-742303401417"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <499FE60F-C271-41D3-A903-BF9A49CD8A0E@trammell.ch> References: <154021847443.6529.8841516061186104159@ietfa.amsl.com> To: taps WG Date: Mon, 22 Oct 2018 16:36:43 +0200 X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Taps] Fwd: I-D Action: draft-ietf-taps-arch-02.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 14:36:55 -0000 --Apple-Mail=_EAB42DA4-37E4-486E-A8FD-742303401417 Content-Type: multipart/alternative; boundary="Apple-Mail=_0301D0FF-A996-4A61-AD3D-F355DD0F4CEA" --Apple-Mail=_0301D0FF-A996-4A61-AD3D-F355DD0F4CEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, We've submitted the -02 revisions of the Architecture and Interface = drafts, rolling up changes from the interim meeting for which we've come = to a conclusion and written text in time for the Bangkok draft cutoff. Of note: properties in the interface draft has been reorganized = following discussion in Montreal and during and after the interim, into = Selection Properties, Connection Properties, and Message Properties, = each discussed in their own section bound to their stage in the = communication process. Cheers, and have fun discussing these in Bangkok, Brian > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: [Taps] I-D Action: draft-ietf-taps-arch-02.txt > Date: 22 October 2018 at 16:27:54 CEST > To: > Cc: taps@ietf.org > Reply-To: taps@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Services WG of the IETF. >=20 > Title : An Architecture for Transport Services > Authors : Tommy Pauly > Brian Trammell > Anna Brunstrom > Godred Fairhurst > Colin Perkins > Philipp S. Tiesel > Chris Wood > Filename : draft-ietf-taps-arch-02.txt > Pages : 24 > Date : 2018-10-22 >=20 > Abstract: > This document provides an overview of the architecture of Transport > Services, a system for exposing the features of transport protocols > to applications. This architecture serves as a basis for = Application > Programming Interfaces (APIs) and implementations that provide > flexible transport networking services. It defines the common set = of > terminology and concepts to be used in more detailed discussion of > Transport Services. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-taps-arch/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-taps-arch-02 > https://datatracker.ietf.org/doc/html/draft-ietf-taps-arch-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-arch-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_0301D0FF-A996-4A61-AD3D-F355DD0F4CEA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Greetings, all,

We've submitted the -02 revisions of the Architecture and = Interface drafts, rolling up changes from the interim meeting for which = we've come to a conclusion and written text in time for the Bangkok = draft cutoff.

Of= note: properties in the interface draft has been reorganized following = discussion in Montreal and during and after the interim, into Selection = Properties, Connection Properties, and Message Properties, each = discussed in their own section bound to their stage in the communication = process.

Cheers,= and have fun discussing these in Bangkok,

Brian

Begin = forwarded message:

From: = internet-drafts@ietf.org
Subject: = [Taps] I-D = Action: draft-ietf-taps-arch-02.txt
Date: = 22 October 2018 at 16:27:54 = CEST
To: = <i-d-announce@ietf.org>
Cc: taps@ietf.org
Reply-To: = taps@ietf.org


A New = Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the Transport = Services WG of the IETF.

=        Title =           : An = Architecture for Transport Services
=        Authors =         : Tommy Pauly
=             &n= bsp;           &nbs= p;Brian Trammell
=             &n= bsp;           &nbs= p;Anna Brunstrom
=             &n= bsp;           &nbs= p;Godred Fairhurst
=             &n= bsp;           &nbs= p;Colin Perkins
=             &n= bsp;           &nbs= p;Philipp S. Tiesel
=             &n= bsp;           &nbs= p;Chris Wood
Filename =        : = draft-ietf-taps-arch-02.txt
Pages =           : 24
= Date =            : = 2018-10-22

Abstract:
=   This document provides an overview of the architecture of = Transport
  Services, a system for exposing the = features of transport protocols
  to = applications.  This architecture serves as a basis for = Application
  Programming Interfaces (APIs) and = implementations that provide
  flexible = transport networking services.  It defines the common set of
  terminology and concepts to be used in more = detailed discussion of
  Transport Services.


The IETF datatracker status = page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-taps-arch/

There are also htmlized versions available = at:
https://tools.ietf.org/html/draft-ietf-taps-arch-02
https://datatracker.ietf.org/doc/html/draft-ietf-taps-arch-02
A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-arch-02


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

Internet-Drafts are also available by = anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

= --Apple-Mail=_0301D0FF-A996-4A61-AD3D-F355DD0F4CEA-- --Apple-Mail=_EAB42DA4-37E4-486E-A8FD-742303401417 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlvN4HsACgkQihK3vwvq RqM2sxAAu5v3c9j7LDzih/hvDBEBVMtWO+jMBwvlaLKC1g/WZqQFLhJ6NfhU8J9B fhqkNaJx+Sif6Xl20AX7viQHFHHm5yGCXTWRJTVdmfeiAES7UFHa02mnIf7e3HWa Vv7e637GJ8Vq6qW5gWmSmSmZCyrcktMTp6W4UVaQ4d37E92KGnKwSP4o9/BrTxbB UJZFgO5PTqL5O6dUT1cmZ80jcDXT5qgJWcSm5ENMtOfVM24pchLXRDcdP7aHaQea WhnCYHAdAWf8ViTKnL9wd6pMTXgmkMofyvv8NGQfYR4nER16Gj/5meq8URPkuwxA enujDhdUDmraT5GQRU274W2VVRTtfrYOW5r5pQteStj3elAsy+z6cTPAI85UCOxo oh2RenohvVD7h18QisWbn+c7k08REgfT0273L1dasrfBpgHCAPiKpT87Lgpr98Y+ qBaQd3KTGt1EYJ/9U3pkHrMtYoJZZwGY1Zj6m0ZMtUQAOlk9+/1K0k2EAcI4a8lr 6M8d21UOJPIc7FlqDAqsyRsZwMpXCDD1k5kZd7Y2leDJntA1fCgGLVXSHxpGGw0n hF7OHMznt8fJWxXzicJrvyKMvveMfv1RAKyzm08MaA0BJ6bQt6dNPygiyGyRBWuE Kgih5NWtr2ftLu1SUAQDT6uYTRwyt2M8jZHEexAaKNvOPp9Gl4U= =5lL9 -----END PGP SIGNATURE----- --Apple-Mail=_EAB42DA4-37E4-486E-A8FD-742303401417-- From nobody Mon Oct 22 08:35:32 2018 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 CEAD9130DC5; Mon, 22 Oct 2018 08:35:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: taps@ietf.org Message-ID: <154022252481.6414.17399001329193257416@ietfa.amsl.com> Date: Mon, 22 Oct 2018 08:35:24 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-impl-02.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 15:35:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : Implementing Interfaces to Transport Services Authors : Anna Brunstrom Tommy Pauly Theresa Enghardt Karl-Johan Grinnemo Tom Jones Philipp S. Tiesel Colin Perkins Michael Welzl Filename : draft-ietf-taps-impl-02.txt Pages : 37 Date : 2018-10-22 Abstract: The Transport Services architecture [I-D.ietf-taps-arch] defines a system that allows applications to use transport networking protocols flexibly. This document serves as a guide to implementation on how to build such a system. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-impl/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-impl-02 https://datatracker.ietf.org/doc/html/draft-ietf-taps-impl-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-impl-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 22 08:57:45 2018 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 24C4C130E61 for ; Mon, 22 Oct 2018 08:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 1J7d41a0PuDl for ; Mon, 22 Oct 2018 08:57:32 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 1C745130E4D for ; Mon, 22 Oct 2018 08:57:32 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id q40-v6so46916453qte.0 for ; Mon, 22 Oct 2018 08:57:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=NyuMQuWqusQDVoC8hkE+r6lkipZpIOsa6q4DNTHDfaw=; b=Im3p275H3GMFVAeN9Y/hkDXbQOKAuml2NcI5JqR7iNV2hnRwADKaQFPFfoSf7ROgiu lBMuGCKJK1i8NCBTVsJ3ZseRtbWl/yzunEtbMiRvJYraO7ASJUPZy+Y6+HqgZrVEjAy8 6+oQcc5kB3cH3zMWr2zetquF4ijiJf+UvSnXZaWLJIn6ocGFROP3o3JVa/iImGjHJl9E SiiMFhuo4kQNyd0fUKisLj7vLTvUnRu+9t5rgrRT7WQ1LnbZ82qO6GsHoXa50GL+PlXQ s1F1a9mUh+432tS57Ptz+paBFKbk335G3aVpoGPscUd3gWHf+d53NERwdITuxfeCv56W pvww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=NyuMQuWqusQDVoC8hkE+r6lkipZpIOsa6q4DNTHDfaw=; b=d0k5GVRLNHDv4zfodXI//0eNfeplDrMUEauFXIDp52HeNuekaizaHw2etFfT7prLF0 fQtDQfx6c+FOpTEc86TtJZq5gEUJUODYEmmC4GaHKlzc19Ff+jwa+JqdYVV0GA+9P8Q3 Aqm/WRZSFpC03GsxepSoRgVrnKyDZrAaIBiZhftIPG9PwYRTGNAVhrgRCv7psZWtMtFL DwTuw0dad4MJsChfCTWHJT6ZUvcvJT+MbzvKuXkPC1dTRnpN/cda4Nav4VLIZtwl9rBJ P8GnAad0RaBip1pmGwlhtFsIS4SIPE+Xml7zsZ6UEzAgGE8ISCA6LOgCWO8nqm4LpaqH +iYg== X-Gm-Message-State: ABuFfogYhOhayW4Vbv47epE+IhueQdqxE/QSV92Wwxc07opp4GcEy/D/ 2+LaBhwjIk8hunojpCm6eyedBUoc X-Google-Smtp-Source: ACcGV61HBGBuU0dc6HxgQAYpZuNKVutVS37RiX6wVxw1p+xbfbAbxqcqwGldZpGSTt5GHCfvJAZIgA== X-Received: by 2002:aed:210e:: with SMTP id 14-v6mr44625544qtc.9.1540223850517; Mon, 22 Oct 2018 08:57:30 -0700 (PDT) Received: from [172.19.32.74] ([2001:4878:a000:3000:7cf9:a46b:97ae:2538]) by smtp.gmail.com with ESMTPSA id c36-v6sm35749015qta.56.2018.10.22.08.57.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Oct 2018 08:57:29 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Mon, 22 Oct 2018 11:57:28 -0400 X-Mailer: MailMate (1.12r5525) Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_E608D314-A323-4829-AD38-E659359D22E7_=" Archived-At: Subject: [Taps] Draft WG Agenda for Bangkok X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 15:57:43 -0000 --=_MailMate_E608D314-A323-4829-AD38-E659359D22E7_= Content-Type: text/plain; format=flowed; markup=markdown Draft agenda below. Some questions: **Who will lead discussion of wg doc topics (#4)?** **Will someone from ETH be available to present on TAPS GO implementation (#5)?** **Any additional topics or gripes about time allocation?** --aaron ---- 0. Agenda Bash (1m) 1. Chairs' Update (4m) 2. WGLC kickoff for draft-ietf-taps-transport-security - Chris (5m) 3. API Mappings (30m) * W3C QUIC API for WebRTC - TBD from the authors * Transport API mappings for QUIC - Tommy * TAPS API mappings for WebRTC - Tommy 4. draft-ietf-taps-{arch,impl,interface} topics (20m) -- TBD * Connection & Message Properties * Cached State policies 5. Implementation updates (10m) * GO implementation - TBD from ETH 6. TAPS Registry - Phillip (10m) 7. WG use of GitHub (10m) - Chairs --=_MailMate_E608D314-A323-4829-AD38-E659359D22E7_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Draft agenda below. Some questions:

Who will lead discussion of wg doc topics (#4)?
Will someone from ETH be available to present on TAPS GO implemen= tation (#5)?
Any additional topics or gripes about time allocation?

--aaron

  1. Agenda Bash (1m)

  2. Chairs' Update (4m)

  3. WGLC kickoff for draft-ietf-taps-transpor= t-security - Chris (5m)

  4. API Mappings (30m)

    • W3C QUIC API for WebRTC - TBD from the authors
    • Transport API mappings for QUIC - Tommy
    • TAPS API mappings for WebRTC - Tommy

  5. draft-ietf-taps-{arch,impl,interface} top= ics (20m) -- TBD

    • Connection & Message Properties
    • Cached State policies

  6. Implementation updates (10m)

    • GO implementation - TBD from ETH

  7. TAPS Registry - Phillip (10m)

  8. WG use of GitHub (10m) - Chairs

--=_MailMate_E608D314-A323-4829-AD38-E659359D22E7_=-- From nobody Mon Oct 22 09:58:11 2018 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 2C1BE130E30; Mon, 22 Oct 2018 09:58:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.87.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: taps@ietf.org Message-ID: <154022748014.6890.5464777930050299508@ietfa.amsl.com> Date: Mon, 22 Oct 2018 09:58:00 -0700 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-transport-security-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2018 16:58:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Services WG of the IETF. Title : A Survey of Transport Security Protocols Authors : Tommy Pauly Colin Perkins Kyle Rose Christopher A. Wood Filename : draft-ietf-taps-transport-security-03.txt Pages : 33 Date : 2018-10-22 Abstract: This document provides a survey of commonly used or notable network security protocols, with a focus on how they interact and integrate with applications and transport protocols. Its goal is to supplement efforts to define and catalog transport services [RFC8095] by describing the interfaces required to add security protocols. It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and WireGuard. This survey is not limited to protocols developed within the scope or context of the IETF, and those included represent a superset of features a TAPS system may need to support. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-taps-transport-security-03 https://datatracker.ietf.org/doc/html/draft-ietf-taps-transport-security-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transport-security-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 24 08:19:34 2018 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 19CF41277CC for ; Wed, 24 Oct 2018 08:19:33 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 OFUX8lh6ZCDC for ; Wed, 24 Oct 2018 08:19:31 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 5863B123FFD for ; Wed, 24 Oct 2018 08:19:31 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id g10-v6so5955176qtq.6 for ; Wed, 24 Oct 2018 08:19:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:mime-version; bh=m7KINAQmqtfXiUwdtKMWH12voj2YquPeeCSQBXh22XU=; b=SF3Ec9tpoM/eDKdb8Y48A1y9SRPpk2VoYaMdI67WIrOwbmSFHOaq7aSGq4P1OincRT 7Tbx3QWMOJp4WYHa4qDanvsCQzAmR6h9EQ9MGlotfW/qJdt8m5uMXwZtr9E9SNMFvRyz HnhauEH1VtUZVWLz+/xGLYHoW1UQSVaf5doYd5D0BwYlumvYY0j/flxvzlKWZ85yWZtx C9siOjtl+vGdmqaVofsvSwoObvGNHTGoUteQAd2HG6dufnGWHWhEKc00qDX265T2oV6i IV/ihk2+7xsg3Lv/uJ3GL05cesa89kDl4rvQMX5NqoUcy9plR04yVQKfau6z2H8fMrJI /Fiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version; bh=m7KINAQmqtfXiUwdtKMWH12voj2YquPeeCSQBXh22XU=; b=luOtqugorUQF1Qno6fHViEdRn2ef1m6r+pK3ZLVvJRGAJ+e43ZpeG9rMsv2N6T/Sqk mVu+wYo2ImWWXh4SIQ5zSDuVe8zcUiTsVRN9zyvvE+epSvXieJUANtE641GbWBzn/74o t1eEaD9sMV/T89OcF0VAdji8MIW14GcvqDsOStfZkOAlfwslzMfQ/zTCFl/nMaT+hmJB pk11V6w3PudcliuneoGPck4w7OZ0BMUhIyMx7H7KjNRhkMvqVUtNly6AHGsRuJUxLJ5v L6W8lkRwAD3rQ6Y4U7mlOLi/AZtW+dcTsEgSb6VOstAmJstZQUAhSevtOfFUovqB0kIG ComA== X-Gm-Message-State: AGRZ1gL/4C8VxMHjMCRPth1kd8odtrKNtxHU8F2NM+0MlVux1LMBP8Bv jlhFO+KPQQTDSi8ueHXKdPiTahlX X-Google-Smtp-Source: AJdET5d/5Kbc+UOT1O2kE8VT6eOPejFYagT0c9nFBtCfy2RwW3r+LneQvXQpP9h+qmYIC1+SwTDSPQ== X-Received: by 2002:ac8:2413:: with SMTP id c19-v6mr2826018qtc.194.1540394369974; Wed, 24 Oct 2018 08:19:29 -0700 (PDT) Received: from [172.19.33.27] ([2001:4878:a000:3000:dc0f:f99e:d4c8:741c]) by smtp.gmail.com with ESMTPSA id i2-v6sm3295811qkf.42.2018.10.24.08.19.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Oct 2018 08:19:28 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Wed, 24 Oct 2018 11:19:26 -0400 X-Mailer: MailMate (1.12r5525) Message-ID: <88370507-1F46-4D59-8E3A-44026B9E73A7@gmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_3296A900-A047-4FB7-95E7-AE32B5C70306_=" Archived-At: Subject: Re: [Taps] Draft WG Agenda for Bangkok X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 15:19:33 -0000 --=_MailMate_3296A900-A047-4FB7-95E7-AE32B5C70306_= Content-Type: text/plain; format=flowed; markup=markdown Looking for responses to the questions below. Hullo! On 22 Oct 2018, at 11:57, Aaron Falk wrote: > Draft agenda below. Some questions: > > **Who will lead discussion of wg doc topics (#4)?** > **Will someone from ETH be available to present on TAPS GO > implementation (#5)?** > **Any additional topics or gripes about time allocation?** > > --aaron > > ---- > > > 0. Agenda Bash (1m) > > 1. Chairs' Update (4m) > > 2. WGLC kickoff for draft-ietf-taps-transport-security - Chris (5m) > > 3. API Mappings (30m) > * W3C QUIC API for WebRTC - TBD from the authors > * Transport API mappings for QUIC - Tommy > * TAPS API mappings for WebRTC - Tommy > > 4. draft-ietf-taps-{arch,impl,interface} topics (20m) -- TBD > * Connection & Message Properties > * Cached State policies > > 5. Implementation updates (10m) > * GO implementation - TBD from ETH > > 6. TAPS Registry - Phillip (10m) > > 7. WG use of GitHub (10m) - Chairs --=_MailMate_3296A900-A047-4FB7-95E7-AE32B5C70306_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Looking for responses to the questions below. Hullo!

=

On 22 Oct 2018, at 11:57, Aaron Falk wrote:

Draft agenda below. Some questions:

Who will lead discussion of wg doc topics (#4)?
Will someone from ETH be available to present on TAPS GO implemen= tation (#5)?
Any additional topics or gripes about time allocation?

--aaron

  1. Agenda Bash (1m)

  2. Chairs' Update (4m)

  3. WGLC kickoff for draft-ietf-taps-transpor= t-security - Chris (5m)

  4. API Mappings (30m)

    • W3C QUIC API for WebRTC - TBD from the authors
    • Transport API mappings for QUIC - Tommy
    • TAPS API mappings for WebRTC - Tommy

  5. draft-ietf-taps-{arch,impl,interface} top= ics (20m) -- TBD

    • Connection & Message Properties
    • Cached State policies

  6. Implementation updates (10m)

    • GO implementation - TBD from ETH

  7. TAPS Registry - Phillip (10m)

  8. WG use of GitHub (10m) - Chairs

--=_MailMate_3296A900-A047-4FB7-95E7-AE32B5C70306_=-- From nobody Wed Oct 24 09:22:05 2018 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 69CF0130EDB for ; Wed, 24 Oct 2018 09:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id my-qZ836VKI5 for ; Wed, 24 Oct 2018 09:21:56 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 564011286E7 for ; Wed, 24 Oct 2018 09:21:56 -0700 (PDT) Received: from mail-mx01.uio.no ([129.240.10.26]) by mail-out01.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gFLus-000069-0l; Wed, 24 Oct 2018 18:21:54 +0200 Received: from 58.116.34.95.customer.cdi.no ([95.34.116.58] helo=[10.0.0.7]) by mail-mx01.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.91) (envelope-from ) id 1gFLuq-0002MH-S5; Wed, 24 Oct 2018 18:21:53 +0200 From: Michael Welzl Message-Id: <8BCA8C14-31FA-42AB-BA56-C5B630D5849C@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_1C4B4E1B-B456-4512-8272-1360757EB3A2" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 24 Oct 2018 18:21:53 +0200 In-Reply-To: <88370507-1F46-4D59-8E3A-44026B9E73A7@gmail.com> Cc: "taps@ietf.org" To: Aaron Falk References: <88370507-1F46-4D59-8E3A-44026B9E73A7@gmail.com> X-Mailer: Apple Mail (2.3273) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx01.uio.no: 95.34.116.58 is neither permitted nor denied by domain of ifi.uio.no) client-ip=95.34.116.58; envelope-from=michawe@ifi.uio.no; helo=[10.0.0.7]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: EBAAA59F6FCA67A76C39F5E81D32BF6290193BE2 Archived-At: Subject: Re: [Taps] Draft WG Agenda for Bangkok X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 16:22:03 -0000 --Apple-Mail=_1C4B4E1B-B456-4512-8272-1360757EB3A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 24, 2018, at 5:19 PM, Aaron Falk wrote: >=20 > Looking for responses to the questions below. Hullo! >=20 > On 22 Oct 2018, at 11:57, Aaron Falk wrote: >=20 > Draft agenda below. Some questions: >=20 > Who will lead discussion of wg doc topics (#4)? >=20 I=E2=80=99ll be there; I can do this. Cheers, Michael > Will someone from ETH be available to present on TAPS GO = implementation (#5)? > Any additional topics or gripes about time allocation? >=20 FWIW, I=E2=80=99m fine with this agenda! Cheers, Michael > --aaron >=20 > Agenda Bash (1m) >=20 > Chairs' Update (4m) >=20 > WGLC kickoff for draft-ietf-taps-transport-security - Chris (5m) >=20 > API Mappings (30m) >=20 > W3C QUIC API for WebRTC - TBD from the authors > Transport API mappings for QUIC - Tommy > TAPS API mappings for WebRTC - Tommy > draft-ietf-taps-{arch,impl,interface} topics (20m) -- TBD >=20 > Connection & Message Properties > Cached State policies > Implementation updates (10m) >=20 > GO implementation - TBD from ETH > TAPS Registry - Phillip (10m) >=20 > WG use of GitHub (10m) - Chairs >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_1C4B4E1B-B456-4512-8272-1360757EB3A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Oct 24, 2018, at 5:19 PM, Aaron Falk <aaron.falk@gmail.com> wrote:

Looking= for responses to the questions below. Hullo!

On 22 Oct 2018, at 11:57, Aaron Falk wrote:

Draft = agenda below. Some questions:

Who will lead discussion of wg doc topics (#4)?


I=E2=80=99ll be there; I can do this.

Cheers,
Michael


Will someone from ETH be available to present on TAPS = GO implementation (#5)?
Any additional topics or gripes about time = allocation?

=

FWIW, I=E2=80=99m fine with this = agenda!

Cheers,
Michael

--aaron

  1. Agenda Bash = (1m)

  2. Chairs' Update = (4m)

  3. WGLC kickoff for = draft-ietf-taps-transport-security - Chris (5m)

  4. API Mappings = (30m)

    • W3C QUIC API for WebRTC - TBD from the authors
    • Transport API mappings for QUIC - Tommy
    • TAPS API mappings for WebRTC - Tommy

  5. draft-ietf-taps-{arch,impl,interface} topics (20m) -- = TBD

    • Connection & Message Properties
    • Cached State policies

  6. Implementation = updates (10m)

    • GO implementation - TBD from ETH

  7. TAPS Registry - = Phillip (10m)

  8. WG use of GitHub = (10m) - Chairs

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

= --Apple-Mail=_1C4B4E1B-B456-4512-8272-1360757EB3A2-- From nobody Thu Oct 25 08:03:43 2018 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 C995E130E6A for ; Thu, 25 Oct 2018 08:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 VCgfEMkjHj-d for ; Thu, 25 Oct 2018 08:03:38 -0700 (PDT) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 A13CE130E5A for ; Thu, 25 Oct 2018 08:03:38 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id x6-v6so4011174pln.0 for ; Thu, 25 Oct 2018 08:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:embedded-html; bh=AIlicsL5GxNgs+CU9cD3giNQywrDc+Bgoa40KdNo5EI=; b=rkIvJ+uzB+CFPIbW4Q2IaRwMG7Se0RWtiZxyB9pYyEizDUY8fGpn7qd5XejZvdlNdh 4G8BbtZdGv/HAa+NxAT1/B7Tq0Muaq8dnatZ9qvBIFIwbn/ms82Be7cvxvQ57F7hApB7 rHJOS+7GG1BCc4Cz6tBfm2ycvVoB7EXU1uM/apjW6M4rR8zbeyzfgNow0XDTW4D4m9i5 EHlw4zPLz74D3gnD8/I6NVYdK2nadfLPy2+tQJcZ/YroDgtqEmpl24j4i/MBAumYOV5y dhCoETITxoXv/azgJdr/BYSEZutAhrFSgLaAHIUWus4BDWxvaThCm4A2mYZbEtsqvwpz 83LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding:embedded-html; bh=AIlicsL5GxNgs+CU9cD3giNQywrDc+Bgoa40KdNo5EI=; b=L1Ra3UML8CozDiKwG9j0nXHxGNK7X6RqQYKnwteDCs6ru2pclW1p4dgWNlnD2u0Hy4 UjdKzU+yYKoDvkhGuORxHFO77yJtRXns+/Gm8HqsrVSR9D6qdjjo4QFHlMTz42y5VHXD eK9/cTvq/gV8731P+zgrLZcGIYV6/t4FrXqvPoXKP1JyjATLTU4XHDP3+qSuNrCFEnMU tJgVsA+RFm80Ghd3Xrqjx/M1EElto84UCP1fX3x0kFQxXgUNdtXK4PUoW1dk8wBKEDvO B1elOeXSi6/BSM62nv1daj9PFwHb8g0Mq9avvIKdUpqsAP+gEDnaqnm4Wj37cz9aAtJP Z01g== X-Gm-Message-State: AGRZ1gL7zUzxpBIdTvsXGLAFyth8XcCEOQ29JunOJb9fZr7i16ChZgGF 3EGFlaewO8X4TiClz3RFXb6yeAfD X-Google-Smtp-Source: AJdET5czU+JUjLxZTS5o1NwVgYxkWqMtVg28nztZARGHYQA+rO79O7g+No+o8TlYT1QRJe0yG8/iTQ== X-Received: by 2002:a17:902:9a94:: with SMTP id w20-v6mr1828096plp.115.1540479817655; Thu, 25 Oct 2018 08:03:37 -0700 (PDT) Received: from [172.19.119.112] (c-98-216-50-175.hsd1.ma.comcast.net. [98.216.50.175]) by smtp.gmail.com with ESMTPSA id t85-v6sm11626991pfi.73.2018.10.25.08.03.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Oct 2018 08:03:36 -0700 (PDT) From: "Aaron Falk" To: "Michael Welzl" Cc: taps@ietf.org Date: Thu, 25 Oct 2018 11:03:30 -0400 X-Mailer: MailMate (1.12r5525) Message-ID: <8806DE5E-BEDE-43AA-923D-7CF5451A6420@gmail.com> In-Reply-To: <8BCA8C14-31FA-42AB-BA56-C5B630D5849C@ifi.uio.no> References: <88370507-1F46-4D59-8E3A-44026B9E73A7@gmail.com> <8BCA8C14-31FA-42AB-BA56-C5B630D5849C@ifi.uio.no> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_1A56C143-9920-46DA-97C7-9F4A3849BEFB_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[596, 3738], "plain":[217, 1243], "uuid":"6183683D-888A-4559-A21E-8A47102F3771"}] Archived-At: Subject: Re: [Taps] Draft WG Agenda for Bangkok X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 15:03:41 -0000 --=_MailMate_1A56C143-9920-46DA-97C7-9F4A3849BEFB_= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit OK. Given the response I will add Michael as lead for the wg doc topics, remove the discussion of the ETH GO implementation, and upload the revised agenda. --aaron On 24 Oct 2018, at 12:21, Michael Welzl wrote: > > On Oct 24, 2018, at 5:19 PM, Aaron Falk > wrote: >> >> Looking for responses to the questions below. Hullo! >> >> On 22 Oct 2018, at 11:57, Aaron Falk wrote: >> >> Draft agenda below. Some questions: >> >> Who will lead discussion of wg doc topics (#4)? >> > > I’ll be there; I can do this. > > Cheers, > Michael > > >> Will someone from ETH be available to present on TAPS GO >> implementation (#5)? >> Any additional topics or gripes about time allocation? >> > > FWIW, I’m fine with this agenda! > > Cheers, > Michael > >> --aaron >> >> Agenda Bash (1m) >> >> Chairs' Update (4m) >> >> WGLC kickoff for draft-ietf-taps-transport-security - Chris (5m) >> >> API Mappings (30m) >> >> W3C QUIC API for WebRTC - TBD from the authors >> Transport API mappings for QUIC - Tommy >> TAPS API mappings for WebRTC - Tommy >> draft-ietf-taps-{arch,impl,interface} topics (20m) -- TBD >> >> Connection & Message Properties >> Cached State policies >> Implementation updates (10m) >> >> GO implementation - TBD from ETH >> TAPS Registry - Phillip (10m) >> >> WG use of GitHub (10m) - Chairs >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps --=_MailMate_1A56C143-9920-46DA-97C7-9F4A3849BEFB_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">OK. Given the response I will add Michael as lead for the= wg doc topics, remove the discussion of the ETH GO implementation, and u= pload the revised agenda.

--aaron

On 24 Oct 2018, at 12:21, Michael Welzl wrote:


On Oct 24, 2018, at 5:19 PM, Aaron= Falk <aaron.falk@g= mail.com> wrote:

Looking for responses to = the questions below. Hullo!

On 22 Oct 2018= , at 11:57, Aaron Falk wrote:

Draft agenda = below. Some questions:

= Who will lead discussion of wg doc topics (#4)?


<= /div>I=E2=80=99ll be there; I can do this.

Cheers,
Michael


Will someone from ETH be available to present on TAPS = GO implementation (#5)?
Any additional topics or gripes about time allocation?=


FWIW, I=E2=80=99m fine with this agenda!

Cheers,
Michael

--aaron

  1. Agenda Bash (1m)

  2. Chairs' Update (4m)=

  3. WGLC kickoff for dr= aft-ietf-taps-transport-security - Chris (5m)

  4. API Mappings (30m)<= /p>

    • W3C QUIC API for WebRTC - TBD from the authors
    • Transport API mappings for QUIC - Tommy
    • TAPS API mappings for WebRTC - Tommy

  5. draft-ietf-taps-{ar= ch,impl,interface} topics (20m) -- TBD

    • Connection & Message Properties
    • Cached State policies

  6. Implementation upda= tes (10m)

    • GO implementation - TBD from ETH

  7. TAPS Registry - Phi= llip (10m)

  8. WG use of GitHub (1= 0m) - Chairs

_______________________________________________
Taps mailin= g list
Taps@iet= f.org
https://www.ietf.org/mailman/listinfo/taps

=
--=_MailMate_1A56C143-9920-46DA-97C7-9F4A3849BEFB_=-- From nobody Fri Oct 26 02:15:19 2018 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 BFC80128CF2 for ; Fri, 26 Oct 2018 02:15:17 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgjSdi0T464D for ; Fri, 26 Oct 2018 02:15:15 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:638:809:ff20:130:149:152:141]) by ietfa.amsl.com (Postfix) with ESMTP id 5859B1293FB for ; Fri, 26 Oct 2018 02:15:13 -0700 (PDT) Received: from [130.149.220.45] (esmeralda.net.t-labs.tu-berlin.de [130.149.220.45]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id 291D920272 for ; Fri, 26 Oct 2018 11:15:11 +0200 (CEST) To: taps@ietf.org References: <154022748014.6890.5464777930050299508@ietfa.amsl.com> From: Theresa Enghardt Openpgp: preference=signencrypt Autocrypt: addr=theresa@inet.tu-berlin.de; prefer-encrypt=mutual; keydata= xsBNBE2ktqYBCAC+3mnQMUTPJEPjKD0EaURx171qWkp4M60Zk97aeG6hSDU2GJAKG/IZ9/w7 NXLZxlfmfK9+y4Fia3aHfdhtdh+hZ/nkzhNHEahpt+coChrcaM/xyLmw7QOfYw6pLEe/snPY bdeiNdg3dsM8SFbLPvzs0REiAS9aVsux7fyDFmmJ4BGqJtjSzAv+l3X508wGeKgbUxT1Ceb5 /6DT5U1cPeSSCsXghHi5pcIfwW0KU00Ug56k3gSIRZ3YlahtBXVyIGOfPMLcvxpVypNejCt3 haLfbK6zI1GFHW39ietsk12DEODM0GiOhlCEx0qL+JxmR+A/IHKkINe5aj8Tl/Ie9TfZABEB AAHNKFRoZXJlc2EgRW5naGFyZHQgPHRoZXJlc2FAc29tZXNlcnZlci5kZT7CwJgEEwEKAEIC GyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAhkBFiEE7xG3phZ0Plgk2BDpgz007xx2oPcF AlqgJ4EFCRC919sACgkQgz007xx2oPf5lAf/VKgireR+/7Pg+sNigE+25bYRjezB5CPz0rPk YQndvFNbegCPKIXlIUbCwAuj1BW4qgBvNzq3X6lsGQ+wE30bKxnRLfjNW4PDGqbT2SsdJPOH b4KOnwaZjLGkDXaqABmkejHEg2hyi1on5JHEWFKz24qsFGosSCH3ZrOrKo9boZS5Md6+J0P/ y8gSCgS2ABYuo9VhyoDWD9hDRF1d7mvRUzACVieSxTOgwFsTCfsNmRnlZjTKjrEWhgpG1W0v 2J6xthOaE9J4TA2uWIi4t6+gvbiseXclzu2KxKrxy+xXEDD7hUb+JvvVLKkhjXwqbyx3lQoS Vy/MEw80YybnHyYFYM7ATQRNpLamAQgAz5qAZBAFqJoFLTYeKHqy149JBtI8Oh4Ywktc1ExL uZDP7KPjLKGJv5ebMHblU579BiSMgj35Bw4H7V5zzgB2DzklLG61ZAjNd6uFEdFNLtf+2/Qq jVqqZjlXfCIlNeq+2U002q1SPzLniX9xm4uHUfL3dZqgOkAWa4fB/X1WmMcXMQX+Npwv9plE JOLdd1J6/XtwsUmnJnkicDiuyb7G8v4fPDJtc0m2sQIdXSL71VIHbme5w8p8OYN41q0vqefB aMp0PnppG/K32Xa9/zW5fTKMcXxcCFZH7Ww2tpnFqZe0zhrL9UjAfQsgXurujk0OvEFhhkQo nVRXUYmLTM0EXQARAQABwsBlBBgBAgAPAhsMBQJW+lhqBQkNGAjEAAoJEIM9NO8cdqD3fK4H /2Jk05xp6eL8jTQO4kpdZtngbP4dxZ9vwgbdmKsN5Rln88Xm5HH8GXHzxU0hY2pLU0QoPzE5 B//tEbM34tYLNXSQScc8UVvfsh3Qup4OmagkAGHPs3lSLnvX17IUaDuhjJcHeDNE0h3ZmhLc XaHijcuxn2OvCVT3qpE5C6voC/IwNQSQGyPogDxfD1IpL7u3aqAmGnuIkLLCnm8DFl3wcGur w3wbVLuMV/WHXvIVgvvjf0fWCKBiyDMimVr2tPEMv/MgRU7BcuMvJx8I4fnC03Wm0BD6Wti+ 01JN0gcYBRNUHnEl/IzOo8A0lHSV5V9Hd/X5G7kkslTSK1xLZMabOCTCwHwEGAEKACYCGwwW IQTvEbemFnQ+WCTYEOmDPTTvHHag9wUCWqAnjQUJEL3X5wAKCRCDPTTvHHag99GLB/0f0E0h NezbAsWOt6PvBXxegI7nPeI3hNN4rP/ZcDQJCvs6OSpsSSWWeUa/LAk6wKyt+JwcYv55eTu1 Zd/wsybRA4DWkSADug3Kcans7rlYbiQ33eP08UD/ST6eSpa3O27DcoEClKrK0QFpqrB144bm YJZhrACOlIgjYGj6v0iCEf2aIyACxPTjg4+PdAwpJkDNMTMd6QS5hr8Bmp8XEsUTbtZ0NmkS rO9De5ogNtjHkdtP7G0sklzOkQ12JPDK8c3g/A1J9ZpzK/VMDtYzZC6yCzk5VHBokhDKm+gZ GXRhrBoceDGkuCz/HevYiqadNdOF5r5bH+JhKs8UW/isRtL/ Message-ID: <6fb7824e-b24e-1b88-f8eb-3e8005906e1b@inet.tu-berlin.de> Date: Fri, 26 Oct 2018 11:15:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <154022748014.6890.5464777930050299508@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transport-security-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 09:15:18 -0000 Dear TAPS, having shepherded the minset draft, and, in the process, having seen a lot of discussion around security, where we mostly pointed to the security survey draft, I gave this draft another read in the current version, with a focus on Section 5. Thanks for the update, this document was a good read. However, I have some comments, which I'm sharing now rather than later, just in case there's anything which is better discussed in-person in Bangkok. Right now, the abstract states that this document is a survey of security protocols. I suggest to add text saying that the document also provides a minimal set of security features. Essentially, this document and minset together cover the "minimum requirements of a secure transport system". In Section 5, the document groups security features into mandatory and optional features, and states their transport dependency and application dependency. Application dependency, for me, relates to whether a feature is "functional", "optimizing", or "automatable" (in minset terminology). For example, if there is no application dependency, the feature is "automatable" and does not have to be exposed to the application. In contrast, a "function" feature needs to be exposed to the application. In Section 5.1, I am missing transport dependency and application dependency for the mandatory transport features. For example, I would be interested to know what is the minimum that the transport system needs to expose to the application for public-key based authentication? In Section 5.1, what is "unilateral responder authentication", which I haven't found in other places in the document under this name? In Section 5.2, "Session caching and management" has no application dependency. However, later in Section 6.1, we do expose Session Cache Management to the application. My interpretation is that this is just an "optimizing" feature, which is why there is no application dependency, but it is still useful to expose. It might help to make this explicit in the text. In Section 5, do we want to mention any security features related to integrity protection? As far as I can see, none of the protocols we survey provide any features explicitly providing privacy. Maybe this is worth highlighting in the Security considerations section, beyond saying that no claims of privacy properties are made. Finally, I would be in favor of asking for a Secdir early review to make sure we're not missing anything in the survey. Thank you again for this draft. I really appreciate that we're discussing transport security features in this way. Best, Theresa From nobody Fri Oct 26 10:46:45 2018 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 890EE12870E; Fri, 26 Oct 2018 10:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.171 X-Spam-Level: X-Spam-Status: No, score=-1.171 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 Cf3Ssuuo1jmK; Fri, 26 Oct 2018 10:46:42 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 CA66C130E76; Fri, 26 Oct 2018 10:46:38 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.23/8.16.0.23) with SMTP id w9QHfg5p008889; Fri, 26 Oct 2018 18:46:37 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=jan2016.eng; bh=5s+TxZPCq8IekV+eAX6jyn3QA7pkCMY+IFCKAUoJ6wk=; b=iQ50AepjzQQb5ArIGuOLOceB6pMh45wmPKeQR1eBpf5eoGats3HfrMzX0X3yAN3d6rZ4 fKW+VCIF7JK1WyNnUSGmsbFYo0CCNpBY8tv0PcaYIBATCRSC5IGheg3er85A9cxj7IhH 0/IUKh4YKvyl9XZsgRlcVu2/k8rputucjns9uAKvfZ2/rOc4GdB7Nu/gjCt/17d32gpZ zbWkYqDJMFLTgH9TSDPYmxG2Du7co9GW5xFMhM31BJJWltQ6w/Xns08+zaIP8xvekgXU e8XM8ZV/yDuVJCTbzhZXGv8w+/wPuyJ2AQISU8+5Emn4qDn/g7hsQgf68XkNmQPtTY3x CQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2nc0rr9bjm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Oct 2018 18:46:37 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w9QHZ2bQ004704; Fri, 26 Oct 2018 13:46:36 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2n7ypvjqbm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 26 Oct 2018 13:46:35 -0400 Received: from [172.19.34.51] (172.19.34.51) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 26 Oct 2018 10:46:33 -0700 From: Aaron Falk To: CC: , Theresa Enghardt Date: Fri, 26 Oct 2018 13:46:25 -0400 X-Mailer: MailMate (1.12r5525) Message-ID: In-Reply-To: <6fb7824e-b24e-1b88-f8eb-3e8005906e1b@inet.tu-berlin.de> References: <154022748014.6890.5464777930050299508@ietfa.amsl.com> <6fb7824e-b24e-1b88-f8eb-3e8005906e1b@inet.tu-berlin.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_88764336-B289-4CD7-B605-1D25AD99613C_=" X-Originating-IP: [172.19.34.51] X-ClientProxiedBy: usma1ex-cas4.msg.corp.akamai.com (172.27.123.57) To ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-26_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=13 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=877 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810260147 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-10-26_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=13 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=874 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810260149 Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transport-security-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 17:46:44 -0000 --=_MailMate_88764336-B289-4CD7-B605-1D25AD99613C_= Content-Type: text/plain; format=flowed; markup=markdown Dear Authors, We agreed at the last IETF that the authors would send a note when this draft was ready for SecDir review. Is it ready? Do you want to talk about Theresa's comments in Bangkok first? --aaron On 26 Oct 2018, at 5:15, Theresa Enghardt wrote: > Dear TAPS, > > having shepherded the minset draft, and, in the process, having seen a > lot of discussion around security, where we mostly pointed to the > security survey draft, I gave this draft another read in the current > version, with a focus on Section 5. > > Thanks for the update, this document was a good read. > > However, I have some comments, which I'm sharing now rather than > later, > just in case there's anything which is better discussed in-person in > Bangkok. > > > Right now, the abstract states that this document is a survey of > security protocols. I suggest to add text saying that the document > also > provides a minimal set of security features. Essentially, this > document > and minset together cover the "minimum requirements of a secure > transport system". > > > In Section 5, the document groups security features into mandatory and > optional features, and states their transport dependency and > application > dependency. Application dependency, for me, relates to whether a > feature > is "functional", "optimizing", or "automatable" (in minset > terminology). > For example, if there is no application dependency, the feature is > "automatable" and does not have to be exposed to the application. In > contrast, a "function" feature needs to be exposed to the application. > > In Section 5.1, I am missing transport dependency and application > dependency for the mandatory transport features. For example, I would > be > interested to know what is the minimum that the transport system needs > to expose to the application for public-key based authentication? > > In Section 5.1, what is "unilateral responder authentication", which I > haven't found in other places in the document under this name? > > In Section 5.2, "Session caching and management" has no application > dependency. However, later in Section 6.1, we do expose Session Cache > Management to the application. My interpretation is that this is just > an > "optimizing" feature, which is why there is no application dependency, > but it is still useful to expose. It might help to make this explicit > in > the text. > > In Section 5, do we want to mention any security features related to > integrity protection? > > > As far as I can see, none of the protocols we survey provide any > features explicitly providing privacy. Maybe this is worth > highlighting > in the Security considerations section, beyond saying that no claims > of > privacy properties are made. > > > Finally, I would be in favor of asking for a Secdir early review to > make > sure we're not missing anything in the survey. > > > Thank you again for this draft. I really appreciate that we're > discussing transport security features in this way. > > > Best, > Theresa --=_MailMate_88764336-B289-4CD7-B605-1D25AD99613C_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Dear Authors,

We agreed at the last IETF that the authors would send a = note when this draft was ready for SecDir review. Is it ready? Do you w= ant to talk about Theresa's comments in Bangkok first?

--aaron

On 26 Oct 2018, at 5:15, Theresa Enghardt wrote:

Dear TAPS,

having shepherded the minset draft, and, in the process, having seen a lot of discussion around security, where we mostly pointed to the
security survey draft, I gave this draft another read in the current
version, with a focus on Section 5.

Thanks for the update, this document was a good read.

However, I have some comments, which I'm sharing now rather than later, just in case there's anything which is better discussed in-person in
Bangkok.


Right now, the abstract states that this document is a survey of
security protocols. I suggest to add text saying that the document also provides a minimal set of security features. Essentially, this document and minset together cover the "minimum requirements of a secure
transport system".


In Section 5, the document groups security features into mandatory and optional features, and states their transport dependency and application<= br> dependency. Application dependency, for me, relates to whether a feature<= br> is "functional", "optimizing", or "automatable" (in minset terminology).<= br> For example, if there is no application dependency, the feature is
"automatable" and does not have to be exposed to the application. In
contrast, a "function" feature needs to be exposed to the application.
In Section 5.1, I am missing transport dependency and application
dependency for the mandatory transport features. For example, I would be<= br> interested to know what is the minimum that the transport system needs to expose to the application for public-key based authentication?

In Section 5.1, what is "unilateral responder authentication", which I haven't found in other places in the document under this name?

In Section 5.2, "Session caching and management" has no application
dependency. However, later in Section 6.1, we do expose Session Cache
= Management to the application. My interpretation is that this is just an<= br> "optimizing" feature, which is why there is no application dependency, but it is still useful to expose. It might help to make this explicit in<= br> the text.

In Section 5, do we want to mention any security features related to
integrity protection?


As far as I can see, none of the protocols we survey provide any
features explicitly providing privacy. Maybe this is worth highlighting in the Security considerations section, beyond saying that no claims of privacy properties are made.


Finally, I would be in favor of asking for a Secdir early review to make<= br> sure we're not missing anything in the survey.


Thank you again for this draft. I really appreciate that we're
discussing transport security features in this way.


Best,
Theresa

--=_MailMate_88764336-B289-4CD7-B605-1D25AD99613C_=-- From nobody Fri Oct 26 22:06:02 2018 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 4ACD81292AD for ; Fri, 26 Oct 2018 22:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 I_gckXGU9iA7 for ; Fri, 26 Oct 2018 22:05:59 -0700 (PDT) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (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 B16FC12785F for ; Fri, 26 Oct 2018 22:05:58 -0700 (PDT) Received: by mail-vs1-xe2d.google.com with SMTP id j20so2126670vso.8 for ; Fri, 26 Oct 2018 22:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SXIHPG/G3vRFHeyTHEjf42JDB+ro0jJFn/nNv0npAE0=; b=QwjxPzRZy7rstcqWHQKiKcqgnpORCyqEjOoPi2DuKxDeegtY8eznxPM8L/hjVpmP49 K8hoBYn475ZUd6CA7oq+P02G6lLEn8egtiIxPB/euwcTuCaS3gUH9QqyfXyHF8nQouhE unXJVXI9dmpW5bXZDG/x+0mjFFQelnjYXT93uidSJ28+k4Lp4goHdTUdGJkqmmSFb1BK CBTGEmBpARpwC+aYcHXerMuCc2RaqNukhWPDuOL+lXgWndJkVXFV+Q0fjsx5bXP8hBTs F1u2j90WKZTy9WaRD4X88DiaHgwf11h7maQVgjzwZzMDv0pilzx/pPFGMlEANy+vwfHb 6/uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SXIHPG/G3vRFHeyTHEjf42JDB+ro0jJFn/nNv0npAE0=; b=EkbmgCEom6fZxh/VYXvhsBzZ1cqCJfZGfBD9zRzOIFXthsW5S5iJs3LrcU+igiSuc3 eRCSHlIP/UI5MyQp15A3FqBO1ACggcTwhXfTd3iJmTE0Ipl7KtX169BbJAD4dJX4UL7G 2cOSNRxDuRp0JOlj8s8M04TP9f5WCZZ6tGobXY4zGM+Rg/pIZ/Q+Z6cRgp5p6OnQIA+/ GLVzqsO89MNHq1vqoGHAtUnLgL9BaBSlaPmP0mQ8tt+5zMyKuHyx3GFONlLaAT/XB/e+ 1KchPD6w7Vdju03jIY905NG5rstJ6e6pu8j8jhWnwt86YG28dxCqtDbYKyvgHmVxLswP BGlg== X-Gm-Message-State: AGRZ1gI1YNsxZe8/pXE1RxRma1I2/sp44G1Z57Igyu/reHCJx/rL/DSv aWVB5AKCUD1I2GzboUi1xUI5xOYLCbAmCJ87eyFJfQ== X-Google-Smtp-Source: AJdET5dRy5pRuG76F+M5dAu0FSvdSFwrN3qfmyF7MF1yaB0co0NBe2YuVWxOfpBeaChu5wWvOi8R3fTxtOgtprNShfU= X-Received: by 2002:a67:d68f:: with SMTP id o15mr1109391vsj.174.1540616757576; Fri, 26 Oct 2018 22:05:57 -0700 (PDT) MIME-Version: 1.0 References: <154022748014.6890.5464777930050299508@ietfa.amsl.com> <6fb7824e-b24e-1b88-f8eb-3e8005906e1b@inet.tu-berlin.de> In-Reply-To: <6fb7824e-b24e-1b88-f8eb-3e8005906e1b@inet.tu-berlin.de> From: Christopher Wood Date: Fri, 26 Oct 2018 22:05:46 -0700 Message-ID: To: Theresa Enghardt Cc: taps@ietf.org Content-Type: multipart/alternative; boundary="0000000000009208a405792eca01" Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transport-security-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 05:06:01 -0000 --0000000000009208a405792eca01 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Theresa, Please see inline below. On Fri, Oct 26, 2018 at 2:15 AM Theresa Enghardt wrote: > Dear TAPS, > > having shepherded the minset draft, and, in the process, having seen a > lot of discussion around security, where we mostly pointed to the > security survey draft, I gave this draft another read in the current > version, with a focus on Section 5. > > Thanks for the update, this document was a good read. > > However, I have some comments, which I'm sharing now rather than later, > just in case there's anything which is better discussed in-person in > Bangkok. > > > Right now, the abstract states that this document is a survey of > security protocols. I suggest to add text saying that the document also > provides a minimal set of security features. Essentially, this document > and minset together cover the "minimum requirements of a secure > transport system". That=E2=80=99s a good suggestion. I=E2=80=99ll add it. > In Section 5, the document groups security features into mandatory and > optional features, and states their transport dependency and application > dependency. Application dependency, for me, relates to whether a feature > is "functional", "optimizing", or "automatable" (in minset terminology). > For example, if there is no application dependency, the feature is > "automatable" and does not have to be exposed to the application. In > contrast, a "function" feature needs to be exposed to the application. What specifically do you think should change here? > > In Section 5.1, I am missing transport dependency and application > dependency for the mandatory transport features. For example, I would be > interested to know what is the minimum that the transport system needs > to expose to the application for public-key based authentication? The mandatory features are those which must be provided regardless of the transport features. Thus, we list no transport dependencies. > > In Section 5.1, what is "unilateral responder authentication", which I > haven't found in other places in the document under this name? This is an oversight that I will correct. It refers to the overwhelmingly common case wherein servers are the only party authenticated in a protocol. > In Section 5.2, "Session caching and management" has no application > dependency. However, later in Section 6.1, we do expose Session Cache > Management to the application. My interpretation is that this is just an > "optimizing" feature, which is why there is no application dependency, > but it is still useful to expose. It might help to make this explicit in > the text. That=E2=80=99s a good suggestion, yes. I=E2=80=99ll note that this is relat= ed to the ongoing Cache Context discussion for the TAPS drafts. > > In Section 5, do we want to mention any security features related to > integrity protection? No, I don=E2=80=99t think so. What would be the purpose? > As far as I can see, none of the protocols we survey provide any > features explicitly providing privacy. Maybe this is worth highlighting > in the Security considerations section, beyond saying that no claims of > privacy properties are made. This is a tough one. Depending on one=E2=80=99s level of pessimism, none of= these protocols provide much in the way of privacy. However, in the case of TLS, we often think of privacy as confidentiality of data involved. Information is often leaked in other ways, e.g., via the SNI. It all boils down to your definition of privacy, of which we have no formal definition. Thus, I=E2=80= =99m hesitant to say more than, e.g., =E2=80=9Cwe do not consider privacy aspect= s of security protocols.=E2=80=9D > > > Finally, I would be in favor of asking for a Secdir early review to make > sure we're not missing anything in the survey. +1 > > > Thank you again for this draft. I really appreciate that we're > discussing transport security features in this way. And thank you for the comments! Best, Chris --0000000000009208a405792eca01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Theresa,

<= div dir=3D"auto">Please see inline below.

On Fri, Oct 26, 2018 at 2:15 AM Theresa Enghardt &= lt;theresa@inet.tu-berlin.de> wrote:
Dear TAPS,

having shepherded the minset draft, and, in the process, having seen a
lot of discussion around security, where we mostly pointed to the
security survey draft, I gave this draft another read in the current
version, with a focus on Section 5.

Thanks for the update, this document was a good read.

However, I have some comments, which I'm sharing now rather than later,=
just in case there's anything which is better discussed in-person in Bangkok.


Right now, the abstract states that this document is a survey of
security protocols. I suggest to add text saying that the document also
provides a minimal set of security features. Essentially, this document
and minset together cover the "minimum requirements of a secure
transport system".



In Section 5, the document groups security features into mandatory and
optional features, and states their transport dependency and application dependency. Application dependency, for me, relates to whether a feature is "functional", "optimizing", or "automatable&quo= t; (in minset terminology).
For example, if there is no application dependency, the feature is
"automatable" and does not have to be exposed to the application.= In
contrast, a "function" feature needs to be exposed to the applica= tion.




In Section 5.1, I am missing transport dependency and application
dependency for the mandatory transport features. For example, I would be interested to know what is the minimum that the transport system needs
to expose to the application for public-key based authentication?

The mandatory features are= those which must be provided regardless of the transport features. Thus, w= e list no transport dependencies.=C2=A0



In Section 5.1, what is "unilateral responder authentication", wh= ich I
haven't found in other places in the document under this name?

This is an oversight that= I will correct. It refers to the overwhelmingly common case wherein server= s are the only party authenticated in a protocol.

In Section 5.2, "Session caching and management" has no applicati= on
dependency. However, later in Section 6.1, we do expose Session Cache
Management to the application. My interpretation is that this is just an "optimizing" feature, which is why there is no application depend= ency,
but it is still useful to expose. It might help to make this explicit in the text.

That=E2= =80=99s a good suggestion, yes. I=E2=80=99ll note that this is related to t= he ongoing Cache Context discussion for the TAPS drafts.



In Section 5, do we want to mention any security features related to
integrity protection?

No, I don=E2=80=99t think so. What would be the purpose?


As far as I can see, none of the protocols we survey provide any
features explicitly providing privacy. Maybe this is worth highlighting
in the Security considerations section, beyond saying that no claims of
privacy properties are made.

This is a tough one. Depending on one=E2=80=99s level of pessim= ism, none of these protocols provide much in the way of privacy. However, i= n the case of TLS, we often think of privacy as confidentiality of data inv= olved. Information is often leaked in other ways, e.g., via the SNI. It all= boils down to your definition of privacy, of which we have no formal defin= ition. Thus, I=E2=80=99m hesitant to say more than, e.g., =E2=80=9Cwe do no= t consider privacy aspects of security protocols.=E2=80=9D




Finally, I would be in favor of asking for a Secdir early review to make sure we're not missing anything in the survey.

+1




Thank you again for this draft. I really appreciate that we're
discussing transport security features in this way.

And thank you for the comments!

--0000000000009208a405792eca01-- From nobody Fri Oct 26 22:08:04 2018 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 A444412DD85; Fri, 26 Oct 2018 22:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 TNpD5LKJf23T; Fri, 26 Oct 2018 22:08:00 -0700 (PDT) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 2B8B41292AD; Fri, 26 Oct 2018 22:08:00 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id q15so2144892vso.1; Fri, 26 Oct 2018 22:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Lgujw6CeK/SwnMRf80b8/+KgQwewbJEhQ4n7/fZ5eZk=; b=TMS59H327kccwKHen1Yry6+Af96AccqOZOPB0o+GYoHGSbvvKCNS/pbDLlQge0303f cQ5RMi1vWnk4hdAwrPNTeHim5BdkB6trLgeURTWpnkzVhArXFyCE+C215eBpqSWkSLKl G5831kyycsGjvLPY5n3xUuzzAw/VoRDwKP/csiQLt5rmLrsXxWoUziYC+OITQ62zdyNQ ZehSOst63CMlUqhmK0RrfR+6Og2ljPNewI4sgAhwSQ3FSBR2qP+TRW+EgkwY5SpbmQ0t cW9AwrgZxu5srKsxvOJwzhTFbbarbjkKknMDjuZLRBe6mKDBjtrMu+AxN/ivqrPrAFtw 22zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Lgujw6CeK/SwnMRf80b8/+KgQwewbJEhQ4n7/fZ5eZk=; b=RXnXDujiMktkn5HSovgnMKGsqneol6MwdEG0eua2bFXLUdoZeg2BkD2SUvPl73TL+6 0UvCiDz1pUWEEIYR0VKpdfyYMrA3+hnxuRI6ZU9SZecRkBPHFAQxpw/nZdv4RhfQ5VGX uXlP8alIYWLd04yjkmFtqI0Ofp/A6SQi9uf8L0tLGx1JL6yQRTz6cvuQPOACc2lU44Uw b0MDMHCyIPWO1c2wC2Oua+sdayPuF1L11DpzOkuwKQ32/3LMUhTfY+vLO1xPOXdEaGyu +bbhr7kGtV2o0EC8KQ3Wf8tU4wrIMvBEOXtBN5NBOvvgSOvpacCKMDDKRorIVYmRlIyQ Og3w== X-Gm-Message-State: AGRZ1gJrIyszc9L/qEo2OJLSDc1uwmaiZnzRlbF6SOkB6MW3qGpARVEr qNJKD4gFylD5F4c3/crtjjGPeVA2KYW87Lwuvo5VWA== X-Google-Smtp-Source: AJdET5fGGjZhcM6sUei+gNWkiER8tH0fTzndkOzJTxzqUEmbibKWC1lTH7udxFqXRAOPBvwAeuIPKeKuK3Rba832qHA= X-Received: by 2002:a67:eb45:: with SMTP id x5mr2826686vso.13.1540616878975; Fri, 26 Oct 2018 22:07:58 -0700 (PDT) MIME-Version: 1.0 References: <154022748014.6890.5464777930050299508@ietfa.amsl.com> <6fb7824e-b24e-1b88-f8eb-3e8005906e1b@inet.tu-berlin.de> In-Reply-To: From: Christopher Wood Date: Fri, 26 Oct 2018 22:07:47 -0700 Message-ID: To: Aaron Falk Cc: Theresa Enghardt , draft-ietf-taps-transport-security@ietf.org, taps@ietf.org Content-Type: multipart/alternative; boundary="000000000000ce70a405792ed1b3" Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transport-security-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 05:08:03 -0000 --000000000000ce70a405792ed1b3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Aaron, On Fri, Oct 26, 2018 at 10:46 AM Aaron Falk wrote: > Dear Authors, > > We agreed at the last IETF that the authors would send a note when this > draft was ready for SecDir review. Is it ready? Do you want to talk about > Theresa's comments in Bangkok first? > It is not yet ready. We will send it to SecDir when that changes. I don=E2= =80=99t think Theresa=E2=80=99s comments are blockers here. (I=E2=80=99ll spin a ne= w version with her comments for submission when the tracker reopen.) Best, Chris > --aaron > > On 26 Oct 2018, at 5:15, Theresa Enghardt wrote: > > Dear TAPS, > > having shepherded the minset draft, and, in the process, having seen a > lot of discussion around security, where we mostly pointed to the > security survey draft, I gave this draft another read in the current > version, with a focus on Section 5. > > Thanks for the update, this document was a good read. > > However, I have some comments, which I'm sharing now rather than later, > just in case there's anything which is better discussed in-person in > Bangkok. > > > Right now, the abstract states that this document is a survey of > security protocols. I suggest to add text saying that the document also > provides a minimal set of security features. Essentially, this document > and minset together cover the "minimum requirements of a secure > transport system". > > > In Section 5, the document groups security features into mandatory and > optional features, and states their transport dependency and application > dependency. Application dependency, for me, relates to whether a feature > is "functional", "optimizing", or "automatable" (in minset terminology). > For example, if there is no application dependency, the feature is > "automatable" and does not have to be exposed to the application. In > contrast, a "function" feature needs to be exposed to the application. > > In Section 5.1, I am missing transport dependency and application > dependency for the mandatory transport features. For example, I would be > interested to know what is the minimum that the transport system needs > to expose to the application for public-key based authentication? > > In Section 5.1, what is "unilateral responder authentication", which I > haven't found in other places in the document under this name? > > In Section 5.2, "Session caching and management" has no application > dependency. However, later in Section 6.1, we do expose Session Cache > Management to the application. My interpretation is that this is just an > "optimizing" feature, which is why there is no application dependency, > but it is still useful to expose. It might help to make this explicit in > the text. > > In Section 5, do we want to mention any security features related to > integrity protection? > > > As far as I can see, none of the protocols we survey provide any > features explicitly providing privacy. Maybe this is worth highlighting > in the Security considerations section, beyond saying that no claims of > privacy properties are made. > > > Finally, I would be in favor of asking for a Secdir early review to make > sure we're not missing anything in the survey. > > > Thank you again for this draft. I really appreciate that we're > discussing transport security features in this way. > > > Best, > Theresa > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > --000000000000ce70a405792ed1b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Aaron,

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

Dear Authors,

We agreed at the last IETF that the authors would send a no= te when this draft was ready for SecDir review. Is it ready? Do you want = to talk about Theresa's comments in Bangkok first?


It is not yet ready. We will send it to SecDir= when that changes. I don=E2=80=99t think Theresa=E2=80=99s comments are bl= ockers here. (I=E2=80=99ll spin a new version with her comments for submiss= ion when the tracker reopen.)

Best,
Chris

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

--aaron

On 26 Oct 2018, at 5:15, Theresa Enghardt wrote:

Dear TAPS,

having shepherded the minset draft, and, in the process, having seen a
lot of discussion around security, where we mostly pointed to the
security survey draft, I gave this draft another read in the current
version, with a focus on Section 5.

Thanks for the update, this document was a good read.

However, I have some comments, which I'm sharing now rather than later,=
just in case there's anything which is better discussed in-person in Bangkok.


Right now, the abstract states that this document is a survey of
security protocols. I suggest to add text saying that the document also
provides a minimal set of security features. Essentially, this document
and minset together cover the "minimum requirements of a secure
transport system".


In Section 5, the document groups security features into mandatory and
optional features, and states their transport dependency and application dependency. Application dependency, for me, relates to whether a feature is "functional", "optimizing", or "automatable&quo= t; (in minset terminology).
For example, if there is no application dependency, the feature is
"automatable" and does not have to be exposed to the application.= In
contrast, a "function" feature needs to be exposed to the applica= tion.

In Section 5.1, I am missing transport dependency and application
dependency for the mandatory transport features. For example, I would be interested to know what is the minimum that the transport system needs
to expose to the application for public-key based authentication?

In Section 5.1, what is "unilateral responder authentication", wh= ich I
haven't found in other places in the document under this name?

In Section 5.2, "Session caching and management" has no applicati= on
dependency. However, later in Section 6.1, we do expose Session Cache
Management to the application. My interpretation is that this is just an "optimizing" feature, which is why there is no application depend= ency,
but it is still useful to expose. It might help to make this explicit in the text.

In Section 5, do we want to mention any security features related to
integrity protection?


As far as I can see, none of the protocols we survey provide any
features explicitly providing privacy. Maybe this is worth highlighting
in the Security considerations section, beyond saying that no claims of
privacy properties are made.


Finally, I would be in favor of asking for a Secdir early review to make sure we're not missing anything in the survey.


Thank you again for this draft. I really appreciate that we're
discussing transport security features in this way.


Best,
Theresa

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
--000000000000ce70a405792ed1b3-- From nobody Sat Oct 27 01:03:40 2018 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 26816128D68 for ; Sat, 27 Oct 2018 01:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjCirKKemIYM for ; Sat, 27 Oct 2018 01:03:36 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:638:809:ff20:130:149:152:141]) by ietfa.amsl.com (Postfix) with ESMTP id D366312785F for ; Sat, 27 Oct 2018 01:03:35 -0700 (PDT) Received: from [192.168.178.160] (ip-95-222-96-215.hsi15.unitymediagroup.de [95.222.96.215]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id BD45320228; Sat, 27 Oct 2018 10:03:34 +0200 (CEST) To: Christopher Wood Cc: taps@ietf.org References: <154022748014.6890.5464777930050299508@ietfa.amsl.com> <6fb7824e-b24e-1b88-f8eb-3e8005906e1b@inet.tu-berlin.de> From: Theresa Enghardt Message-ID: <302b8870-2473-8ae3-b196-7c62850c97c1@inet.tu-berlin.de> Date: Sat, 27 Oct 2018 10:03:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------95E3DA2867DF4B90491D16D9" Content-Language: en-US Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transport-security-03.txt X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 08:03:38 -0000 This is a multi-part message in MIME format. --------------95E3DA2867DF4B90491D16D9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Chris, I'm replying to your questions inline: On 27.10.2018 07:05, Christopher Wood wrote: > > > In Section 5, the document groups security features into mandatory and > optional features, and states their transport dependency and > application > dependency. Application dependency, for me, relates to whether a > feature > is "functional", "optimizing", or "automatable" (in minset > terminology). > For example, if there is no application dependency, the feature is > "automatable" and does not have to be exposed to the application. In > contrast, a "function" feature needs to be exposed to the application. > > > What specifically do you think should change here? I suggest to define "application dependency" at the beginning of Section 5 -- it states what the application needs to know about the security feature for it to work, right? Is the application knowing about the feature always mandatory, or is this sometimes optional? Additionally, it might be useful to define what we mean by "transport dependency". If this means that a security feature can only be provided when a certain transport feature is in place, then I'm not sure I understand the transport dependency of "Source validation". Does this mean that source validation only works with streams? Or does it work differently depending on whether we have streams or datagrams? > > In Section 5.1, I am missing transport dependency and application > dependency for the mandatory transport features. For example, I > would be > interested to know what is the minimum that the transport system needs > to expose to the application for public-key based authentication? > > > The mandatory features are those which must be provided regardless of > the transport features. Thus, we list no transport dependencies. I see, and I think it would help me to reduce confusion to clarify this in the document. Are there any application dependencies for mandatory transport features? For example, I would expect at least public-key authentication and pre-shared key support to be application-dependent. > > > In Section 5, do we want to mention any security features related to > integrity protection? > > > No, I don’t think so. What would be the purpose? For example, "Record (channel or datagram) confidentiality and integrity" is defined as a security feature in Section 3, but then not mentioned in Section 5 at all. This surprises me as a reader, I would have expected it to be listed as a mandatory feature. Perhaps it is reflected as "segment or datagram encryption and authentication", which was actually the definition of "Record (channel or datagram) confidentiality and integrity" given in Section 3, but then I'm confused about the change in terminology. As another example: "Optional record integrity" shows up in Section 3 but not in Section 5. If Section 5 is just a subset of the security features listed in Section 3, I would appreciate some text in Section 5 to explain why these features were chosen and not others. > As far as I can see, none of the protocols we survey provide any > features explicitly providing privacy. Maybe this is worth > highlighting > in the Security considerations section, beyond saying that no > claims of > privacy properties are made. > > > This is a tough one. Depending on one’s level of pessimism, none of > these protocols provide much in the way of privacy. However, in the > case of TLS, we often think of privacy as confidentiality of data > involved. Information is often leaked in other ways, e.g., via the > SNI. It all boils down to your definition of privacy, of which we have > no formal definition. Thus, I’m hesitant to say more than, e.g., “we > do not consider privacy aspects of security protocols.” I understand, but I would also find it very interesting to at least mention, e.g., (reduction of) information leakage as an aspect related to privacy. I'm not sure it could be formalized as a security features, given the lack of formal definition of privacy. Thanks, and thanks for the discussion! Best, Theresa --------------95E3DA2867DF4B90491D16D9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Chris,

I'm replying to your questions inline:

On 27.10.2018 07:05, Christopher Wood wrote:

In Section 5, the document groups security features into mandatory and
optional features, and states their transport dependency and application
dependency. Application dependency, for me, relates to whether a feature
is "functional", "optimizing", or "automatable" (in minset terminology).
For example, if there is no application dependency, the feature is
"automatable" and does not have to be exposed to the application. In
contrast, a "function" feature needs to be exposed to the application.

What specifically do you think should change here?

I suggest to define "application dependency" at the beginning of Section 5 -- it states what the application needs to know about the security feature for it to work, right? Is the application knowing about the feature always mandatory, or is this sometimes optional?

Additionally, it might be useful to define what we mean by "transport dependency". If this means that a security feature can only be provided when a certain transport feature is in place, then I'm not sure I understand the transport dependency of "Source validation". Does this mean that source validation only works with streams? Or does it work differently depending on whether we have streams or datagrams?


In Section 5.1, I am missing transport dependency and application
dependency for the mandatory transport features. For example, I would be
interested to know what is the minimum that the transport system needs
to expose to the application for public-key based authentication?

The mandatory features are those which must be provided regardless of the transport features. Thus, we list no transport dependencies.

I see, and I think it would help me to reduce confusion to clarify this in the document.

Are there any application dependencies for mandatory transport features?
For example, I would expect at least public-key authentication and pre-shared key support to be application-dependent.



In Section 5, do we want to mention any security features related to
integrity protection?

No, I don’t think so. What would be the purpose?

For example, "Record (channel or datagram) confidentiality and integrity" is defined as a security feature in Section 3, but then not mentioned in Section 5 at all. This surprises me as a reader, I would have expected it to be listed as a mandatory feature.
Perhaps it is reflected as "segment or datagram encryption and authentication", which was actually the definition of "Record (channel or datagram) confidentiality and integrity" given in Section 3, but then I'm confused about the change in terminology.

As another example: "Optional record integrity" shows up in Section 3 but not in Section 5.

If Section 5 is just a subset of the security features listed in Section 3, I would appreciate some text in Section 5 to explain why these features were chosen and not others.

As far as I can see, none of the protocols we survey provide any
features explicitly providing privacy. Maybe this is worth highlighting
in the Security considerations section, beyond saying that no claims of
privacy properties are made.

This is a tough one. Depending on one’s level of pessimism, none of these protocols provide much in the way of privacy. However, in the case of TLS, we often think of privacy as confidentiality of data involved. Information is often leaked in other ways, e.g., via the SNI. It all boils down to your definition of privacy, of which we have no formal definition. Thus, I’m hesitant to say more than, e.g., “we do not consider privacy aspects of security protocols.”

I understand, but I would also find it very interesting to at least mention, e.g., (reduction of) information leakage as an aspect related to privacy. I'm not sure it could be formalized as a security features, given the lack of formal definition of privacy.


Thanks, and thanks for the discussion!

Best,
Theresa
--------------95E3DA2867DF4B90491D16D9-- From nobody Mon Oct 29 11:17:14 2018 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 F2268131059 for ; Mon, 29 Oct 2018 11:17:11 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 NQUxYsjBqeRg for ; Mon, 29 Oct 2018 11:17:10 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 9B588131023 for ; Mon, 29 Oct 2018 11:17:10 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id l41-v6so10380437qtl.8 for ; Mon, 29 Oct 2018 11:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=mt9aAnRxFBv+bfgpTtoox6x5y0XYQ+VWHvGWuGJ2mjM=; b=nFZPdav7kqpZZyxE49D5F61wKr/TIsMQw2lcLxcKUk7wWVsMSqs1etBcL4TDpyuj3Q /xBI8QZOjghamuX2nbkUh12uiDQsrS/1iGmrxzLPn68UswF7ZNXGC1qpqrXVxVx5UQ6L LxSdMOHLFuxre9Eh34rtHKUmE8VRU9AhMUkXjpXX5zY8WnIvwAQm3FzS8HjZZcY8lUKh RLoFezLs5/N8UsEO3XUXRBkUWa4V6DeuAPtxtMz/ZvkdhVufpHTuHpegWlPaWl8cN4DP xN7N7ddvZ5DaoiBblbvTcmRVJ+ljq9hNqjzaXEI5hPKK7U/QgrNYUz2DIrtu1oujkXqR pYwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=mt9aAnRxFBv+bfgpTtoox6x5y0XYQ+VWHvGWuGJ2mjM=; b=TdiAWXNiP1Xt5aFrUBtxoR++NiuMyY+WwRtE1SPW0mnXA3kLDG6a5Oe6O2VnXYeU+2 tD1ba2ixPg8ELwKnnemRlavGmWlzv+Znx3W3/rmwyGGxtRPOUFV+rjDJ3PTlZgt8Ike6 8KeEpWB9ugG2iyjdasToK6hgExgDaCC0ZPH9W70mWsbitjk+uFPP33f/MCCXF3YI7Voz K/qDbsDA2+Wmyxcao82pptaOJSn2H8TVFkP3gLq9GtD9ZzQabG1VMptFYYq+FpeRDu4J V2E2KkdHP29VTE/ceVk9cOIRTZywfxKsfu6zbDxO16QATRsb0nCSIDGSPkpwwqwXAtS0 YVQA== X-Gm-Message-State: AGRZ1gIVOUj8M7Hid+x+2WObhQQVcsDtng0plDuJQW2aY1+r7xMFkOOX cvCyWpFcCuabA7XSTKe7PakBh8YY X-Google-Smtp-Source: AJdET5cwQzn3Hft9T+CybIUHq3rDiHgPeOVl+tzyv+zAnvWz+sLQ2Keb/vluZGnHf8bwv+8l4cH37A== X-Received: by 2002:ac8:101a:: with SMTP id z26-v6mr13821380qti.308.1540837029143; Mon, 29 Oct 2018 11:17:09 -0700 (PDT) Received: from [172.19.37.111] ([2001:4878:a000:3000:d46b:8c0c:628b:32b3]) by smtp.gmail.com with ESMTPSA id l123-v6sm644735qkd.95.2018.10.29.11.17.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Oct 2018 11:17:08 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Mon, 29 Oct 2018 14:17:06 -0400 X-Mailer: MailMate (1.12r5525) Message-ID: <169BDE40-9870-4C56-BEE3-ECE93361BA8C@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_E50FCCAE-88B4-4A13-8876-764AF162E02E_=" Archived-At: Subject: [Taps] security parameters in draft-ietf-taps-interface X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 18:17:12 -0000 --=_MailMate_E50FCCAE-88B4-4A13-8876-764AF162E02E_= Content-Type: text/plain; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable In preface, I almost know enough about transport security to be = dangerous so I'm hoping someone more knowledgeable will clarify for = me... In section 5.3.1 of draft-ietf-taps-interface-02 a number of different = security parameters are proposed: ```` SecurityParameters.AddIdentity(identity) SecurityParameters.AddPrivateKey(privateKey, publicKey) SecurityParameters.AddSupportedGroup(secp256k1) SecurityParameters.AddCiphersuite(TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1= 305_SHA256) SecurityParameters.AddSignatureAlgorithm(ed25519) SecurityParameters.SetSessionCacheCapacity(MAX_CACHE_ELEMENTS) SecurityParameters.SetSessionCacheLifetime(SECONDS_PER_DAY) SecurityParameters.SetSessionCachePolicy(CachePolicyOneTimeUse) SecurityParameters.AddPreSharedKey(key, identity) ```` Aren't there relationships between them? Like you might have some = support for multiple identities, cyphersuites, and pre-shared keys but = they don't all work with each other. In other words, maybe this is more = of a tree than a flat space. --aaron --=_MailMate_E50FCCAE-88B4-4A13-8876-764AF162E02E_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

In preface, I almost know enough about transport security= to be dangerous so I'm hoping someone more knowledgeable will clarify fo= r me...

In section 5.3.1 of draft-ietf-taps-interface-02 a number= of different security parameters are proposed:

   SecurityParame=
ters.AddIdentity(identity)
   SecurityParameters.AddPrivateKey(privateKey, publicKey)

   SecurityParameters.AddSupportedGroup(secp256k1)
   SecurityParameters.AddCiphersuite(TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY13=
05_SHA256)
   SecurityParameters.AddSignatureAlgorithm(ed25519)

   SecurityParameters.SetSessionCacheCapacity(MAX_CACHE_ELEMENTS)
   SecurityParameters.SetSessionCacheLifetime(SECONDS_PER_DAY)
   SecurityParameters.SetSessionCachePolicy(CachePolicyOneTimeUse)

   SecurityParameters.AddPreSharedKey(key, identity)

Aren't there relationships between them? Like you might = have some support for multiple identities, cyphersuites, and pre-shared k= eys but they don't all work with each other. In other words, maybe this = is more of a tree than a flat space.

--aaron

--=_MailMate_E50FCCAE-88B4-4A13-8876-764AF162E02E_=-- From nobody Mon Oct 29 11:31:18 2018 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 B0432131069 for ; Mon, 29 Oct 2018 11:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 0cqzE1rkk7nt for ; Mon, 29 Oct 2018 11:31:11 -0700 (PDT) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 19C8A131059 for ; Mon, 29 Oct 2018 11:31:10 -0700 (PDT) Received: by mail-ua1-x92e.google.com with SMTP id d8so2435760ual.2 for ; Mon, 29 Oct 2018 11:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SCwMfLohusIzx30xEFQqtMyZ+BIgnDmkVdhlpaML0mc=; b=b6Ib0+Hoz04Z/ytLkOwSYxSyTQpksNA5qDHQWbweZPUN3sU6bi0pZyKD7fvu46a8nj LWPP1j5ocU1I0tylSBnHNEDxuMmFSofyRvXP1Y7xQJN0fKrdRo8j1eEeTUELLqIS87Wn +l06ILs9igOs78ELjNvkEamJRWudZncPYbi4c26ZtPlPCmY9IF9POTe2NK2PoBFc36Wk vEulG0SrTZaUTEHF9oup/EF6iZYoD1DASLI/yBWdQV1gLrXkxUjnqAFArSGxFIQAzf7P WXZYTymbnn3161GQJdeEfBHyP2AuW14wwAhAJyGgLwvYCPSiAN1onouVwD/c2HENAAKi 6u4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SCwMfLohusIzx30xEFQqtMyZ+BIgnDmkVdhlpaML0mc=; b=Geuc95V4Vcov0221jn+0Rm+kU/1TxqAz8ZOx5u3lxd9VpH97pownuw5jTlBXHqotHK H+wQcptxe52p1DjIvaaSyBg5+w2mj3ma1VgSEGonMycKOqYprBdnVF6awi+suVHNEgf3 GUDAQxCvx09rp1MHtQTB2Ju/BqZngk9GJJe+8DW/eFJ+PLtKqbGzbaLTWjpbx90pWQeY y2xIV+OeoGnFsI8kQFcGJrX2V5Ks1G+SQYy6S7A4qQ5VLkmRUBAGnEU3wJnuGJTEw7Dp X8Hq6UWCuYbjwCcNeQRUZKs+KUCKHDBndEyEPlrV+xorGLt+Anu6/bL6w20K6R4dN4Au G/gQ== X-Gm-Message-State: AGRZ1gLQMVS+ruL8aAFT+8Oefwgjq7t3VECEz93B3ekX584qsHJyEKEx 65yIT1XnbOzGYyXIjLd5ImVn1/ACgBm5BLvqjPk= X-Google-Smtp-Source: AJdET5eI1WbHCF1+R1L6avSaMgoqOCU4lYbpYYAXhii27NirRn5lKyAKmhzLIUHBYuy9G195JIkLH3p26fmA7zK/Jdw= X-Received: by 2002:ab0:4128:: with SMTP id j37mr6563322uad.58.1540837868934; Mon, 29 Oct 2018 11:31:08 -0700 (PDT) MIME-Version: 1.0 References: <169BDE40-9870-4C56-BEE3-ECE93361BA8C@gmail.com> In-Reply-To: <169BDE40-9870-4C56-BEE3-ECE93361BA8C@gmail.com> From: Christopher Wood Date: Mon, 29 Oct 2018 11:30:55 -0700 Message-ID: To: Aaron Falk Cc: taps WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Taps] security parameters in draft-ietf-taps-interface X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2018 18:31:13 -0000 On Mon, Oct 29, 2018 at 11:17 AM Aaron Falk wrote: > > In preface, I almost know enough about transport security to be dangerous so I'm hoping someone more knowledgeable will clarify for me... > > In section 5.3.1 of draft-ietf-taps-interface-02 a number of different security parameters are proposed: > > SecurityParameters.AddIdentity(identity) > SecurityParameters.AddPrivateKey(privateKey, publicKey) > > SecurityParameters.AddSupportedGroup(secp256k1) > SecurityParameters.AddCiphersuite(TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256) > SecurityParameters.AddSignatureAlgorithm(ed25519) > > SecurityParameters.SetSessionCacheCapacity(MAX_CACHE_ELEMENTS) > SecurityParameters.SetSessionCacheLifetime(SECONDS_PER_DAY) > SecurityParameters.SetSessionCachePolicy(CachePolicyOneTimeUse) > > SecurityParameters.AddPreSharedKey(key, identity) > > Aren't there relationships between them? Like you might have some support for multiple identities, cyphersuites, and pre-shared keys but they don't all work with each other. In other words, maybe this is more of a tree than a flat space. Yes, this is true. For example, depending on the type of identity (and private key) available, certain ciphersuites are not permitted. Describing these relationships is very protocol (TLS) specific, and thus it seems inappropriate to capture them here. I would rather add text simply noting the possible dependencies. The implementation draft can then expand on how certain configurations are not possible. Best, Chris