From nobody Fri Nov 1 01:02:17 2019 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 7660C120108 for ; Fri, 1 Nov 2019 01:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 Ln4yZGIWz-rt for ; Fri, 1 Nov 2019 01:02:14 -0700 (PDT) Received: from magpie.corvid.ch (magpie.corvid.ch [46.101.110.207]) (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 9860A1200F5 for ; Fri, 1 Nov 2019 01:02:14 -0700 (PDT) Received: from [127.0.0.1] (helo=magpie.corvid.ch) by magpie.corvid.ch with esmtp (Exim 4.92) (envelope-from ) id 1iQRqk-0007ne-Up for taps@ietf.org; Fri, 01 Nov 2019 08:00:02 +0000 Content-Type: multipart/alternative; boundary="===============8064069532700102288==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 01 Nov 2019 08:00:02 +0000 Archived-At: Subject: [Taps] Weekly github digest (TAPS GitHub Activity Digest) 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, 01 Nov 2019 08:02:17 -0000 --===============8064069532700102288== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * ietf-tapswg/api-drafts (+0/-3/=F0=9F=92=AC6) 4 issues received 6 new comments: - #145 Draft should point at implementations somewhere (2 by mwelzl, ther= i) https://github.com/ietf-tapswg/api-drafts/issues/145 [Implementation] [= ready for text] = - #356 Fix "Implementing maintenance" section (2 by mwelzl, tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/356 [Implementation] [= help wanted] = - #248 Implementation should separate out protocol-specific bits (1 by tf= pauly) https://github.com/ietf-tapswg/api-drafts/issues/248 [Implementation] = - #309 Clarification on queued receives (1 by MaxF12) https://github.com/ietf-tapswg/api-drafts/issues/309 [API] = 3 issues closed: - API Draft author editorial comments https://github.com/ietf-tapswg/api-= drafts/issues/313 [API] [ready for text] = - Implementation should separate out protocol-specific bits https://githu= b.com/ietf-tapswg/api-drafts/issues/248 [Implementation] = - Fix "Implementing maintenance" section https://github.com/ietf-tapswg/a= pi-drafts/issues/356 [Implementation] [help wanted] = Pull requests ------------- * ietf-tapswg/api-drafts (+1/-1/=F0=9F=92=AC0) 1 pull requests submitted: - Introduce pooled connections as optional implementation detail (by phil= sbln) https://github.com/ietf-tapswg/api-drafts/pull/358 = 1 pull requests merged: - Fixes #313 per Gorry's comments https://github.com/ietf-tapswg/api-drafts/pull/346 = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============8064069532700102288== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday November 01, 2019

Issues

ietf-tapswg/api-drafts (+0/-3/=F0=9F=92=AC6)

4 issues received 6 new comments:

3 issues closed:

Pull requests

ietf-tapswg/api-drafts (+1/-1/=F0=9F=92=AC0)

1 pull requests submitted:

1 pull requests merged:

Repositories tracked by this digest:

--===============8064069532700102288==-- From nobody Mon Nov 4 05:33:41 2019 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 081C5120227 for ; Mon, 4 Nov 2019 05:33:40 -0800 (PST) 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_HELO_NONE=0.001, 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 szJ-yOjyFrWb for ; Mon, 4 Nov 2019 05:33:37 -0800 (PST) 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 64C47120806 for ; Mon, 4 Nov 2019 05:33:37 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id r22so13825843qtt.2 for ; Mon, 04 Nov 2019 05:33:37 -0800 (PST) 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=eNvBPax0l8LbdLXo5DJlxXvU61K2zjGzGryBFXYW1go=; b=bCPljsYZT+gMYee5xD7ClsmdPe5anrcn4Ib1prczXklEj9rlB6Ui2lMO3DeCFUHs9q P4oyI7givDgTe7ErA+sFNepr35yhKlt7rEYtV7HKJe5u2AhUQUgcf3Ts+I6CYDN/+Y5I GaP3DGy6R9GdEf9VKoatgl6iikur8rH7l3YyeRI2op3j7KG9vxYZU9DGzv1qrJsrKy+7 75OleZCn63gReIdKspnvqyXlRSThO43dCOtjT+xBI5rUtggIQHMpoDfX45+ZyZtK2tYb TFM1QY+CmPEf0nTzQuUQIf+q0SL62q/bKGOUq33JrWce4pooyZ8tUvPslaQjCuCUpeXu H4iw== 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=eNvBPax0l8LbdLXo5DJlxXvU61K2zjGzGryBFXYW1go=; b=fMkuO0WNknj6W5JTFCJ8k5OYiOPHYQIN9Na9cTEJKgTHhUww1JzYuhWPAbqoAc8/JG 3jzh0rFBqAMhjPGbN0aZ5tKBGKOeyERsFhqyWqenhpW1kYWtCks38vmasBsDQwaOLaAD ysge2RIFG022ByFYrrYIfJTcq0cySKYqqqo1FMrBqSnyBZUj18xIg+nzJqgTCv4mp45K 4wq7OPyb87VCBc+eClCWdVFkko8e023SsDdXx4QqV9LSg1AW6CGIFHEbWAL8Yz0GL8E9 WbvwDnBySaHE2d7KlJZOd6yIKNuQcDPguCVAGEmFUdeCSaFy5mQxvjonwbSOdA2ePslb ZpTw== X-Gm-Message-State: APjAAAW9eKZkWuzusJsXr4zisISB/+MgaSg/JXOYxZz0I2Tt9Y+ICoHj 606+0VT9Tjy322ibiE7dP+zfVZ/e X-Google-Smtp-Source: APXvYqxMnXHTakbQXqB3TYfC4uHiG6F78omc/PbA6d+z64YNks8jHSy+Yx/4dqx7NUShxmTttUA6HQ== X-Received: by 2002:ac8:528a:: with SMTP id s10mr12097227qtn.361.1572874416151; Mon, 04 Nov 2019 05:33:36 -0800 (PST) Received: from [172.19.33.191] ([2601:184:4881:2420:291f:1c1d:304c:e55c]) by smtp.gmail.com with ESMTPSA id t66sm7742187qka.108.2019.11.04.05.33.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Nov 2019 05:33:35 -0800 (PST) From: "Aaron Falk" To: "taps WG" Cc: "Zaheduzzaman Sarker" Date: Mon, 04 Nov 2019 08:33:33 -0500 X-Mailer: MailMate (1.13r5655) Message-ID: <5C95DA93-91D3-44C1-BDF2-09667092FC12@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_183F0981-BF7D-4FD4-B160-695C84816283_=" Archived-At: Subject: [Taps] call for TAPS agenda topics 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, 04 Nov 2019 13:33:40 -0000 --=_MailMate_183F0981-BF7D-4FD4-B160-695C84816283_= Content-Type: text/plain; markup=markdown Ok, gang, what should we discuss in Singapore? --aaron --=_MailMate_183F0981-BF7D-4FD4-B160-695C84816283_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Ok, gang, what should we discuss in Singapore?

--aaron

--=_MailMate_183F0981-BF7D-4FD4-B160-695C84816283_=-- From nobody Mon Nov 4 10:18:26 2019 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 D536C1209C8 for ; Mon, 4 Nov 2019 10:18:24 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 3hzpqPzjoTZ1 for ; Mon, 4 Nov 2019 10:18:23 -0800 (PST) Received: from mail-yb1-xb2d.google.com (mail-yb1-xb2d.google.com [IPv6:2607:f8b0:4864:20::b2d]) (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 1048512091D for ; Mon, 4 Nov 2019 10:18:23 -0800 (PST) Received: by mail-yb1-xb2d.google.com with SMTP id h202so8199172ybg.13 for ; Mon, 04 Nov 2019 10:18:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PeUzNPC53yVwtXrXgAdElz3kTRuuaI5rKyBM0PJQLnU=; b=ZXwug/3ooweIDPD8O9yBbG3MDDpCOmed7F+i8eBRXTtSQUd0lXVGAit4QlFj34PgHb AjGBpahHIrnYui3XQdELHmdjdLRwjP+5j+xOflq1tcyqhkRHYUMilDjBr3wJD67FrOMY OxqQos5AYsNGtXmK2TWSZoYRzi3UMz4NuZ6Gk= 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=PeUzNPC53yVwtXrXgAdElz3kTRuuaI5rKyBM0PJQLnU=; b=Rdjx9p+9OjmBJ5JG/ti4qxYPapW9uz54oI9TC4szCTSsOWrjboUxUfO3+ZIxAwu5yv cDWn1/2r1ZwNVYPbrkH7UCbx4ZMz7TzCoSHzLkRITmB8VP7slcwOJFWjbWfRzCHDhxsU qOShur8J7kAF6po6OYw4wYlLOFaryc6ohLPLQjil+zNgdvALVId8WGGCbHAGD1NaYSK8 RCWnovteQYto3ZjcYhZpZAUwftn7KpjOAwd3XsnmLTdXTxvCcEi5oGxM/sUTVvtvO/+R NG6ftcKjajvGfyfUc09r9GADQ7fxrM+B++Nb0+lOVMO8LmWW6qCgpWfus+CCX2c+2a97 rszA== X-Gm-Message-State: APjAAAV/T8bIGsghpuN1kz5dEOSjhrWCRgtVJFjoQlVcPHTfPpTLc9bc m1QkpK1NXqosFGQxPzfz+ReaAtLTbJVgNjds2wd/Bv6u1MI= X-Google-Smtp-Source: APXvYqwncDb8Viv/HJi1Ug4qOL59HuACksgvdeHCkXRNCFi9SGwxaHEtKw3ogQ+S/szLi2LilK+fEg1djZ+c/7v1ZHU= X-Received: by 2002:a25:bdd4:: with SMTP id g20mr23154854ybk.127.1572891501897; Mon, 04 Nov 2019 10:18:21 -0800 (PST) MIME-Version: 1.0 References: <5C95DA93-91D3-44C1-BDF2-09667092FC12@gmail.com> In-Reply-To: <5C95DA93-91D3-44C1-BDF2-09667092FC12@gmail.com> From: Kyle Rose Date: Mon, 4 Nov 2019 13:18:10 -0500 Message-ID: To: Aaron Falk Cc: taps WG , Zaheduzzaman Sarker Content-Type: multipart/alternative; boundary="0000000000003dbada059689571f" Archived-At: Subject: Re: [Taps] call for TAPS agenda topics 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, 04 Nov 2019 18:18:25 -0000 --0000000000003dbada059689571f Content-Type: text/plain; charset="UTF-8" Evidently, the transport security document. On Mon, Nov 4, 2019 at 8:33 AM Aaron Falk wrote: > Ok, gang, what should we discuss in Singapore? > > --aaron > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > --0000000000003dbada059689571f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Evidently, the transport security document.

<= div class=3D"gmail_quote">
On Mon, Nov= 4, 2019 at 8:33 AM Aaron Falk <= aaron.falk@gmail.com> wrote:

Ok, gang, what should we discuss in Singapore?

--aaron

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
--0000000000003dbada059689571f-- From nobody Mon Nov 4 12:26:59 2019 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 9502A120843; Mon, 4 Nov 2019 12:26:53 -0800 (PST) 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.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: taps@ietf.org Message-ID: <157289921357.13984.6568141490003639945@ietfa.amsl.com> Date: Mon, 04 Nov 2019 12:26:53 -0800 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-arch-05.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, 04 Nov 2019 20:26:54 -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-05.txt Pages : 26 Date : 2019-11-04 Abstract: This document provides an overview of the architecture of Transport Services, a model for exposing transport protocol features to applications for network communication. In contrast to what is provided by most existing Application Programming Interfaces (APIs), Transport Services is based on an asynchronous, event-driven interaction pattern; it uses messages for representing data transfer to applications; and it assumes an implementation that can use multiple IP addresses, multiple protocols, and multiple paths, and provide multiple application streams. This document further defines the common set of terminology and concepts to be used in definitions of Transport Services APIs and implementations. 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-taps-arch-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-arch-05 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 Nov 4 12:28:09 2019 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 5CA80120125; Mon, 4 Nov 2019 12:28:03 -0800 (PST) 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.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: taps@ietf.org Message-ID: <157289928334.13956.6694151802210616620@ietfa.amsl.com> Date: Mon, 04 Nov 2019 12:28:03 -0800 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-interface-05.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, 04 Nov 2019 20:28:03 -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 Tommy Pauly Filename : draft-ietf-taps-interface-05.txt Pages : 64 Date : 2019-11-04 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-taps-interface-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-interface-05 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 Nov 4 12:28:55 2019 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 DD3DF120219; Mon, 4 Nov 2019 12:28:45 -0800 (PST) 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.108.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: taps@ietf.org Message-ID: <157289932586.13868.15421674158123388423@ietfa.amsl.com> Date: Mon, 04 Nov 2019 12:28:45 -0800 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-impl-05.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, 04 Nov 2019 20:28:46 -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-05.txt Pages : 48 Date : 2019-11-04 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-taps-impl-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-impl-05 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 Nov 4 12:31:51 2019 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 5F4FD120233 for ; Mon, 4 Nov 2019 12:31:49 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, 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 ysmi8gBjhmnb for ; Mon, 4 Nov 2019 12:31:48 -0800 (PST) Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 E707E120125 for ; Mon, 4 Nov 2019 12:31:47 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id xA4KQaEM027707; Mon, 4 Nov 2019 12:31:42 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=hF5FTT8sziMyPb2TD9BxBQ8iHZSYoC1BGShnKVNNOeY=; b=dQwW2Vh9V3shSJU1vyviidNQlhdbw8assnc1RGFhjd0SFmm9mhgxEV7jYzsTsHLquKkN 496TaVKRSOfNB7M4/iLezWx2ZfXDR4QSz8nqL79wXCg4KYTvoBa0Y3JHDBGAR02IFTlO qXIP1oF3PpopfTi5/N/knOqo5mGhLdx29oXAGqC4aqdjVs5kHCZVTArHiN8713ohWqdO MQVkzWaWyU/tV1G+1RZlD0cbFMKFBOFag1YJivbSHthPPaoWcg50YO8d9fOIpQ7x9ZxQ 3vZS9eNMLF+KU72jRr0P/HrwOAD1CEXf1jPOPxQdbDrhwPu7JUwf06V+x7iPsMhHrCY8 oQ== Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2w18r7rwma-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 04 Nov 2019 12:31:42 -0800 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q0G00CLLP0UI0A0@mr2-mtap-s03.rno.apple.com>; Mon, 04 Nov 2019 12:31:42 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q0G00C00O4D7200@nwk-mmpp-sz12.apple.com>; Mon, 04 Nov 2019 12:31:42 -0800 (PST) X-Va-A: X-Va-T-CD: 47a77c38fd385c8cb889518f364fbac2 X-Va-E-CD: 958043bbad085a95e0b3339c77a12d53 X-Va-R-CD: 2f3cf7ed5e248def8b8f40b54f4181de X-Va-CD: 0 X-Va-ID: 43ffb7e5-b10a-4eff-90ce-693f4ba6722c X-V-A: X-V-T-CD: 47a77c38fd385c8cb889518f364fbac2 X-V-E-CD: 958043bbad085a95e0b3339c77a12d53 X-V-R-CD: 2f3cf7ed5e248def8b8f40b54f4181de X-V-CD: 0 X-V-ID: 223f00f4-55f9-4493-8384-4cbac28a9801 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-04_11:,, signatures=0 Received: from [17.230.5.121] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q0G001OTP0T2H00@nwk-mmpp-sz12.apple.com>; Mon, 04 Nov 2019 12:31:42 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_7B19D033-DB54-4F27-AB76-A9A8E9F8998A" MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Date: Mon, 04 Nov 2019 12:31:40 -0800 In-reply-to: Cc: Zaheduzzaman Sarker , taps WG To: Kyle Rose , Aaron Falk References: <5C95DA93-91D3-44C1-BDF2-09667092FC12@gmail.com> X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-04_11:, , signatures=0 Archived-At: Subject: Re: [Taps] call for TAPS agenda topics 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, 04 Nov 2019 20:31:49 -0000 --Apple-Mail=_7B19D033-DB54-4F27-AB76-A9A8E9F8998A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Right, I'd ask that we spend a good chunk of time discussing the = security document. Since we have 90 minutes, perhaps allocate 20-30 = minutes for that? I've just posted the -05 versions of the three main documents. I'd = suggest that we spend a good chunk of time going through the issues = list, and figuring out what we expect to do when: = (https://github.com/ietf-tapswg/api-drafts/issues?page=3D1&q=3Dis%3Aissue+= is%3Aopen). We've made some strides in adding detail in the implementation draft, = but that's still the one that needs most attention. Thanks, Tommy > On Nov 4, 2019, at 10:18 AM, Kyle Rose wrote: >=20 > Evidently, the transport security document. >=20 > On Mon, Nov 4, 2019 at 8:33 AM Aaron Falk > wrote: > Ok, gang, what should we discuss in Singapore? >=20 > --aaron >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps = > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_7B19D033-DB54-4F27-AB76-A9A8E9F8998A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Right, I'd ask that we spend a good chunk of time discussing = the security document. Since we have 90 minutes, perhaps allocate 20-30 = minutes for that?

I've= just posted the -05 versions of the three main documents. I'd suggest = that we spend a good chunk of time going through the issues list, and = figuring out what we expect to do when: (https://github.com/ietf-tapswg/api-drafts/issues?page=3D1&q= =3Dis%3Aissue+is%3Aopen).

We've made some strides in adding = detail in the implementation draft, but that's still the one that needs = most attention.

Thanks,
Tommy

On Nov = 4, 2019, at 10:18 AM, Kyle Rose <krose@krose.org> wrote:

Evidently, the transport security document.

On Mon, Nov 4, 2019 at 8:33 AM Aaron = Falk <aaron.falk@gmail.com> wrote:

Ok, = gang, what should we discuss in Singapore?

--aaron

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

= --Apple-Mail=_7B19D033-DB54-4F27-AB76-A9A8E9F8998A-- From nobody Mon Nov 4 12:36:28 2019 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 255D1120041 for ; Mon, 4 Nov 2019 12:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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 0SiNteBJVZuF for ; Mon, 4 Nov 2019 12:36:23 -0800 (PST) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 34D45120052 for ; Mon, 4 Nov 2019 12:36:22 -0800 (PST) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id xA4KaIqg009999 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 4 Nov 2019 21:36:18 +0100 Received: from [193.16.224.12] (helo=[10.16.95.92]) by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1iRj2s-0000vc-QS; Mon, 04 Nov 2019 21:33:50 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: "Philipp S. Tiesel" In-Reply-To: Date: Mon, 4 Nov 2019 21:36:12 +0100 Cc: Aaron Falk , Zaheduzzaman Sarker , taps WG Content-Transfer-Encoding: quoted-printable Message-Id: <5BEA272C-BF1C-4CEA-823D-0297282543E5@in-panik.de> References: <5C95DA93-91D3-44C1-BDF2-09667092FC12@gmail.com> To: Kyle Rose X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [Taps] call for TAPS agenda topics 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, 04 Nov 2019 20:36:27 -0000 AVE! Philipp S. Tiesel -- =20 Philipp S. Tiesel https://philipp.tiesel.net/ > On 4. Nov 2019, at 19:18, Kyle Rose wrote: >=20 > Evidently, the transport security document. Yes, we need to discuss next steps there. I still hope there will be = some discussion on the list this and next week so we do not need to spend too much = precious face time with this issue. I also see the state of the three other documents as agenda Items: - Architecture=20 - Should be nearly finished, but for those you have not read one of = the last two versions,=20 please do so and give feedback! - Interface - Framers - Errors - Multicast - Implementation - Are we satisfied with the structure - Proxies/Tor/etc=E2=80=A6 - Multicast >=20 > On Mon, Nov 4, 2019 at 8:33 AM Aaron Falk = wrote: > Ok, gang, what should we discuss in Singapore? >=20 > --aaron >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Mon Nov 4 13:27:08 2019 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 7E42A120A2E for ; Mon, 4 Nov 2019 13:27:02 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 0vnwCJXe-UGs for ; Mon, 4 Nov 2019 13:26:58 -0800 (PST) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 05236120913 for ; Mon, 4 Nov 2019 13:26:57 -0800 (PST) Received: from smtp8.infomaniak.ch (smtp8.infomaniak.ch [83.166.132.38]) by smtp-sh2.infomaniak.ch (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id xA4LQr9l123979 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 4 Nov 2019 22:26:54 +0100 Received: from [10.11.33.88] (dynamic-145-014-214-039.glattnet.ch [145.14.214.39]) (authenticated bits=0) by smtp8.infomaniak.ch (8.14.5/8.14.5) with ESMTP id xA4LQqtY101793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 4 Nov 2019 22:26:53 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Brian Trammell (IETF)" In-Reply-To: <5BEA272C-BF1C-4CEA-823D-0297282543E5@in-panik.de> Date: Mon, 4 Nov 2019 22:26:52 +0100 Cc: Kyle Rose , Aaron Falk , Zaheduzzaman Sarker , taps WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <5C95DA93-91D3-44C1-BDF2-09667092FC12@gmail.com> <5BEA272C-BF1C-4CEA-823D-0297282543E5@in-panik.de> To: "Philipp S. Tiesel" X-Mailer: Apple Mail (2.3445.104.11) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Taps] call for TAPS agenda topics 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, 04 Nov 2019 21:27:06 -0000 hi Philipp, all, parachuting-into-the-thread comments inline below. > On 4 Nov 2019, at 21:36, Philipp S. Tiesel wrote: >=20 >=20 >=20 > AVE! > Philipp S. Tiesel >=20 > -- =20 > Philipp S. Tiesel > https://philipp.tiesel.net/ >=20 >> On 4. Nov 2019, at 19:18, Kyle Rose wrote: >>=20 >> Evidently, the transport security document. >=20 > Yes, we need to discuss next steps there. I still hope there will be = some discussion > on the list this and next week so we do not need to spend too much = precious face time > with this issue. >=20 > I also see the state of the three other documents as agenda Items: > - Architecture=20 > - Should be nearly finished, but for those you have not read one of = the last two versions,=20 > please do so and give feedback! IIRC we'd said we wanted to hold this until at least interface was done. = But yes, please read this :) (I should re-read, actually). > - Interface I think you've identified the three pending discussions correctly on = this doc... > - Framers I need to dig into this a bit (and hope to before Singapore, but I also = hoped to have cycles before the interim that didn't happen so MMMV) but = I'm a lot happier with the general arrangement in -05 with the bulk of = the framer detail in -impl. > - Errors I continue to think that something along the lines of the present = underspecification is not wrong here. But we should probably have more = text about the shape of that underspecification. > - Multicast ...continues to be the swamp into which all transport efforts wade and = subsequently get eaten by rodents of unusual size. :) Practically speaking, this boils down to two issues AFAICT: - We have https://github.com/ietf-tapswg/api-drafts/issues/303 on = multicast transport properties. This is marked Ready For Text and = assigned to tfpauly, so I'm inclined to let Tommy write some text here = (or assign someone else if they'd like to take a crack at it). - We have https://github.com/ietf-tapswg/api-drafts/issues/150 which has = a long and varied history which you should go read if you're not = familiar with it (or if, like me, you'd forgotten it): - dup'd to https://github.com/ietf-tapswg/api-drafts/issues/170, which = was closed by PR on 6 Jun 2018 - reopened to explictly address multicast interaction, languished = without discussion for six months - tagged ready for text in January with an assigned volunteer (Jake) = but no discussion or guidance otherwise I propose we come to a decision on this in Singapore: commit to text = soon (end 2019) or ship without. Cheers, Brian > - Implementation > - Are we satisfied with the structure > - Proxies/Tor/etc=E2=80=A6 > - Multicast >=20 >>=20 >> On Mon, Nov 4, 2019 at 8:33 AM Aaron Falk = wrote: >> Ok, gang, what should we discuss in Singapore? >>=20 >> --aaron >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Mon Nov 4 15:09:25 2019 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 C9E0B1209AA for ; Mon, 4 Nov 2019 15:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 bBvaW1BkrFf9 for ; Mon, 4 Nov 2019 15:09:17 -0800 (PST) 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 4F783120A23 for ; Mon, 4 Nov 2019 15:09:17 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id g50so26603787qtb.4 for ; Mon, 04 Nov 2019 15:09:17 -0800 (PST) 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=PDAlBnj+rmWiTQEaQXxEeLvHX+ueHGsMKMJeXUVrHcs=; b=EgPS+3Ig3FYh+wZ3hcc9nAPRbP7eg/dFsl1FKwfF2lb/H3hbBqUQlPpxwHC+InrmVw 6Xp0K0Euha7wVyzDFR69OmvcR7Zf/aJYuJzmht/Wg0mkHI1POKiz4RKpneTPkPLFVCHT 4G6RQi2Lpy74Q60RWnT/stfA+WNoQBz/o3JJLUFshcxUu0v2ryTHe2Z2wefZ2iDnYqll 6fMG0pIlTfYGGrxd56ZRDyJpvl78gQkMN+IKpbl3to3dpxOIxt0UCDRMorhCKPGudBB4 sFMvcKrHEcSiub/cRzBmsMYH9SKAFOXhtVflStveb21EYro3YcStZf42pDlBABTHgfmN Yfqg== 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=PDAlBnj+rmWiTQEaQXxEeLvHX+ueHGsMKMJeXUVrHcs=; b=fhwbBxELP7xhOMc1a1z49D8Ytmt6pn/Z+crO7SruDhx6vMCgKNCqRlhOdp/BfnIdNC DKS56Xy80cQfEyD717DEUsOP3Nt4iT55R7dssQtHkLiuKITdAKadfMmnP8Y/PEJUQWeW jbmJBn7qAxSB4hoJaQsjK0F7r8TXGwjWuKY0d/YDoBje2rQ2iHXcBUPZ8EMtLh32frKI vH0ILq1EFrKHHrMtFZtJStZdqqk/QkJQ7nmz5mB/cWRoJ1hJAdqcEZbUI9T+avHyMisx FHOWQlNtWIsD+/qhC6Q7LyGPNpRdUJ7dD273InyXQmbypCaJFYF5+uVCaWnXnr30mZdU 3Bkw== X-Gm-Message-State: APjAAAXEauD+IU4TszYfkOYifn0CD9aOjGCI6k85GXFuyDxkp/7ZUtTL M69rRXKhvnsO97SDrMxpDCLWaVrB X-Google-Smtp-Source: APXvYqwBPs4NtvI9h5GD5nqVIh3VZ4o52gM9k89X9y6SNPCW4YiexmDKCQKNYCFOEqqze/WQHQwXZA== X-Received: by 2002:ac8:6ce:: with SMTP id j14mr14543230qth.121.1572908955797; Mon, 04 Nov 2019 15:09:15 -0800 (PST) Received: from [172.19.32.96] ([2001:4878:a048:3000:c031:a808:8df1:c243]) by smtp.gmail.com with ESMTPSA id o5sm7436639qtq.10.2019.11.04.15.09.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Nov 2019 15:09:14 -0800 (PST) From: "Aaron Falk" To: "taps WG" Cc: "Philipp S. Tiesel" , "Brian Trammell" , "Kyle Rose" , "Zaheduzzaman Sarker" Date: Mon, 04 Nov 2019 18:09:11 -0500 X-Mailer: MailMate (1.13r5655) Message-ID: <27D8D383-E3AB-47C1-B1AF-488C703A44BC@gmail.com> In-Reply-To: References: <5C95DA93-91D3-44C1-BDF2-09667092FC12@gmail.com> <5BEA272C-BF1C-4CEA-823D-0297282543E5@in-panik.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_25DA0839-7912-4A39-816C-8BFCDC059E6D_=" Archived-At: Subject: Re: [Taps] call for TAPS agenda topics 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, 04 Nov 2019 23:09:24 -0000 --=_MailMate_25DA0839-7912-4A39-816C-8BFCDC059E6D_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Draft agenda based on what I=E2=80=99ve heard. Putting the security draft= last = as I=E2=80=99m uncertain at this point whether the discussion will conver= ge. = Also, rather than Philipp=E2=80=99s list of topics, I suggest someone sho= uld = scrub the open issues. Who should drive the discussion? Other comments? 0. Administrivia (10m) - Chairs 1. Issue review for (50m) * = [draft-ietf-taps-architecture-05](https://datatracker.ietf.org/doc/html/d= raft-ietf-taps-arch-05) * = [draft-ietf-taps-interface-05](https://datatracker.ietf.org/doc/html/draf= t-ietf-taps-interface-05) * = [draft-ietf-taps-implementation-05](https://datatracker.ietf.org/doc/html= /draft-ietf-taps-impl-05) 2. IETF last call comments on = [draft-ietf-taps-security-09](https://tools.ietf.org/html/draft-ietf-taps= -transport-security-09) = (30m) * Ref [[from = Ekr](https://mailarchive.ietf.org/arch/msg/taps/R4zjHu8FN7A_3Lvs4TOyuF7kv= L8)] = [[from = Christian](https://mailarchive.ietf.org/arch/msg/saag/43g1LfmbbL1F5BoUHTw= yOleHJU0#)] * What are our next steps? --aaron On 4 Nov 2019, at 16:26, Brian Trammell (IETF) wrote: > hi Philipp, all, > > parachuting-into-the-thread comments inline below. > >> On 4 Nov 2019, at 21:36, Philipp S. Tiesel wrote: >> >> >> >> AVE! >> Philipp S. Tiesel >> >> -- >> Philipp S. Tiesel >> https://philipp.tiesel.net/ >> >>> On 4. Nov 2019, at 19:18, Kyle Rose wrote: >>> >>> Evidently, the transport security document. >> >> Yes, we need to discuss next steps there. I still hope there will be = >> some discussion >> on the list this and next week so we do not need to spend too much = >> precious face time >> with this issue. >> >> I also see the state of the three other documents as agenda Items: >> - Architecture >> - Should be nearly finished, but for those you have not read one of = >> the last two versions, >> please do so and give feedback! > > IIRC we'd said we wanted to hold this until at least interface was = > done. But yes, please read this :) (I should re-read, actually). > >> - Interface > > I think you've identified the three pending discussions correctly on = > this doc... > >> - Framers > > I need to dig into this a bit (and hope to before Singapore, but I = > also hoped to have cycles before the interim that didn't happen so = > MMMV) but I'm a lot happier with the general arrangement in -05 with = > the bulk of the framer detail in -impl. > >> - Errors > > I continue to think that something along the lines of the present = > underspecification is not wrong here. But we should probably have more = > text about the shape of that underspecification. > >> - Multicast > > ...continues to be the swamp into which all transport efforts wade and = > subsequently get eaten by rodents of unusual size. :) > > Practically speaking, this boils down to two issues AFAICT: > > - We have https://github.com/ietf-tapswg/api-drafts/issues/303 on = > multicast transport properties. This is marked Ready For Text and = > assigned to tfpauly, so I'm inclined to let Tommy write some text here = > (or assign someone else if they'd like to take a crack at it). > > - We have https://github.com/ietf-tapswg/api-drafts/issues/150 which = > has a long and varied history which you should go read if you're not = > familiar with it (or if, like me, you'd forgotten it): > > - dup'd to https://github.com/ietf-tapswg/api-drafts/issues/170, = > which was closed by PR on 6 Jun 2018 > - reopened to explictly address multicast interaction, languished = > without discussion for six months > - tagged ready for text in January with an assigned volunteer (Jake) = > but no discussion or guidance otherwise > > I propose we come to a decision on this in Singapore: commit to text = > soon (end 2019) or ship without. > > Cheers, > > Brian > >> - Implementation >> - Are we satisfied with the structure >> - Proxies/Tor/etc=E2=80=A6 >> - Multicast >> >>> >>> On Mon, Nov 4, 2019 at 8:33 AM Aaron Falk = >>> wrote: >>> Ok, gang, what should we discuss in Singapore? >>> >>> --aaron >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps --=_MailMate_25DA0839-7912-4A39-816C-8BFCDC059E6D_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Draft agenda based on what I=E2=80=99ve heard. Putting th= e security draft last as I=E2=80=99m uncertain at this point whether the = discussion will converge. Also, rather than Philipp=E2=80=99s list of top= ics, I suggest someone should scrub the open issues. Who should drive the= discussion? Other comments?

  1. Administrivia (10m) - Chairs
  2. Issue review for (50m)
  3. IETF last call comments on d= raft-ietf-taps-security-09 (30m)

--aaron

On 4 Nov 2019, at 16:26, Brian Trammell (IETF) wrote:

=

h= i Philipp, all,

parachuting-into-the-thread comments inline below.

On 4 Nov 20= 19, at 21:36, Philipp S. Tiesel <phils@in-panik.de> wrote:



AVE!
Philipp S. Tiesel

--
Philipp S. Tiesel
https://phil= ipp.tiesel.net/

On 4. Nov 2= 019, at 19:18, Kyle Rose <krose@krose.org> wrote:

Evidently, the transport security document.

Yes, we need to discuss next steps there. I = still hope there will be some discussion
on the list this and next week so we do not need to spend too much precio= us face time
with this issue.

I also see the state of the three other documents as agenda Items:
- Architecture
- Should be nearly finished, but for those you have not read one of the= last two versions,
please do so and give feedback!

IIRC we'd said we wanted to hold this until = at least interface was done. But yes, please read this :) (I should re-re= ad, actually).

- Interface=

I think you've identified the three pending = discussions correctly on this doc...

- Framers=

I need to dig into this a bit (and hope to b= efore Singapore, but I also hoped to have cycles before the interim that = didn't happen so MMMV) but I'm a lot happier with the general arrangement= in -05 with the bulk of the framer detail in -impl.

- Errors<= /p>

I continue to think that something along the= lines of the present underspecification is not wrong here. But we should= probably have more text about the shape of that underspecification.

- Multica= st

...continues to be the swamp into which all = transport efforts wade and subsequently get eaten by rodents of unusual s= ize. :)

Practically speaking, this boils down to two issues AFAICT:

- We have https://github.com/ietf-tapswg/api-drafts/issues/3= 03 on multicast transport properties. This is marked Ready For Text a= nd assigned to tfpauly, so I'm inclined to let Tommy write some text here= (or assign someone else if they'd like to take a crack at it).

- We have https://github.com/ietf-tapswg/api-drafts/issues/1= 50 which has a long and varied history which you should go read if yo= u're not familiar with it (or if, like me, you'd forgotten it):

- dup'd to https://github.com/ietf-tapswg/api-drafts/issue= s/170, which was closed by PR on 6 Jun 2018
- reopened to explictly address multicast interaction, languished witho= ut discussion for six months
- tagged ready for text in January with an assigned volunteer (Jake) bu= t no discussion or guidance otherwise

I propose we come to a decision on this in Singapore: commit to text soon= (end 2019) or ship without.

Cheers,

Brian

- Implement= ation
- Are we satisfied with the structure
- Proxies/Tor/etc=E2=80=A6
- Multicast

On Mon, Nov= 4, 2019 at 8:33 AM Aaron Falk <aaron.falk@gmail.com> wrote:
Ok, gang, what should we discuss in Singapore?

--aaron

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

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

--=_MailMate_25DA0839-7912-4A39-816C-8BFCDC059E6D_=-- From nobody Mon Nov 4 21:58:55 2019 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 1E72612004F for ; Mon, 4 Nov 2019 21:58:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 gfUfcYgjULOE for ; Mon, 4 Nov 2019 21:58:49 -0800 (PST) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 E5CA2120020 for ; Mon, 4 Nov 2019 21:58:48 -0800 (PST) Received: from smtp8.infomaniak.ch (smtp8.infomaniak.ch [83.166.132.38]) by smtp-sh2.infomaniak.ch (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id xA55wjoZ200168 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 5 Nov 2019 06:58:46 +0100 Received: from [10.11.33.78] (dynamic-145-014-214-039.glattnet.ch [145.14.214.39]) (authenticated bits=0) by smtp8.infomaniak.ch (8.14.5/8.14.5) with ESMTP id xA55wiEM022804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 5 Nov 2019 06:58:45 +0100 Content-Type: multipart/alternative; boundary=Apple-Mail-0ED80B9F-9C6C-4AC8-95A0-75DDFE85F825 Mime-Version: 1.0 (1.0) From: "Brian Trammell (IETF)" X-Mailer: iPhone Mail (16G102) In-Reply-To: <27D8D383-E3AB-47C1-B1AF-488C703A44BC@gmail.com> Date: Tue, 5 Nov 2019 06:58:44 +0100 Cc: taps WG , "Philipp S. Tiesel" , Kyle Rose , Zaheduzzaman Sarker Content-Transfer-Encoding: 7bit Message-Id: References: <5C95DA93-91D3-44C1-BDF2-09667092FC12@gmail.com> <5BEA272C-BF1C-4CEA-823D-0297282543E5@in-panik.de> <27D8D383-E3AB-47C1-B1AF-488C703A44BC@gmail.com> To: Aaron Falk X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Taps] call for TAPS agenda topics 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, 05 Nov 2019 05:58:53 -0000 --Apple-Mail-0ED80B9F-9C6C-4AC8-95A0-75DDFE85F825 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I can do the issue scrub for -interface. Sent from my iPhone > On 5 Nov 2019, at 00:09, Aaron Falk wrote: >=20 > Draft agenda based on what I=E2=80=99ve heard. Putting the security draft l= ast as I=E2=80=99m uncertain at this point whether the discussion will conve= rge. Also, rather than Philipp=E2=80=99s list of topics, I suggest someone s= hould scrub the open issues. Who should drive the discussion? Other comments= ? >=20 > Administrivia (10m) - Chairs > Issue review for (50m) > draft-ietf-taps-architecture-05 > draft-ietf-taps-interface-05 > draft-ietf-taps-implementation-05 > IETF last call comments on draft-ietf-taps-security-09 (30m) > Ref [from Ekr] [from Christian] > What are our next steps? > --aaron >=20 > On 4 Nov 2019, at 16:26, Brian Trammell (IETF) wrote: >=20 > hi Philipp, all, >=20 > parachuting-into-the-thread comments inline below. >=20 > On 4 Nov 2019, at 21:36, Philipp S. Tiesel wrote: >=20 >=20 >=20 > AVE! > Philipp S. Tiesel >=20 > -- > Philipp S. Tiesel > https://philipp.tiesel.net/ >=20 > On 4. Nov 2019, at 19:18, Kyle Rose wrote: >=20 > Evidently, the transport security document. >=20 > Yes, we need to discuss next steps there. I still hope there will be some d= iscussion > on the list this and next week so we do not need to spend too much preciou= s face time > with this issue. >=20 > I also see the state of the three other documents as agenda Items: > - Architecture > - Should be nearly finished, but for those you have not read one of the la= st two versions, > please do so and give feedback! >=20 > IIRC we'd said we wanted to hold this until at least interface was done. B= ut yes, please read this :) (I should re-read, actually). >=20 > - Interface >=20 > I think you've identified the three pending discussions correctly on this d= oc... >=20 > - Framers >=20 > I need to dig into this a bit (and hope to before Singapore, but I also ho= ped to have cycles before the interim that didn't happen so MMMV) but I'm a l= ot happier with the general arrangement in -05 with the bulk of the framer d= etail in -impl. >=20 > - Errors >=20 > I continue to think that something along the lines of the present underspe= cification is not wrong here. But we should probably have more text about th= e shape of that underspecification. >=20 > - Multicast >=20 > ...continues to be the swamp into which all transport efforts wade and sub= sequently get eaten by rodents of unusual size. :) >=20 > Practically speaking, this boils down to two issues AFAICT: >=20 > - We have https://github.com/ietf-tapswg/api-drafts/issues/303 on multicas= t transport properties. This is marked Ready For Text and assigned to tfpaul= y, so I'm inclined to let Tommy write some text here (or assign someone else= if they'd like to take a crack at it). >=20 > - We have https://github.com/ietf-tapswg/api-drafts/issues/150 which has a= long and varied history which you should go read if you're not familiar wit= h it (or if, like me, you'd forgotten it): >=20 > - dup'd to https://github.com/ietf-tapswg/api-drafts/issues/170, which was= closed by PR on 6 Jun 2018 > - reopened to explictly address multicast interaction, languished without d= iscussion for six months > - tagged ready for text in January with an assigned volunteer (Jake) but n= o discussion or guidance otherwise >=20 > I propose we come to a decision on this in Singapore: commit to text soon (= end 2019) or ship without. >=20 > Cheers, >=20 > Brian >=20 > - Implementation > - Are we satisfied with the structure > - Proxies/Tor/etc=E2=80=A6 > - Multicast >=20 > On Mon, Nov 4, 2019 at 8:33 AM Aaron Falk wrote: > Ok, gang, what should we discuss in Singapore? >=20 > --aaron >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps >=20 --Apple-Mail-0ED80B9F-9C6C-4AC8-95A0-75DDFE85F825 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I can do the issue scrub for -interface.
Sent from my iPhone

On 5 Nov 2019, at 00:09, Aaron Falk <aaron.falk@gmail.com> wrote:

Draft agenda based on what I=E2=80=99ve heard. Putting the s= ecurity draft last as I=E2=80=99m uncertain at this point whether the discus= sion will converge. Also, rather than Philipp=E2=80=99s list of topics, I su= ggest someone should scrub the open issues. Who should drive the discussion?= Other comments?

  1. Administrivia (10m) - Chairs
  2. Issue review for (50m)
  3. IETF last call comments on draft-i= etf-taps-security-09 (30m)

--aaron

On 4 Nov 2019, at 16:26, Brian Trammell (IETF) wrote:

hi Phil= ipp, all,

parachuting-into-the-thread comments inline below.

On 4 Nov 2019, at= 21:36, Philipp S. Tiesel <phils@in-= panik.de> wrote:



AVE!
Philipp S. Tiesel

--
Philipp S. Tiesel
https://philipp= .tiesel.net/

On 4. Nov 2019, a= t 19:18, Kyle Rose <krose@krose.org> wrote:

Evidently, the transport security document.

Yes, we need to discuss next steps there. I sti= ll hope there will be some discussion
on the list this and next week so we do not need to spend too much precious f= ace time
with this issue.

I also see the state of the three other documents as agenda Items:
- Architecture
- Should be nearly finished, but for those you have not read one of the la= st two versions,
please do so and give feedback!

IIRC we'd said we wanted to hold this until at l= east interface was done. But yes, please read this :) (I should re-read, act= ually).

- Interface

I think you've identified the three pending dis= cussions correctly on this doc...

- Framers

I need to dig into this a bit (and hope to befo= re Singapore, but I also hoped to have cycles before the interim that didn't= happen so MMMV) but I'm a lot happier with the general arrangement in -05 w= ith the bulk of the framer detail in -impl.

- Errors

I continue to think that something along the li= nes of the present underspecification is not wrong here. But we should proba= bly have more text about the shape of that underspecification.

- Multicast

=

...continues to be the swamp into which all tra= nsport efforts wade and subsequently get eaten by rodents of unusual size. := )

Practically speaking, this boils down to two issues AFAICT:

- We have https://github.com/ietf-tapswg/api-drafts/issues/303= on multicast transport properties. This is marked Ready For Text and assign= ed to tfpauly, so I'm inclined to let Tommy write some text here (or assign s= omeone else if they'd like to take a crack at it).

- We have https://github.com/ietf-tapswg/api-drafts/issues/150= which has a long and varied history which you should go read if you're not f= amiliar with it (or if, like me, you'd forgotten it):

- dup'd to https://github.com/ietf-tapswg/api-drafts/issues/170<= /a>, which was closed by PR on 6 Jun 2018
- reopened to explictly address multicast interaction, languished without d= iscussion for six months
- tagged ready for text in January with an assigned volunteer (Jake) but n= o discussion or guidance otherwise

I propose we come to a decision on this in Singapore: commit to text soon (e= nd 2019) or ship without.

Cheers,

Brian

- Implementation<= br> - Are we satisfied with the structure
- Proxies/Tor/etc=E2=80=A6
- Multicast

On Mon, Nov 4, 20= 19 at 8:33 AM Aaron Falk <aaron.f= alk@gmail.com> wrote:
Ok, gang, what should we discuss in Singapore?

--aaron

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

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

= --Apple-Mail-0ED80B9F-9C6C-4AC8-95A0-75DDFE85F825-- From nobody Wed Nov 6 14:54:20 2019 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 6761812011F for ; Wed, 6 Nov 2019 14:54:18 -0800 (PST) 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_HELO_NONE=0.001, 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 EqaYv7YtW_uK for ; Wed, 6 Nov 2019 14:54:15 -0800 (PST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 6B3111200B1 for ; Wed, 6 Nov 2019 14:54:15 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id i19so307303qki.2 for ; Wed, 06 Nov 2019 14:54:15 -0800 (PST) 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=nApEsbmSaiZJY8egitN9BbVFvqJPiPDOseVEDYUMass=; b=uBOQ+ZsdFUI/vLKyMiIES3ppLhl1X66CEWeaSmPj/Y64wD3XqIZQc1G1NcrvPihQx3 rl1yDRvmIu+VLoegS7qE+/JGqTgW2VJQrdiYSa2dg0VVLxEFxgxCAySIemO4LijHXAb+ R/a4+Rh256CNwc8q8jDigi12Ek4JKQ/evTT8cnR85VG3v//ePe5uugxCkvJ+WhD7Mahl SmZycBxzbr7dze/Rzpg26W93vIQ7zfCfaUBHwoXvDOCta3+4quEySkufZqkZjVYv6MkO 6HKs16xHy1AOQkjfjVVJUUfVegC6a/oee72T2PmtgGQvvYXkSTXSW0IgQFE/6egJ/dm2 M2gw== 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=nApEsbmSaiZJY8egitN9BbVFvqJPiPDOseVEDYUMass=; b=TQmqYpLm4eiQA4lOGxsstIc8/6ecKV7Who2hA43eI4LbvK6+3Q08sokC69TezQ/qMU rABXys3XkxbFTDlOUMNy91E/7lcSANfbc3qwAetyMg2bPcMwabZt4wv90JhMmlOkyBcl MrTLysDYY5ErT39BG2Kw4+sT6d6EZgzsonRWOTo50Jw2NYakswc13MKF9U3hQD12JJgO 29asxoQk2xluvjbA+Up7cUsC2aD14LQ2cHYSwb9fE0LpVmfEaaLcQ/xCCOLtFNAK9zgY CTG5U3MvW7pB40Ol1koLlRyVQkfxh31G+0kB3gc7cCCzSJFu575MT2t7zvvGgbcCwpcY fU7Q== X-Gm-Message-State: APjAAAUmKs7xr0eAARWXsPeSPGOt/nBl9jbWaaZMYxiJBQd8fVgb6A6U mRoji1oaQnLO+lhJi+5SOps= X-Google-Smtp-Source: APXvYqy7QzGwW60mJdBsuTtlZe5FMZVt5hjXE12dpCecWsxlPFYcsFM7hOXLhdcDu8OWO94bnd8AVA== X-Received: by 2002:a37:8245:: with SMTP id e66mr4684800qkd.355.1573080854267; Wed, 06 Nov 2019 14:54:14 -0800 (PST) Received: from [172.19.33.55] ([2001:4878:a048:3000:a16f:d9a6:5c0c:1a38]) by smtp.gmail.com with ESMTPSA id g25sm169077qtc.90.2019.11.06.14.54.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Nov 2019 14:54:13 -0800 (PST) From: "Aaron Falk" To: "Brian Trammell" , "taps WG" Cc: "Philipp S. Tiesel" , "Kyle Rose" , "Zaheduzzaman Sarker" Date: Wed, 06 Nov 2019 17:54:11 -0500 X-Mailer: MailMate (1.13r5655) Message-ID: <39D5EDBC-97BD-4980-878F-442A144313A5@gmail.com> In-Reply-To: References: <5C95DA93-91D3-44C1-BDF2-09667092FC12@gmail.com> <5BEA272C-BF1C-4CEA-823D-0297282543E5@in-panik.de> <27D8D383-E3AB-47C1-B1AF-488C703A44BC@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_05C65C9D-25F8-4F23-989C-9EEF7196C63F_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[508, 7625], "plain":[160, 4101], "uuid":"17E54141-8157-470A-80CF-8DB5257FEA6F"}] Archived-At: Subject: Re: [Taps] call for TAPS agenda topics 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, 06 Nov 2019 22:54:19 -0000 --=_MailMate_05C65C9D-25F8-4F23-989C-9EEF7196C63F_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Thanks, Brian. We need discussion leads for -architecture, -implementation, and -security. --aaron On 5 Nov 2019, at 0:58, Brian Trammell (IETF) wrote: > I can do the issue scrub for -interface. > > Sent from my iPhone > >> On 5 Nov 2019, at 00:09, Aaron Falk wrote: >> >> Draft agenda based on what I’ve heard. Putting the security draft >> last as I’m uncertain at this point whether the discussion will >> converge. Also, rather than Philipp’s list of topics, I suggest >> someone should scrub the open issues. Who should drive the >> discussion? Other comments? >> >> Administrivia (10m) - Chairs >> Issue review for (50m) >> draft-ietf-taps-architecture-05 >> draft-ietf-taps-interface-05 >> draft-ietf-taps-implementation-05 >> IETF last call comments on draft-ietf-taps-security-09 (30m) >> Ref [from Ekr] [from Christian] >> What are our next steps? >> --aaron >> >> On 4 Nov 2019, at 16:26, Brian Trammell (IETF) wrote: >> >> hi Philipp, all, >> >> parachuting-into-the-thread comments inline below. >> >> On 4 Nov 2019, at 21:36, Philipp S. Tiesel wrote: >> >> >> >> AVE! >> Philipp S. Tiesel >> >> -- >> Philipp S. Tiesel >> https://philipp.tiesel.net/ >> >> On 4. Nov 2019, at 19:18, Kyle Rose wrote: >> >> Evidently, the transport security document. >> >> Yes, we need to discuss next steps there. I still hope there will be >> some discussion >> on the list this and next week so we do not need to spend too much >> precious face time >> with this issue. >> >> I also see the state of the three other documents as agenda Items: >> - Architecture >> - Should be nearly finished, but for those you have not read one of >> the last two versions, >> please do so and give feedback! >> >> IIRC we'd said we wanted to hold this until at least interface was >> done. But yes, please read this :) (I should re-read, actually). >> >> - Interface >> >> I think you've identified the three pending discussions correctly on >> this doc... >> >> - Framers >> >> I need to dig into this a bit (and hope to before Singapore, but I >> also hoped to have cycles before the interim that didn't happen so >> MMMV) but I'm a lot happier with the general arrangement in -05 with >> the bulk of the framer detail in -impl. >> >> - Errors >> >> I continue to think that something along the lines of the present >> underspecification is not wrong here. But we should probably have >> more text about the shape of that underspecification. >> >> - Multicast >> >> ...continues to be the swamp into which all transport efforts wade >> and subsequently get eaten by rodents of unusual size. :) >> >> Practically speaking, this boils down to two issues AFAICT: >> >> - We have https://github.com/ietf-tapswg/api-drafts/issues/303 on >> multicast transport properties. This is marked Ready For Text and >> assigned to tfpauly, so I'm inclined to let Tommy write some text >> here (or assign someone else if they'd like to take a crack at it). >> >> - We have https://github.com/ietf-tapswg/api-drafts/issues/150 which >> has a long and varied history which you should go read if you're not >> familiar with it (or if, like me, you'd forgotten it): >> >> - dup'd to https://github.com/ietf-tapswg/api-drafts/issues/170, >> which was closed by PR on 6 Jun 2018 >> - reopened to explictly address multicast interaction, languished >> without discussion for six months >> - tagged ready for text in January with an assigned volunteer (Jake) >> but no discussion or guidance otherwise >> >> I propose we come to a decision on this in Singapore: commit to text >> soon (end 2019) or ship without. >> >> Cheers, >> >> Brian >> >> - Implementation >> - Are we satisfied with the structure >> - Proxies/Tor/etc… >> - Multicast >> >> On Mon, Nov 4, 2019 at 8:33 AM Aaron Falk >> wrote: >> Ok, gang, what should we discuss in Singapore? >> >> --aaron >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >> --=_MailMate_05C65C9D-25F8-4F23-989C-9EEF7196C63F_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Thanks, Brian.

We need discussion leads for -architecture, -implementati= on, and -security.

--aaron

On 5 Nov 2019, at 0:58, Brian Trammell (IETF) wrote:

I can do the issue scrub for -interface.

Sent from my iPhone

On 5 Nov 2019, at 00:09, Aaron Falk <aaron.falk@gmail.com> wrote:

Draft agenda based on what I=E2=80=99ve heard. Putting th= e security draft last as I=E2=80=99m uncertain at this point whether the = discussion will converge. Also, rather than Philipp=E2=80=99s list of top= ics, I suggest someone should scrub the open issues. Who should drive the= discussion? Other comments?

  1. Administrivia (10m) - Chairs
  2. Issue review for (50m)
  3. IETF last call comments on d= raft-ietf-taps-security-09 (30m)

--aaron

On 4 Nov 2019, at 16:26, Brian Trammell (IETF) wrote:

=

h= i Philipp, all,

parachuting-into-the-thread comments inline below.

On 4 Nov 20= 19, at 21:36, Philipp S. Tiesel <= phils@in-panik.de> wrote:



AVE!
Philipp S. Tiesel

--
Philipp S. Tiesel
https://phil= ipp.tiesel.net/

On 4. Nov 2= 019, at 19:18, Kyle Rose <krose@kro= se.org> wrote:

Evidently, the transport security document.

Yes, we need to discuss next steps there. I = still hope there will be some discussion
on the list this and next week so we do not need to spend too much precio= us face time
with this issue.

I also see the state of the three other documents as agenda Items:
- Architecture
- Should be nearly finished, but for those you have not read one of the= last two versions,
please do so and give feedback!

IIRC we'd said we wanted to hold this until = at least interface was done. But yes, please read this :) (I should re-re= ad, actually).

- Interface=

I think you've identified the three pending = discussions correctly on this doc...

- Framers=

I need to dig into this a bit (and hope to b= efore Singapore, but I also hoped to have cycles before the interim that = didn't happen so MMMV) but I'm a lot happier with the general arrangement= in -05 with the bulk of the framer detail in -impl.

- Errors<= /p>

I continue to think that something along the= lines of the present underspecification is not wrong here. But we should= probably have more text about the shape of that underspecification.

- Multica= st

...continues to be the swamp into which all = transport efforts wade and subsequently get eaten by rodents of unusual s= ize. :)

Practically speaking, this boils down to two issues AFAICT:

- We have https://github.com/ietf-tapswg/api-drafts/issues/3= 03 on multicast transport properties. This is marked Ready For Text a= nd assigned to tfpauly, so I'm inclined to let Tommy write some text here= (or assign someone else if they'd like to take a crack at it).

- We have https://github.com/ietf-tapswg/api-drafts/issues/1= 50 which has a long and varied history which you should go read if yo= u're not familiar with it (or if, like me, you'd forgotten it):

- dup'd to https://github.com/ietf-tapswg/api-drafts/issue= s/170, which was closed by PR on 6 Jun 2018
- reopened to explictly address multicast interaction, languished witho= ut discussion for six months
- tagged ready for text in January with an assigned volunteer (Jake) bu= t no discussion or guidance otherwise

I propose we come to a decision on this in Singapore: commit to text soon= (end 2019) or ship without.

Cheers,

Brian

- Implement= ation
- Are we satisfied with the structure
- Proxies/Tor/etc=E2=80=A6
- Multicast

On Mon, Nov= 4, 2019 at 8:33 AM Aaron Falk <aaron.falk@gmail.com> wrote:
Ok, gang, what should we discuss in Singapore?

--aaron

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

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

--=_MailMate_05C65C9D-25F8-4F23-989C-9EEF7196C63F_=-- From nobody Wed Nov 6 16:53:34 2019 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 43F6A120045 for ; Wed, 6 Nov 2019 16:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 Nbli_wiSAUWp for ; Wed, 6 Nov 2019 16:53:30 -0800 (PST) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.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 4426412026E for ; Wed, 6 Nov 2019 16:53:30 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id xA70qWfw034591; Wed, 6 Nov 2019 16:53:25 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=HjTd2KM+jwFnvhuW+B5AVdNXKrIBJqqz+xz8aiNIwJ8=; b=f3N39AAQ8OxGXZw0HovCsR8iN5aXMxgrME2f0KnU2Uj0dCRSYgtZ94HmWP7M8W9w13Hw p8g25Pc304GHh0BDxNv68C03dOrO8iI4a5AVssyJtwLLHyitB37R5fNrV6U/wxAE4iNT vGILCI+4O6y7jOl1ttjmYiwlSsVMlMf++nUkQOBc59cxZ4NyK5/aj7qHz8SGDX4NqFu+ hie60yWUVaS0W0rCQfjwSpOoUQddjemiUybLCIbQf39IozdG0qd3beuWSYYzVwQmBFgb uH5FmpAuZBsCHpX7sd0UiiUYvJR6YDjcO8JzQAB6t1AJE4AnPtqFBFQFQpRAtao0QNDK fA== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2w41v4tne8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 06 Nov 2019 16:53:25 -0800 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q0K00C1VQGW6370@ma1-mtap-s03.corp.apple.com>; Wed, 06 Nov 2019 16:53:25 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q0K00500Q328300@nwk-mmpp-sz13.apple.com>; Wed, 06 Nov 2019 16:53:25 -0800 (PST) X-Va-A: X-Va-T-CD: 0325f276f41c42fd3b0ac081f7f3f808 X-Va-E-CD: 958043bbad085a95e0b3339c77a12d53 X-Va-R-CD: 2f3cf7ed5e248def8b8f40b54f4181de X-Va-CD: 0 X-Va-ID: 1cda289f-1c5f-4bca-a4f1-bb7f1a75cff5 X-V-A: X-V-T-CD: 0325f276f41c42fd3b0ac081f7f3f808 X-V-E-CD: 958043bbad085a95e0b3339c77a12d53 X-V-R-CD: 2f3cf7ed5e248def8b8f40b54f4181de X-V-CD: 0 X-V-ID: c649257a-0b2d-4f67-8871-99cff458fc92 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-06_09:,, signatures=0 Received: from [17.230.168.251] by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q0K00LMMQG71290@nwk-mmpp-sz13.apple.com>; Wed, 06 Nov 2019 16:53:24 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <47A9A4CF-406C-4A92-AE0C-5594FB690331@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_D44DFFBA-80C0-4819-8803-CD867764038A" MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Date: Wed, 06 Nov 2019 16:53:22 -0800 In-reply-to: <39D5EDBC-97BD-4980-878F-442A144313A5@gmail.com> Cc: Brian Trammell , taps WG , "Philipp S. Tiesel" , Kyle Rose , Zaheduzzaman Sarker To: Aaron Falk References: <5C95DA93-91D3-44C1-BDF2-09667092FC12@gmail.com> <5BEA272C-BF1C-4CEA-823D-0297282543E5@in-panik.de> <27D8D383-E3AB-47C1-B1AF-488C703A44BC@gmail.com> <39D5EDBC-97BD-4980-878F-442A144313A5@gmail.com> X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-06_09:, , signatures=0 Archived-At: Subject: Re: [Taps] call for TAPS agenda topics 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, 07 Nov 2019 00:53:33 -0000 --Apple-Mail=_D44DFFBA-80C0-4819-8803-CD867764038A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I can lead the discussion around implementation issues, as Anna will be = remote. Best, Tommy > On Nov 6, 2019, at 2:54 PM, Aaron Falk wrote: >=20 > Thanks, Brian. >=20 > We need discussion leads for -architecture, -implementation, and = -security. >=20 > --aaron >=20 > On 5 Nov 2019, at 0:58, Brian Trammell (IETF) wrote: >=20 > I can do the issue scrub for -interface. >=20 > Sent from my iPhone >=20 > On 5 Nov 2019, at 00:09, Aaron Falk > wrote: >=20 >> Draft agenda based on what I=E2=80=99ve heard. Putting the security = draft last as I=E2=80=99m uncertain at this point whether the discussion = will converge. Also, rather than Philipp=E2=80=99s list of topics, I = suggest someone should scrub the open issues. Who should drive the = discussion? Other comments? >>=20 >> Administrivia (10m) - Chairs >> Issue review for (50m) >> draft-ietf-taps-architecture-05 = >> draft-ietf-taps-interface-05 = >> draft-ietf-taps-implementation-05 = >> IETF last call comments on draft-ietf-taps-security-09 = = (30m) >> Ref [from Ekr = ] = [from Christian = ]= >> What are our next steps? >> --aaron >>=20 >> On 4 Nov 2019, at 16:26, Brian Trammell (IETF) wrote: >>=20 >> hi Philipp, all, >>=20 >> parachuting-into-the-thread comments inline below. >>=20 >> On 4 Nov 2019, at 21:36, Philipp S. Tiesel > wrote: >>=20 >>=20 >>=20 >> AVE! >> Philipp S. Tiesel >>=20 >> -- >> Philipp S. Tiesel >> https://philipp.tiesel.net/ >> On 4. Nov 2019, at 19:18, Kyle Rose > wrote: >>=20 >> Evidently, the transport security document. >>=20 >> Yes, we need to discuss next steps there. I still hope there will be = some discussion >> on the list this and next week so we do not need to spend too much = precious face time >> with this issue. >>=20 >> I also see the state of the three other documents as agenda Items: >> - Architecture >> - Should be nearly finished, but for those you have not read one of = the last two versions, >> please do so and give feedback! >>=20 >> IIRC we'd said we wanted to hold this until at least interface was = done. But yes, please read this :) (I should re-read, actually). >>=20 >> - Interface >>=20 >> I think you've identified the three pending discussions correctly on = this doc... >>=20 >> - Framers >>=20 >> I need to dig into this a bit (and hope to before Singapore, but I = also hoped to have cycles before the interim that didn't happen so MMMV) = but I'm a lot happier with the general arrangement in -05 with the bulk = of the framer detail in -impl. >>=20 >> - Errors >>=20 >> I continue to think that something along the lines of the present = underspecification is not wrong here. But we should probably have more = text about the shape of that underspecification. >>=20 >> - Multicast >>=20 >> ...continues to be the swamp into which all transport efforts wade = and subsequently get eaten by rodents of unusual size. :) >>=20 >> Practically speaking, this boils down to two issues AFAICT: >>=20 >> - We have https://github.com/ietf-tapswg/api-drafts/issues/303 = on multicast = transport properties. This is marked Ready For Text and assigned to = tfpauly, so I'm inclined to let Tommy write some text here (or assign = someone else if they'd like to take a crack at it). >>=20 >> - We have https://github.com/ietf-tapswg/api-drafts/issues/150 = which has a long = and varied history which you should go read if you're not familiar with = it (or if, like me, you'd forgotten it): >>=20 >> - dup'd to https://github.com/ietf-tapswg/api-drafts/issues/170 = , which was closed = by PR on 6 Jun 2018 >> - reopened to explictly address multicast interaction, languished = without discussion for six months >> - tagged ready for text in January with an assigned volunteer (Jake) = but no discussion or guidance otherwise >>=20 >> I propose we come to a decision on this in Singapore: commit to text = soon (end 2019) or ship without. >>=20 >> Cheers, >>=20 >> Brian >>=20 >> - Implementation >> - Are we satisfied with the structure >> - Proxies/Tor/etc=E2=80=A6 >> - Multicast >>=20 >> On Mon, Nov 4, 2019 at 8:33 AM Aaron Falk > wrote: >> Ok, gang, what should we discuss in Singapore? >>=20 >> --aaron >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps = >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps = >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps = >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_D44DFFBA-80C0-4819-8803-CD867764038A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = can lead the discussion around implementation issues, as Anna will be = remote.

Best,
Tommy

On Nov 6, 2019, at 2:54 PM, Aaron Falk <aaron.falk@gmail.com> wrote:

Thanks,= Brian.

We need discussion leads for = -architecture, -implementation, and -security.

--aaron

On 5 Nov 2019, at 0:58, = Brian Trammell (IETF) wrote:

I can do the issue scrub for -interface.

Sent from my iPhone

On 5 Nov 2019, at 00:09, Aaron = Falk <aaron.falk@gmail.com> wrote:

Draft = agenda based on what I=E2=80=99ve heard. Putting the security draft last = as I=E2=80=99m uncertain at this point whether the discussion will = converge. Also, rather than Philipp=E2=80=99s list of topics, I suggest = someone should scrub the open issues. Who should drive the discussion? = Other comments?

  1. Administrivia (10m) - Chairs
  2. Issue review for (50m)
  3. IETF last call comments on draft-ietf-taps-security-09 = (30m)

--aaron

On = 4 Nov 2019, at 16:26, Brian Trammell (IETF) wrote:

hi Philipp, = all,

parachuting-into-the-thread comments inline below.

On 4 Nov 2019, at 21:36, Philipp S. Tiesel <phils@in-panik.de> = wrote:



AVE!
Philipp S. Tiesel

--
Philipp S. Tiesel
https://philipp.tiesel.net/

On 4. Nov 2019, at 19:18, Kyle Rose <krose@krose.org> = wrote:

Evidently, the transport security document.

Yes, we need to discuss next = steps there. I still hope there will be some discussion
on the list this and next week so we do not need to spend too much = precious face time
with this issue.

I also see the state of the three other documents as agenda Items:
- Architecture
- Should be nearly finished, but for those you have not read one of = the last two versions,
please do so and give feedback!

IIRC we'd said we wanted to hold = this until at least interface was done. But yes, please read this :) (I = should re-read, actually).

- Interface

I think you've identified the = three pending discussions correctly on this doc...

- Framers

I need to dig into this a bit = (and hope to before Singapore, but I also hoped to have cycles before = the interim that didn't happen so MMMV) but I'm a lot happier with the = general arrangement in -05 with the bulk of the framer detail in = -impl.

- Errors

I continue to think that = something along the lines of the present underspecification is not wrong = here. But we should probably have more text about the shape of that = underspecification.

- Multicast

...continues to be the swamp = into which all transport efforts wade and subsequently get eaten by = rodents of unusual size. :)

Practically speaking, this boils down to two issues AFAICT:
=
- We have https://github.com/ietf-tapswg/api-drafts/issues/303 on = multicast transport properties. This is marked Ready For Text and = assigned to tfpauly, so I'm inclined to let Tommy write some text here = (or assign someone else if they'd like to take a crack at it).

- We have https://github.com/ietf-tapswg/api-drafts/issues/150 = which has a long and varied history which you should go read if you're = not familiar with it (or if, like me, you'd forgotten it):

- dup'd to https://github.com/ietf-tapswg/api-drafts/issues/170, = which was closed by PR on 6 Jun 2018
- reopened to explictly address multicast interaction, languished = without discussion for six months
- tagged ready for text in January with an assigned volunteer (Jake) = but no discussion or guidance otherwise

I propose we come to a decision on this in Singapore: commit to text = soon (end 2019) or ship without.

Cheers,

Brian

- Implementation
- Are we satisfied with the structure
- Proxies/Tor/etc=E2=80=A6
- Multicast

On Mon, Nov 4, 2019 at 8:33 AM Aaron Falk <aaron.falk@gmail.com> wrote:
Ok, gang, what should we discuss in Singapore?

--aaron

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

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

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

= --Apple-Mail=_D44DFFBA-80C0-4819-8803-CD867764038A-- From nobody Thu Nov 7 07:48:53 2019 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 E6C4812092C for ; Thu, 7 Nov 2019 07:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 p-XQ9DJtokpl for ; Thu, 7 Nov 2019 07:48:48 -0800 (PST) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 94A03120908 for ; Thu, 7 Nov 2019 07:48:48 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id y39so2910957qty.0 for ; Thu, 07 Nov 2019 07:48:48 -0800 (PST) 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=Yf0hidWt25Knj0v1mV2JdIkW1oyr8nSlLw56hTQ29R8=; b=pAK3j80iVQK1trjiiNWaNRxAc4UIZXfsgnW+TaT01cX9H6nWYl4mnkwQnsiigu2rvH 2+xkr1Rvrv5SEvXdkcpCVYzDbnIliVt54on9AikJMu75K3wA2fOF6bmjc/v0dMtJgyt2 QkD/Gi+rHzBLILsoukbQapVidtKGqz7QzxW4iagmmxgQztiY0Cwvc3sn1FUQJPagGezG OgZkKAMMKISrqFw7bLrIlcygnTso7gXTxE/IbiS0ZU2grK0OapZNULeUd3nMftKzrx9F 78k9hPPacJbGmEdH9orQ14kfIyXYABNbPElRX6RBHjSyWAAPEyjKk+ylQZjvgql+qBat +oog== 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=Yf0hidWt25Knj0v1mV2JdIkW1oyr8nSlLw56hTQ29R8=; b=ZMhhcVM7FgTiok/zcpLclRKkOQyXcbxk4QIRuHpTdCtTlpvPvbfaPhfrXKRrOYuwa0 edfCa+SRxZz5x/qtw9iQ0HzB4kZwYsZPRYSTvnX0BDmPZokBHsfwQ+smcZigu4pVmrpc Vs7ALjaX0AV85H0Cnx16f1h2lucFt4zheZrILBtHtFL2ptUguNUKGso/gQeunFAwaYUh qBICehmRE+CIkezZ58klvjo5Zd60T5TkpAZFn3jNd/WCLJTtpWSRhUs5hc1w3QnyBOD3 /nB7V59RllA9+R2Ij9NAgybPsNXbtzqJqOrg5pxppnLoIvVAMJKKxK1ufr+SkVFYNJMR JSvw== X-Gm-Message-State: APjAAAXP+einZATXSuvhCwj29aetiGAkTTju7o5efFQBEXNMy2ZqE2I/ nj3Tt9QqLdHo8n7PO5Ogupw= X-Google-Smtp-Source: APXvYqxwcj00hjXa+f3SQjw+aGYTaVkqaB+xohA5rrkVZGQAHWxLq5pVnI0ssnIncUoOxBNaV+lIWw== X-Received: by 2002:ac8:2632:: with SMTP id u47mr4438554qtu.54.1573141727397; Thu, 07 Nov 2019 07:48:47 -0800 (PST) Received: from [172.19.36.136] ([2001:4878:a048:3000:446d:ab8d:382f:2dcb]) by smtp.gmail.com with ESMTPSA id f24sm1153360qkh.81.2019.11.07.07.48.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Nov 2019 07:48:43 -0800 (PST) From: "Aaron Falk" To: "Tommy Pauly" Cc: "Brian Trammell" , "taps WG" , "Philipp S. Tiesel" , "Kyle Rose" , "Zaheduzzaman Sarker" Date: Thu, 07 Nov 2019 10:48:29 -0500 X-Mailer: MailMate (1.13r5655) Message-ID: In-Reply-To: <47A9A4CF-406C-4A92-AE0C-5594FB690331@apple.com> References: <5C95DA93-91D3-44C1-BDF2-09667092FC12@gmail.com> <5BEA272C-BF1C-4CEA-823D-0297282543E5@in-panik.de> <27D8D383-E3AB-47C1-B1AF-488C703A44BC@gmail.com> <39D5EDBC-97BD-4980-878F-442A144313A5@gmail.com> <47A9A4CF-406C-4A92-AE0C-5594FB690331@apple.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_85EF597A-08C8-4545-A92D-04941953CE7D_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[474, 10430], "plain":[122, 5607], "uuid":"611D6EAA-844E-49FE-A3AB-0FA65CB8E9E7"}] Archived-At: Subject: Re: [Taps] call for TAPS agenda topics 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, 07 Nov 2019 15:48:52 -0000 --=_MailMate_85EF597A-08C8-4545-A92D-04941953CE7D_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Thanks, Tommy. Who will talk about -architecture & -security? --aaron On 6 Nov 2019, at 19:53, Tommy Pauly wrote: > I can lead the discussion around implementation issues, as Anna will > be remote. > > Best, > Tommy > >> On Nov 6, 2019, at 2:54 PM, Aaron Falk wrote: >> >> Thanks, Brian. >> >> We need discussion leads for -architecture, -implementation, and >> -security. >> >> --aaron >> >> On 5 Nov 2019, at 0:58, Brian Trammell (IETF) wrote: >> >> I can do the issue scrub for -interface. >> >> Sent from my iPhone >> >> On 5 Nov 2019, at 00:09, Aaron Falk > > wrote: >> >>> Draft agenda based on what I’ve heard. Putting the security draft >>> last as I’m uncertain at this point whether the discussion will >>> converge. Also, rather than Philipp’s list of topics, I suggest >>> someone should scrub the open issues. Who should drive the >>> discussion? Other comments? >>> >>> Administrivia (10m) - Chairs >>> Issue review for (50m) >>> draft-ietf-taps-architecture-05 >>> >>> draft-ietf-taps-interface-05 >>> >>> draft-ietf-taps-implementation-05 >>> >>> IETF last call comments on draft-ietf-taps-security-09 >>> >>> (30m) >>> Ref [from Ekr >>> ] >>> [from Christian >>> ] >>> What are our next steps? >>> --aaron >>> >>> On 4 Nov 2019, at 16:26, Brian Trammell (IETF) wrote: >>> >>> hi Philipp, all, >>> >>> parachuting-into-the-thread comments inline below. >>> >>> On 4 Nov 2019, at 21:36, Philipp S. Tiesel >> > wrote: >>> >>> >>> >>> AVE! >>> Philipp S. Tiesel >>> >>> -- >>> Philipp S. Tiesel >>> https://philipp.tiesel.net/ >>> On 4. Nov 2019, at 19:18, Kyle Rose >> > wrote: >>> >>> Evidently, the transport security document. >>> >>> Yes, we need to discuss next steps there. I still hope there will be >>> some discussion >>> on the list this and next week so we do not need to spend too much >>> precious face time >>> with this issue. >>> >>> I also see the state of the three other documents as agenda Items: >>> - Architecture >>> - Should be nearly finished, but for those you have not read one of >>> the last two versions, >>> please do so and give feedback! >>> >>> IIRC we'd said we wanted to hold this until at least interface was >>> done. But yes, please read this :) (I should re-read, actually). >>> >>> - Interface >>> >>> I think you've identified the three pending discussions correctly on >>> this doc... >>> >>> - Framers >>> >>> I need to dig into this a bit (and hope to before Singapore, but I >>> also hoped to have cycles before the interim that didn't happen so >>> MMMV) but I'm a lot happier with the general arrangement in -05 with >>> the bulk of the framer detail in -impl. >>> >>> - Errors >>> >>> I continue to think that something along the lines of the present >>> underspecification is not wrong here. But we should probably have >>> more text about the shape of that underspecification. >>> >>> - Multicast >>> >>> ...continues to be the swamp into which all transport efforts wade >>> and subsequently get eaten by rodents of unusual size. :) >>> >>> Practically speaking, this boils down to two issues AFAICT: >>> >>> - We have https://github.com/ietf-tapswg/api-drafts/issues/303 >>> on multicast >>> transport properties. This is marked Ready For Text and assigned to >>> tfpauly, so I'm inclined to let Tommy write some text here (or >>> assign someone else if they'd like to take a crack at it). >>> >>> - We have https://github.com/ietf-tapswg/api-drafts/issues/150 >>> which has a >>> long and varied history which you should go read if you're not >>> familiar with it (or if, like me, you'd forgotten it): >>> >>> - dup'd to https://github.com/ietf-tapswg/api-drafts/issues/170 >>> , which was >>> closed by PR on 6 Jun 2018 >>> - reopened to explictly address multicast interaction, languished >>> without discussion for six months >>> - tagged ready for text in January with an assigned volunteer (Jake) >>> but no discussion or guidance otherwise >>> >>> I propose we come to a decision on this in Singapore: commit to text >>> soon (end 2019) or ship without. >>> >>> Cheers, >>> >>> Brian >>> >>> - Implementation >>> - Are we satisfied with the structure >>> - Proxies/Tor/etc… >>> - Multicast >>> >>> On Mon, Nov 4, 2019 at 8:33 AM Aaron Falk >> > wrote: >>> Ok, gang, what should we discuss in Singapore? >>> >>> --aaron >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>> >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps --=_MailMate_85EF597A-08C8-4545-A92D-04941953CE7D_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Thanks, Tommy.

Who will talk about -architecture & -security?

--aaron

On 6 Nov 2019, at 19:53, Tommy Pauly wrote:

I can lead the discussion around implement= ation issues, as Anna will be remote.

Best,
Tommy

On Nov 6, 2019, at 2:54 PM, Aaron Falk <aaron.falk@gmail.com> wrote:

Thanks, Brian.

We need discussion leads for -architecture, -implem= entation, and -security.

--aaron

On 5 Nov 2019, at 0:58, Brian Trammell (IETF) wrote:

I can do the issue scrub= for -interface.

Sent from my iPhone

On 5= Nov 2019, at 00:09, Aaron Falk <aaron.falk@gmail.com> wrote:

Draft agenda based on wha= t I=E2=80=99ve heard. Putting the security draft last as I=E2=80=99m unce= rtain at this point whether the discussion will converge. Also, rather th= an Philipp=E2=80=99s list of topics, I suggest someone should scrub the o= pen issues. Who should drive the discussion? Other comments?

  1. Administrivia (10m) - Chairs
  2. Issue review for (50m)
  3. IETF last call comments on draft-ietf-taps-security-09 (30m)

--aaron

On = 4 Nov 2019, at 16:26, Brian Trammell (IETF) wrote:

hi Philipp, all,

parachuting-into-the-thread comments inline below.

On 4 Nov 2019, at 21:36, Philipp S. Tiesel <phils@in-panik.de> wrote:



AVE!
Philipp S. Tiesel

--
Philipp S. Tiesel
h= ttps://philipp.tiesel.net/

On 4. Nov 2019, at 19:18, Kyle Rose <krose@krose.org> wrote:

Evidently, the transport security document.

Yes, we need to discuss next step= s there. I still hope there will be some discussion
on the list this and next week so we do not need to spend too much precio= us face time
with this issue.

I also see the state of the three other documents as agenda Items:
- Architecture
- Should be nearly finished, but for those you have not read one of the= last two versions,
please do so and give feedback!

IIRC we'd said we wanted to hold = this until at least interface was done. But yes, please read this :) (I s= hould re-read, actually).

- Interface

I think you've identified the thr= ee pending discussions correctly on this doc...

- Framers

I need to dig into this a bit (an= d hope to before Singapore, but I also hoped to have cycles before the in= terim that didn't happen so MMMV) but I'm a lot happier with the general = arrangement in -05 with the bulk of the framer detail in -impl.

- Errors

I continue to think that somethin= g along the lines of the present underspecification is not wrong here. Bu= t we should probably have more text about the shape of that underspecific= ation.

- Multicast

...continues to be the swamp into= which all transport efforts wade and subsequently get eaten by rodents o= f unusual size. :)

Practically speaking, this boils down to two issues AFAICT:

- We have https://github.com/ietf-tapswg/api-draf= ts/issues/303 on multicast transport properties. This is marked Ready= For Text and assigned to tfpauly, so I'm inclined to let Tommy write som= e text here (or assign someone else if they'd like to take a crack at it)= =2E

- We have https://github.com/ietf-tapswg/api-draf= ts/issues/150 which has a long and varied history which you should go= read if you're not familiar with it (or if, like me, you'd forgotten it)= :

- dup'd to https://github.com/ietf-tapswg/api-d= rafts/issues/170, which was closed by PR on 6 Jun 2018
= - reopened to explictly address multicast interaction, languished witho= ut discussion for six months
- tagged ready for text in January with an assigned volunteer (Jake) bu= t no discussion or guidance otherwise

I propose we come to a decision on this in Singapore: commit to text soon= (end 2019) or ship without.

Cheers,

Brian

- Implementation
- Are we satisfied with the structure
- Proxies/Tor/etc=E2=80=A6
- Multicast

On Mon, Nov 4, 2019 at 8:33 AM Aaron Falk <aaron.falk@gmail.com> wrote: Ok, gang, what should we discuss in Singapore?

--aaron

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

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

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

<= /blockquote>
--=_MailMate_85EF597A-08C8-4545-A92D-04941953CE7D_=-- From nobody Thu Nov 7 10:16:41 2019 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 5DB4A12090E for ; Thu, 7 Nov 2019 10:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 Dq6YTwjqVXwW for ; Thu, 7 Nov 2019 10:16:37 -0800 (PST) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 2870412013F for ; Thu, 7 Nov 2019 10:16:37 -0800 (PST) Received: from smtp7.infomaniak.ch (smtp7.infomaniak.ch [83.166.132.30]) by smtp-sh2.infomaniak.ch (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id xA7IGNhD236266 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 7 Nov 2019 19:16:23 +0100 Received: from [100.99.40.169] ([213.55.225.117]) (authenticated bits=0) by smtp7.infomaniak.ch (8.14.5/8.14.5) with ESMTP id xA7IGLaa004762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Nov 2019 19:16:22 +0100 Content-Type: multipart/alternative; boundary=Apple-Mail-3BCA23E8-F169-4654-A3EE-9DCA879ECF6E Mime-Version: 1.0 (1.0) From: "Brian Trammell (IETF)" X-Mailer: iPhone Mail (16G102) In-Reply-To: Date: Thu, 7 Nov 2019 19:16:21 +0100 Cc: Tommy Pauly , taps WG , "Philipp S. Tiesel" , Kyle Rose , Zaheduzzaman Sarker Content-Transfer-Encoding: 7bit Message-Id: <2E5698B5-54AB-47DE-A00C-C07E2C5EC0B7@trammell.ch> References: <5C95DA93-91D3-44C1-BDF2-09667092FC12@gmail.com> <5BEA272C-BF1C-4CEA-823D-0297282543E5@in-panik.de> <27D8D383-E3AB-47C1-B1AF-488C703A44BC@gmail.com> <39D5EDBC-97BD-4980-878F-442A144313A5@gmail.com> <47A9A4CF-406C-4A92-AE0C-5594FB690331@apple.com> To: Aaron Falk X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Taps] call for TAPS agenda topics 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, 07 Nov 2019 18:16:40 -0000 --Apple-Mail-3BCA23E8-F169-4654-A3EE-9DCA879ECF6E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I can take architecture too =E2=80=94 the list should be short ;) Sent from my iPhone > On 7 Nov 2019, at 16:48, Aaron Falk wrote: >=20 > Thanks, Tommy. >=20 > Who will talk about -architecture & -security? >=20 > --aaron >=20 > On 6 Nov 2019, at 19:53, Tommy Pauly wrote: >=20 > I can lead the discussion around implementation issues, as Anna will be re= mote. >=20 > Best, > Tommy >=20 >> On Nov 6, 2019, at 2:54 PM, Aaron Falk wrote: >>=20 >> Thanks, Brian. >>=20 >> We need discussion leads for -architecture, -implementation, and -securit= y. >>=20 >> --aaron >>=20 >> On 5 Nov 2019, at 0:58, Brian Trammell (IETF) wrote: >>=20 >> I can do the issue scrub for -interface. >>=20 >> Sent from my iPhone >>=20 >>> On 5 Nov 2019, at 00:09, Aaron Falk wrote: >>>=20 >>> Draft agenda based on what I=E2=80=99ve heard. Putting the security draf= t last as I=E2=80=99m uncertain at this point whether the discussion will co= nverge. Also, rather than Philipp=E2=80=99s list of topics, I suggest someon= e should scrub the open issues. Who should drive the discussion? Other comme= nts? >>>=20 >>> Administrivia (10m) - Chairs >>> Issue review for (50m) >>> draft-ietf-taps-architecture-05 >>> draft-ietf-taps-interface-05 >>> draft-ietf-taps-implementation-05 >>> IETF last call comments on draft-ietf-taps-security-09 (30m) >>> Ref [from Ekr] [from Christian] >>> What are our next steps? >>> --aaron >>>=20 >>> On 4 Nov 2019, at 16:26, Brian Trammell (IETF) wrote: >>>=20 >>> hi Philipp, all, >>>=20 >>> parachuting-into-the-thread comments inline below. >>>=20 >>> On 4 Nov 2019, at 21:36, Philipp S. Tiesel wrote: >>>=20 >>>=20 >>>=20 >>> AVE! >>> Philipp S. Tiesel >>>=20 >>> -- >>> Philipp S. Tiesel >>> https://philipp.tiesel.net/ >>>=20 >>> On 4. Nov 2019, at 19:18, Kyle Rose wrote: >>>=20 >>> Evidently, the transport security document. >>>=20 >>> Yes, we need to discuss next steps there. I still hope there will be som= e discussion >>> on the list this and next week so we do not need to spend too much preci= ous face time >>> with this issue. >>>=20 >>> I also see the state of the three other documents as agenda Items: >>> - Architecture >>> - Should be nearly finished, but for those you have not read one of the l= ast two versions, >>> please do so and give feedback! >>>=20 >>> IIRC we'd said we wanted to hold this until at least interface was done.= But yes, please read this :) (I should re-read, actually). >>>=20 >>> - Interface >>>=20 >>> I think you've identified the three pending discussions correctly on thi= s doc... >>>=20 >>> - Framers >>>=20 >>> I need to dig into this a bit (and hope to before Singapore, but I also h= oped to have cycles before the interim that didn't happen so MMMV) but I'm a= lot happier with the general arrangement in -05 with the bulk of the framer= detail in -impl. >>>=20 >>> - Errors >>>=20 >>> I continue to think that something along the lines of the present unders= pecification is not wrong here. But we should probably have more text about t= he shape of that underspecification. >>>=20 >>> - Multicast >>>=20 >>> ...continues to be the swamp into which all transport efforts wade and s= ubsequently get eaten by rodents of unusual size. :) >>>=20 >>> Practically speaking, this boils down to two issues AFAICT: >>>=20 >>> - We have https://github.com/ietf-tapswg/api-drafts/issues/303 on multic= ast transport properties. This is marked Ready For Text and assigned to tfpa= uly, so I'm inclined to let Tommy write some text here (or assign someone el= se if they'd like to take a crack at it). >>>=20 >>> - We have https://github.com/ietf-tapswg/api-drafts/issues/150 which has= a long and varied history which you should go read if you're not familiar w= ith it (or if, like me, you'd forgotten it): >>>=20 >>> - dup'd to https://github.com/ietf-tapswg/api-drafts/issues/170, which w= as closed by PR on 6 Jun 2018 >>> - reopened to explictly address multicast interaction, languished withou= t discussion for six months >>> - tagged ready for text in January with an assigned volunteer (Jake) but= no discussion or guidance otherwise >>>=20 >>> I propose we come to a decision on this in Singapore: commit to text soo= n (end 2019) or ship without. >>>=20 >>> Cheers, >>>=20 >>> Brian >>>=20 >>> - Implementation >>> - Are we satisfied with the structure >>> - Proxies/Tor/etc=E2=80=A6 >>> - Multicast >>>=20 >>> On Mon, Nov 4, 2019 at 8:33 AM Aaron Falk wrote: >>> Ok, gang, what should we discuss in Singapore? >>>=20 >>> --aaron >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>>=20 >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 --Apple-Mail-3BCA23E8-F169-4654-A3EE-9DCA879ECF6E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I can take architecture too =E2=80=94 the l= ist should be short ;)

Sen= t from my iPhone

On 7 Nov 2019, at 16:48, Aaron Fa= lk <aaron.falk@gmail.com> w= rote:

Thanks, Tommy.

Who will talk about -architecture & -security?

--aaron

On 6 Nov 2019, at 19:53, Tommy Pauly wrote:

I can lead the discussion around implementation issues= , as Anna will be remote.

Best,
Tommy

On Nov 6, 2019= , at 2:54 PM, Aaron Falk <aaron.falk@gmail.com> wrote:

Thanks, Brian.

We need discussion leads for -architecture, -implementation,= and -security.

--aaron

On 5 Nov 2019, at 0:58, Brian Trammell (IETF) wrote:

I can do the issue scrub for -int= erface.

Sent from m= y iPhone

On 5 Nov 2019, at 0= 0:09, Aaron Falk <aaro= n.falk@gmail.com> wrote:

Draft agenda based on what I=E2= =80=99ve heard. Putting the security draft last as I=E2=80=99m uncertain at t= his point whether the discussion will converge. Also, rather than Philipp=E2= =80=99s list of topics, I suggest someone should scrub the open issues. Who s= hould drive the discussion? Other comments?

  1. Administrivia (10m) - Chairs
  2. Issue review for (50m)
  3. IETF last call comments on draft-ietf-taps-security-09 (30m)

--aaron

On 4 N= ov 2019, at 16:26, Brian Trammell (IETF) wrote:

<= p dir=3D"auto" class=3D"">hi Philipp, all,

parachuting-into-the-thread comments inline below.

On 4 Nov 2019, at 21:36, Philipp S. Tiesel <phils@in-panik.de> wrote:



AVE!
Philipp S. Tiesel

--
Philipp S. Tiesel
http= s://philipp.tiesel.net/

On 4. Nov 2019, at 19:18, Kyle Rose <krose@krose.org> wrote:

Evidently, the transport security document.

Yes, we need to discuss next steps t= here. I still hope there will be some discussion
on the list this and next week so we do not need to spend too much precious f= ace time
with this issue.

I also see the state of the three other documents as agenda Items:
- Architecture
- Should be nearly finished, but for those you have not read one of the la= st two versions,
please do so and give feedback!

IIRC we'd said we wanted to hold thi= s until at least interface was done. But yes, please read this :) (I should r= e-read, actually).

- Interface

I think you've identified the three p= ending discussions correctly on this doc...

- Framers

I need to dig into this a bit (and h= ope to before Singapore, but I also hoped to have cycles before the interim t= hat didn't happen so MMMV) but I'm a lot happier with the general arrangemen= t in -05 with the bulk of the framer detail in -impl.

- Errors

I continue to think that something a= long the lines of the present underspecification is not wrong here. But we s= hould probably have more text about the shape of that underspecification.

- Multicast

...continues to be the swamp into wh= ich all transport efforts wade and subsequently get eaten by rodents of unus= ual size. :)

Practically speaking, this boils down to two issues AFAICT:

- We have https://github.com/ietf-tapswg/api-drafts/iss= ues/303 on multicast transport properties. This is marked Ready For Text= and assigned to tfpauly, so I'm inclined to let Tommy write some text here (= or assign someone else if they'd like to take a crack at it).
=
- We have https://github.com/ietf-tapswg/api-drafts/iss= ues/150 which has a long and varied history which you should go read if y= ou're not familiar with it (or if, like me, you'd forgotten it):

- dup'd to https://github.com/ietf-tapswg/api-drafts/= issues/170, which was closed by PR on 6 Jun 2018
- reopened to explictly address multicast interaction, languished without d= iscussion for six months
- tagged ready for text in January with an assigned volunteer (Jake) but n= o discussion or guidance otherwise

I propose we come to a decision on this in Singapore: commit to text soon (e= nd 2019) or ship without.

Cheers,

Brian

- Implementation
- Are we satisfied with the structure
- Proxies/Tor/etc=E2=80=A6
- Multicast

On Mon, Nov 4, 2019 at 8:33 AM Aaron Falk <aaron.falk@gmail.com> wrote:
Ok, gang, what should we discuss in Singapore?

--aaron

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

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

_______________________________________________
Taps mailing l= ist
Taps@ietf.org<= /a>
htt= ps://www.ietf.org/mailman/listinfo/taps

= --Apple-Mail-3BCA23E8-F169-4654-A3EE-9DCA879ECF6E-- From nobody Fri Nov 8 00:02:19 2019 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 C7C3F12009E for ; Fri, 8 Nov 2019 00:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 p8_Eu5vEk9OB for ; Fri, 8 Nov 2019 00:02:16 -0800 (PST) Received: from magpie.corvid.ch (magpie.corvid.ch [46.101.110.207]) (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 D5D4612003E for ; Fri, 8 Nov 2019 00:02:15 -0800 (PST) Received: from [127.0.0.1] (helo=magpie.corvid.ch) by magpie.corvid.ch with esmtp (Exim 4.92) (envelope-from ) id 1iSzBc-0000IJ-82 for taps@ietf.org; Fri, 08 Nov 2019 08:00:04 +0000 Content-Type: multipart/alternative; boundary="===============3642774850610566070==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 08 Nov 2019 08:00:04 +0000 Archived-At: Subject: [Taps] Weekly github digest (TAPS GitHub Activity Digest) 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, 08 Nov 2019 08:02:18 -0000 --===============3642774850610566070== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * ietf-tapswg/api-drafts (+0/-2/=F0=9F=92=AC1) 1 issues received 1 new comments: - #357 Default values (1 by gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/357 [API] [discuss] = 2 issues closed: - Add text about connection coalescing and connection pooling https://git= hub.com/ietf-tapswg/api-drafts/issues/339 [Implementation] [ready for text] = - Make InitiateError more generic https://github.com/ietf-tapswg/api-draf= ts/issues/341 [API] = Pull requests ------------- * ietf-tapswg/api-drafts (+1/-3/=F0=9F=92=AC0) 1 pull requests submitted: - Move Message Framer implementation details to implementation (by tfpaul= y) https://github.com/ietf-tapswg/api-drafts/pull/359 = 3 pull requests merged: - Move Message Framer implementation details to implementation https://github.com/ietf-tapswg/api-drafts/pull/359 = - Introduce pooled connections as optional implementation detail https://github.com/ietf-tapswg/api-drafts/pull/358 = - Allow for error events to include an optional reason https://github.com/ietf-tapswg/api-drafts/pull/351 = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============3642774850610566070== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday November 08, 2019

Issues

ietf-tapswg/api-drafts (+0/-2/=F0=9F=92=AC1)

1 issues received 1 new comments:

2 issues closed:

Pull requests

ietf-tapswg/api-drafts (+1/-3/=F0=9F=92=AC0)

1 pull requests submitted:

3 pull requests merged:

Repositories tracked by this digest:

--===============3642774850610566070==-- From nobody Fri Nov 8 01:45:53 2019 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 099D9120870 for ; Fri, 8 Nov 2019 01:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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 F_GXMrwY0NPr for ; Fri, 8 Nov 2019 01:45:48 -0800 (PST) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 46BE4120866 for ; Fri, 8 Nov 2019 01:45:47 -0800 (PST) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id xA89jg0l025417 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 8 Nov 2019 10:45:42 +0100 Received: from p2e505233.dip0.t-ipconnect.de ([46.80.82.51] helo=c02z21drlvdm.fritz.box) by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1iT0nS-0007L3-3E; Fri, 08 Nov 2019 10:43:14 +0100 From: "Philipp S. Tiesel" Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_BFB86BFE-7354-48DA-A8FD-74433443018D" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Fri, 8 Nov 2019 10:45:41 +0100 In-Reply-To: Cc: taps WG To: Aaron Falk References: <5C95DA93-91D3-44C1-BDF2-09667092FC12@gmail.com> <5BEA272C-BF1C-4CEA-823D-0297282543E5@in-panik.de> <27D8D383-E3AB-47C1-B1AF-488C703A44BC@gmail.com> <39D5EDBC-97BD-4980-878F-442A144313A5@gmail.com> <47A9A4CF-406C-4A92-AE0C-5594FB690331@apple.com> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [Taps] call for TAPS agenda topics 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, 08 Nov 2019 09:45:51 -0000 --Apple-Mail=_BFB86BFE-7354-48DA-A8FD-74433443018D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 If none of the authors wants to moderate -security, I can do that. =20 AVE! Philipp S. Tiesel > On 7. Nov 2019, at 16:48, Aaron Falk wrote: >=20 > Thanks, Tommy. >=20 > Who will talk about -architecture & -security? >=20 > --aaron >=20 > On 6 Nov 2019, at 19:53, Tommy Pauly wrote: >=20 > I can lead the discussion around implementation issues, as Anna will = be remote. >=20 > Best, > Tommy >=20 >> On Nov 6, 2019, at 2:54 PM, Aaron Falk > wrote: >>=20 >> Thanks, Brian. >>=20 >> We need discussion leads for -architecture, -implementation, and = -security. >>=20 >> --aaron >>=20 >> On 5 Nov 2019, at 0:58, Brian Trammell (IETF) wrote: >>=20 >> I can do the issue scrub for -interface. >>=20 >> Sent from my iPhone >>=20 >> On 5 Nov 2019, at 00:09, Aaron Falk > wrote: >>=20 >>> Draft agenda based on what I=E2=80=99ve heard. Putting the security = draft last as I=E2=80=99m uncertain at this point whether the discussion = will converge. Also, rather than Philipp=E2=80=99s list of topics, I = suggest someone should scrub the open issues. Who should drive the = discussion? Other comments? >>>=20 >>> Administrivia (10m) - Chairs >>> Issue review for (50m) >>> draft-ietf-taps-architecture-05 = >>> draft-ietf-taps-interface-05 = >>> draft-ietf-taps-implementation-05 = >>> IETF last call comments on draft-ietf-taps-security-09 = = (30m) >>> Ref [from Ekr = ] = [from Christian = ]= >>> What are our next steps? >>> --aaron >>>=20 >>> On 4 Nov 2019, at 16:26, Brian Trammell (IETF) wrote: >>>=20 >>> hi Philipp, all, >>>=20 >>> parachuting-into-the-thread comments inline below. >>>=20 >>> On 4 Nov 2019, at 21:36, Philipp S. Tiesel > wrote: >>>=20 >>>=20 >>>=20 >>> AVE! >>> Philipp S. Tiesel >>>=20 >>> -- >>> Philipp S. Tiesel >>> https://philipp.tiesel.net/ >>> On 4. Nov 2019, at 19:18, Kyle Rose > wrote: >>>=20 >>> Evidently, the transport security document. >>>=20 >>> Yes, we need to discuss next steps there. I still hope there will be = some discussion >>> on the list this and next week so we do not need to spend too much = precious face time >>> with this issue. >>>=20 >>> I also see the state of the three other documents as agenda Items: >>> - Architecture >>> - Should be nearly finished, but for those you have not read one of = the last two versions, >>> please do so and give feedback! >>>=20 >>> IIRC we'd said we wanted to hold this until at least interface was = done. But yes, please read this :) (I should re-read, actually). >>>=20 >>> - Interface >>>=20 >>> I think you've identified the three pending discussions correctly on = this doc... >>>=20 >>> - Framers >>>=20 >>> I need to dig into this a bit (and hope to before Singapore, but I = also hoped to have cycles before the interim that didn't happen so MMMV) = but I'm a lot happier with the general arrangement in -05 with the bulk = of the framer detail in -impl. >>>=20 >>> - Errors >>>=20 >>> I continue to think that something along the lines of the present = underspecification is not wrong here. But we should probably have more = text about the shape of that underspecification. >>>=20 >>> - Multicast >>>=20 >>> ...continues to be the swamp into which all transport efforts wade = and subsequently get eaten by rodents of unusual size. :) >>>=20 >>> Practically speaking, this boils down to two issues AFAICT: >>>=20 >>> - We have https://github.com/ietf-tapswg/api-drafts/issues/303 = on multicast = transport properties. This is marked Ready For Text and assigned to = tfpauly, so I'm inclined to let Tommy write some text here (or assign = someone else if they'd like to take a crack at it). >>>=20 >>> - We have https://github.com/ietf-tapswg/api-drafts/issues/150 = which has a long = and varied history which you should go read if you're not familiar with = it (or if, like me, you'd forgotten it): >>>=20 >>> - dup'd to https://github.com/ietf-tapswg/api-drafts/issues/170 = , which was closed = by PR on 6 Jun 2018 >>> - reopened to explictly address multicast interaction, languished = without discussion for six months >>> - tagged ready for text in January with an assigned volunteer (Jake) = but no discussion or guidance otherwise >>>=20 >>> I propose we come to a decision on this in Singapore: commit to text = soon (end 2019) or ship without. >>>=20 >>> Cheers, >>>=20 >>> Brian >>>=20 >>> - Implementation >>> - Are we satisfied with the structure >>> - Proxies/Tor/etc=E2=80=A6 >>> - Multicast >>>=20 -- =20 Philipp S. Tiesel https://philipp.tiesel.net/ --Apple-Mail=_BFB86BFE-7354-48DA-A8FD-74433443018D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 If = none of the authors wants to moderate -security, I can do that.
 
AVE!
   Philipp S. = Tiesel

On 7. Nov 2019, at 16:48, Aaron = Falk <aaron.falk@gmail.com> wrote:

Thanks,= Tommy.

Who will talk about = -architecture & -security?

--aaron

On 6 Nov 2019, at 19:53, Tommy Pauly wrote:

I can lead the discussion around = implementation issues, as Anna will be remote.

Best,
Tommy

On Nov 6, 2019, at 2:54 PM, = Aaron Falk <aaron.falk@gmail.com> wrote:

Thanks,= Brian.

We need discussion leads for = -architecture, -implementation, and -security.

--aaron

On 5 Nov 2019, at 0:58, = Brian Trammell (IETF) wrote:

I can do the issue scrub for -interface.

Sent from my iPhone

On 5 Nov 2019, at 00:09, Aaron = Falk <aaron.falk@gmail.com> wrote:

Draft = agenda based on what I=E2=80=99ve heard. Putting the security draft last = as I=E2=80=99m uncertain at this point whether the discussion will = converge. Also, rather than Philipp=E2=80=99s list of topics, I suggest = someone should scrub the open issues. Who should drive the discussion? = Other comments?

  1. Administrivia (10m) - Chairs
  2. Issue review for (50m)
  3. IETF last call comments on draft-ietf-taps-security-09 = (30m)

--aaron

On = 4 Nov 2019, at 16:26, Brian Trammell (IETF) wrote:

hi Philipp, = all,

parachuting-into-the-thread comments inline below.

On 4 Nov 2019, at 21:36, Philipp S. Tiesel <phils@in-panik.de> = wrote:



AVE!
Philipp S. Tiesel

--
Philipp S. Tiesel
https://philipp.tiesel.net/

On 4. Nov 2019, at 19:18, Kyle Rose <krose@krose.org> = wrote:

Evidently, the transport security document.

Yes, we need to discuss next = steps there. I still hope there will be some discussion
on the list this and next week so we do not need to spend too much = precious face time
with this issue.

I also see the state of the three other documents as agenda Items:
- Architecture
- Should be nearly finished, but for those you have not read one of = the last two versions,
please do so and give feedback!

IIRC we'd said we wanted to hold = this until at least interface was done. But yes, please read this :) (I = should re-read, actually).

- Interface

I think you've identified the = three pending discussions correctly on this doc...

- Framers

I need to dig into this a bit = (and hope to before Singapore, but I also hoped to have cycles before = the interim that didn't happen so MMMV) but I'm a lot happier with the = general arrangement in -05 with the bulk of the framer detail in = -impl.

- Errors

I continue to think that = something along the lines of the present underspecification is not wrong = here. But we should probably have more text about the shape of that = underspecification.

- Multicast

...continues to be the swamp = into which all transport efforts wade and subsequently get eaten by = rodents of unusual size. :)

Practically speaking, this boils down to two issues AFAICT:
=
- We have https://github.com/ietf-tapswg/api-drafts/issues/303 on = multicast transport properties. This is marked Ready For Text and = assigned to tfpauly, so I'm inclined to let Tommy write some text here = (or assign someone else if they'd like to take a crack at it).

- We have https://github.com/ietf-tapswg/api-drafts/issues/150 = which has a long and varied history which you should go read if you're = not familiar with it (or if, like me, you'd forgotten it):

- dup'd to https://github.com/ietf-tapswg/api-drafts/issues/170, = which was closed by PR on 6 Jun 2018
- reopened to explictly address multicast interaction, languished = without discussion for six months
- tagged ready for text in January with an assigned volunteer (Jake) = but no discussion or guidance otherwise

I propose we come to a decision on this in Singapore: commit to text = soon (end 2019) or ship without.

Cheers,

Brian

- Implementation
- Are we satisfied with the structure
- Proxies/Tor/etc=E2=80=A6
- Multicast

=
--  
Philipp = S. Tiesel
https://philipp.tiesel.net/


= --Apple-Mail=_BFB86BFE-7354-48DA-A8FD-74433443018D-- From nobody Thu Nov 14 10:19:04 2019 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 13A781209AD; Thu, 14 Nov 2019 10:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 Q-mwWq1AlFTD; Thu, 14 Nov 2019 10:18:54 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 E21F412083D; Thu, 14 Nov 2019 10:18:49 -0800 (PST) Received: from [46.183.103.8] (helo=[172.18.209.93]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iVJhf-0002mG-T7; Thu, 14 Nov 2019 19:18:47 +0100 From: Mirja Kuehlewind Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <5E74FD29-90C3-4CFD-9971-2FA7ECAC90D3@kuehlewind.net> Date: Thu, 14 Nov 2019 19:18:46 +0100 Cc: webtransport-request@ietf.org To: taps@ietf.org X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1573755529;50204fd9; X-HE-SMSGID: 1iVJhf-0002mG-T7 Archived-At: Subject: [Taps] WebTransport and taps 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, 14 Nov 2019 18:19:02 -0000 Hi taps folks (also cc=E2=80=99ing the WebTransport list), I assume that people on the taps list are aware of the WebTransport = effort that will have a BoF meeting on 13:30-15:00 Wednesday. I had = another look at the WebTransport documents today in order to better = understand the scope of WebTransport compared to taps.=20 Looking at = https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 I believe = that this should be covered by pooled connections in taps + use of = partial messages. WebTransport proposes to use streams as the base = concept while we in taps explicitly decided against this but to use = messages instead which also aligns with other protocols that are = discussed in WebTransports like Websockets and WebRTC data channels. = Unfortunately the draft doesn=E2=80=99t give any reasoning for that = choice but I would still think that use of particle messages in taps = should be equivalent at it is explicitly designed to address = applications that actually need streaming. What do people think? Further looking at = https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 this draft = defines a new ALPN value and a QUIC extension. I guess in taps we have = not explicitly considered ALPN so far but we really would need to do = that in any case! I guess one could see this as a protocol specific = property but maybe it=E2=80=99s even worth to be more explicit here. Did = anybody consider ALPN already? Regarding the new QUIC transport parameter I have to say that the = purpose it not fully clear to me from the draft. However it seems that = this is supposed to support some kind of access control that is = performed on the application layer but by a more trusted entity than the = client application itself. It is not fully clear to me what the trust = assumptions are, however it does seems that is should not be a transport = parameter that is protocol specific but rather some function on the = higher layer. However, to be able to make a proposal here, I would = probably need to understand the purpose better. Do people have any = insights? Do people have thoughts? What is missing in taps to also cover the full = web use case? Is that something we want to account for in taps? Or what = is the difference that would not fit with the taps approach? What am I = missing? Mirja From nobody Thu Nov 14 14:17:04 2019 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 D3EA9120025; Thu, 14 Nov 2019 14:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 HEyh99PtvXYK; Thu, 14 Nov 2019 14:17:01 -0800 (PST) Received: from nwk-aaemail-lapp01.apple.com (nwk-aaemail-lapp01.apple.com [17.151.62.66]) (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 07A25120019; Thu, 14 Nov 2019 14:17:01 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id xAEMCYjv065262; Thu, 14 Nov 2019 14:16:59 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=k0tkAEGO7C7Mbw0vaAy+XoIddp5LXVwEpXwz0NAH3JQ=; b=NipAKCmEMhx+7XTSH0idQWLYHRhU4hiJrjY08fPqjgc5c7jDUoWBrmb3YHO86zillwQv ZzlPyz/z/xa82poqHewV8k8UP6JVUp06aQwaeB2HvJBF9vhqIzzC0rMoTuUCFhwtDT6X CDLUCGx3ppSmxmsm37p0b/FvE/2tghCT9Yfh1fZIcFhgbAGoeM2DlF9pcNhxjuZCygmM iCpjYYACYLMokDadLiLJfzTN/lOAFIGMPosdxLxhunVpMks1+aPApY7DBzqKdGFXEBvH Cqb8Ru/0z9CsbP3qaNQ58xfOvJAmf2T0AvhiKxTkjINGsASCn2M6sFgZXtzVDsEIOBOo jw== Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) by nwk-aaemail-lapp01.apple.com with ESMTP id 2w9fa18gn1-25 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 14 Nov 2019 14:16:59 -0800 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q0Z008M8CK7V0B0@mr2-mtap-s03.rno.apple.com>; Thu, 14 Nov 2019 14:16:56 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q0Z00B00CHQY900@nwk-mmpp-sz11.apple.com>; Thu, 14 Nov 2019 14:16:56 -0800 (PST) X-Va-A: X-Va-T-CD: d23c83608635fec7ec1c9230479bd305 X-Va-E-CD: be331bbc83c6a92968e811b57f4d23fc X-Va-R-CD: 33a2ea6ff90a919ae26a772b903df90f X-Va-CD: 0 X-Va-ID: fb6c7f24-cc48-4e18-ae9e-c2e574009d23 X-V-A: X-V-T-CD: d23c83608635fec7ec1c9230479bd305 X-V-E-CD: be331bbc83c6a92968e811b57f4d23fc X-V-R-CD: 33a2ea6ff90a919ae26a772b903df90f X-V-CD: 0 X-V-ID: d86cba59-038b-473f-b921-2fc5bdb963d9 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-14_05:,, signatures=0 Received: from [17.230.171.146] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q0Z00BOQCK7ND00@nwk-mmpp-sz11.apple.com>; Thu, 14 Nov 2019 14:16:55 -0800 (PST) Sender: tpauly@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) From: Tommy Pauly In-reply-to: <5E74FD29-90C3-4CFD-9971-2FA7ECAC90D3@kuehlewind.net> Date: Thu, 14 Nov 2019 14:16:53 -0800 Cc: taps@ietf.org, webtransport-request@ietf.org Content-transfer-encoding: quoted-printable Message-id: <3250EDAB-EFC6-4FDB-BFE5-AEF138A59845@apple.com> References: <5E74FD29-90C3-4CFD-9971-2FA7ECAC90D3@kuehlewind.net> To: Mirja Kuehlewind X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-14_05:, , signatures=0 Archived-At: Subject: Re: [Taps] WebTransport and taps 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, 14 Nov 2019 22:17:03 -0000 > On Nov 14, 2019, at 10:18 AM, Mirja Kuehlewind = wrote: >=20 > Hi taps folks (also cc=E2=80=99ing the WebTransport list), >=20 > I assume that people on the taps list are aware of the WebTransport = effort that will have a BoF meeting on 13:30-15:00 Wednesday. I had = another look at the WebTransport documents today in order to better = understand the scope of WebTransport compared to taps.=20 >=20 > Looking at = https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 I believe = that this should be covered by pooled connections in taps + use of = partial messages. WebTransport proposes to use streams as the base = concept while we in taps explicitly decided against this but to use = messages instead which also aligns with other protocols that are = discussed in WebTransports like Websockets and WebRTC data channels. = Unfortunately the draft doesn=E2=80=99t give any reasoning for that = choice but I would still think that use of particle messages in taps = should be equivalent at it is explicitly designed to address = applications that actually need streaming. What do people think? I think the notion of stream here is just a multiplexing concept; the = terminology doesn't follow the terminology in TAPS, but it's not at = odds. It's just a different phrasing. >=20 > Further looking at = https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 this draft = defines a new ALPN value and a QUIC extension. I guess in taps we have = not explicitly considered ALPN so far but we really would need to do = that in any case! I guess one could see this as a protocol specific = property but maybe it=E2=80=99s even worth to be more explicit here. Did = anybody consider ALPN already? ALPN is a TLS option, so it fits into the protocol-specific options. We = certainly have support for that in our implementation! = (https://developer.apple.com/documentation/security/2976269-sec_protocol_o= ptions_add_tls_app?language=3Dobjc) >=20 > Regarding the new QUIC transport parameter I have to say that the = purpose it not fully clear to me from the draft. However it seems that = this is supposed to support some kind of access control that is = performed on the application layer but by a more trusted entity than the = client application itself. It is not fully clear to me what the trust = assumptions are, however it does seems that is should not be a transport = parameter that is protocol specific but rather some function on the = higher layer. However, to be able to make a proposal here, I would = probably need to understand the purpose better. Do people have any = insights? =46rom the TAPS side, transport parameters in QUIC do need to be able to = be configured by the app or set as a default for a given use case, so = that shouldn't be an issue. >=20 > Do people have thoughts? What is missing in taps to also cover the = full web use case? Is that something we want to account for in taps? Or = what is the difference that would not fit with the taps approach? What = am I missing? Fundamentally, TAPS is about API shape and approach. It alone doesn't = define any new protocol knobs. If WebTransport needs new on-the-wire = protocol changes, those need to be independent. However, the shape of = creating connections, and sending and receiving messages, is something = that can certainly conform to a TAPS-compliant interface. If you read through draft-vvv-webtransport-overview, it largely outlines = something that is a TAPS interface, just without referencing TAPS or = calling that out. So, one way to view the relationship is that WebTransport as described = is a specific set of protocol features that a web-focused implementation = of a TAPS system ought to build, plus a few protocol tweaks below. Thanks, Tommy >=20 > Mirja >=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Nov 15 00:02:20 2019 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 BEA10120110 for ; Fri, 15 Nov 2019 00:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 I5tD7D0AiTkb for ; Fri, 15 Nov 2019 00:02:17 -0800 (PST) Received: from magpie.corvid.ch (magpie.corvid.ch [46.101.110.207]) (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 2952912010F for ; Fri, 15 Nov 2019 00:02:16 -0800 (PST) Received: from [127.0.0.1] (helo=magpie.corvid.ch) by magpie.corvid.ch with esmtp (Exim 4.92) (envelope-from ) id 1iVWWS-0006Zy-ED for taps@ietf.org; Fri, 15 Nov 2019 08:00:04 +0000 Content-Type: multipart/alternative; boundary="===============6084395654903823474==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 15 Nov 2019 08:00:04 +0000 Archived-At: Subject: [Taps] Weekly github digest (TAPS GitHub Activity Digest) 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, 15 Nov 2019 08:02:19 -0000 --===============6084395654903823474== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * ietf-tapswg/api-drafts (+0/-3/=F0=9F=92=AC2) 2 issues received 2 new comments: - #344 Framers: Move parts to Implementation draft (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/344 [API] [Implementat= ion] = - #342 Allow error events to include reason (1 by MaxF12) https://github.com/ietf-tapswg/api-drafts/issues/342 [API] = 3 issues closed: - Framers: Move parts to Implementation draft https://github.com/ietf-tap= swg/api-drafts/issues/344 [API] [Implementation] = - Nits on framers in arch-draft https://github.com/ietf-tapswg/api-drafts= /issues/348 [Architecture] = - Allow error events to include reason https://github.com/ietf-tapswg/api= -drafts/issues/342 [API] = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============6084395654903823474== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday November 15, 2019

Issues

ietf-tapswg/api-drafts (+0/-3/=F0=9F=92=AC2)

2 issues received 2 new comments:

3 issues closed:

Repositories tracked by this digest:

--===============6084395654903823474==-- From nobody Fri Nov 15 00:51:20 2019 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 47DC012013B; Fri, 15 Nov 2019 00:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 BgeT9VqCfLlp; Fri, 15 Nov 2019 00:51:15 -0800 (PST) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 07E3012013A; Fri, 15 Nov 2019 00:51:14 -0800 (PST) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id xAF8pANg010862 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 15 Nov 2019 09:51:10 +0100 Received: from [193.16.224.0] (helo=[10.16.32.16]) by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1iVXHV-0001u0-3s; Fri, 15 Nov 2019 09:48:41 +0100 From: "Philipp S. Tiesel" Message-Id: <8571226C-FD40-4467-B167-BBDE7B2D5653@in-panik.de> Content-Type: multipart/alternative; boundary="Apple-Mail=_A4BD20FD-3019-4AC6-B397-D18B776B0FFF" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Fri, 15 Nov 2019 09:51:01 +0100 In-Reply-To: <3250EDAB-EFC6-4FDB-BFE5-AEF138A59845@apple.com> Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , webtransport-request@ietf.org, taps@ietf.org To: Tommy Pauly References: <5E74FD29-90C3-4CFD-9971-2FA7ECAC90D3@kuehlewind.net> <3250EDAB-EFC6-4FDB-BFE5-AEF138A59845@apple.com> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [Taps] WebTransport and taps 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, 15 Nov 2019 08:51:18 -0000 --Apple-Mail=_A4BD20FD-3019-4AC6-B397-D18B776B0FFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On 14. Nov 2019, at 23:16, Tommy Pauly = wrote: >> On Nov 14, 2019, at 10:18 AM, Mirja Kuehlewind = wrote: >>=20 >> Hi taps folks (also cc=E2=80=99ing the WebTransport list), >>=20 >> I assume that people on the taps list are aware of the WebTransport = effort that will have a BoF meeting on 13:30-15:00 Wednesday. I had = another look at the WebTransport documents today in order to better = understand the scope of WebTransport compared to taps.=20 >>=20 >> Looking at = https://tools.ietf.org/html/draft-vvv-webtransport-overview-00 I believe = that this should be covered by pooled connections in taps + use of = partial messages. WebTransport proposes to use streams as the base = concept while we in taps explicitly decided against this but to use = messages instead which also aligns with other protocols that are = discussed in WebTransports like Websockets and WebRTC data channels. = Unfortunately the draft doesn=E2=80=99t give any reasoning for that = choice but I would still think that use of particle messages in taps = should be equivalent at it is explicitly designed to address = applications that actually need streaming. What do people think? >=20 > I think the notion of stream here is just a multiplexing concept; the = terminology doesn't follow the terminology in TAPS, but it's not at = odds. It's just a different phrasing. I largely agree. The thing they call a Stream would be represented by a = TAPS connection backed by a stream of a QUIC connection. A TAPS system = should also be able to provide functionally equivalent alternative = transport, e.g, falling back to TCP connections or assigning the stream = to a a specific connection from a pool of established QUIC connections. >>=20 >> Further looking at = https://tools.ietf.org/html/draft-vvv-webtransport-quic-00 = this draft = defines a new ALPN value and a QUIC extension. I guess in taps we have = not explicitly considered ALPN so far but we really would need to do = that in any case! I guess one could see this as a protocol specific = property but maybe it=E2=80=99s even worth to be more explicit here. Did = anybody consider ALPN already? >=20 > ALPN is a TLS option, so it fits into the protocol-specific options. = We certainly have support for that in our implementation! = (https://developer.apple.com/documentation/security/2976269-sec_protocol_o= ptions_add_tls_app?language=3Dobjc = ) in the long run, making the ALPN a TLS option may be a little short = sighted. We should consider to making it an optional part of the remote endpoint = (remote.with_alp(=E2=80=9Chttp=E2=80=9D), as a future QUIC version that = may not be based on TLS would certainly also support this concept. I can = also imagine Applications only specifying a ALPN and a host name while = the transport systems fills in port candidates or use appropriate proxy = chains. This can also be used to address services in Kybernetis like cloud = infrastructures. >> Regarding the new QUIC transport parameter I have to say that the = purpose it not fully clear to me from the draft. However it seems that = this is supposed to support some kind of access control that is = performed on the application layer but by a more trusted entity than the = client application itself. It is not fully clear to me what the trust = assumptions are, however it does seems that is should not be a transport = parameter that is protocol specific but rather some function on the = higher layer. However, to be able to make a proposal here, I would = probably need to understand the purpose better. Do people have any = insights? >=20 > =46rom the TAPS side, transport parameters in QUIC do need to be able = to be configured by the app or set as a default for a given use case, so = that shouldn't be an issue. Full ACK =E2=80=93 But I would discourage using it as it makes protocol = evolution harder. >=20 >>=20 >> Do people have thoughts? What is missing in taps to also cover the = full web use case? Is that something we want to account for in taps? Or = what is the difference that would not fit with the taps approach? What = am I missing? >=20 > Fundamentally, TAPS is about API shape and approach. It alone doesn't = define any new protocol knobs. If WebTransport needs new on-the-wire = protocol changes, those need to be independent. However, the shape of = creating connections, and sending and receiving messages, is something = that can certainly conform to a TAPS-compliant interface. >=20 > If you read through draft-vvv-webtransport-overview, it largely = outlines something that is a TAPS interface, just without referencing = TAPS or calling that out. >=20 > So, one way to view the relationship is that WebTransport as described = is a specific set of protocol features that a web-focused implementation = of a TAPS system ought to build, plus a few protocol tweaks below. Agreed. AVE! Philipp S. Tiesel -- =20 Philipp S. Tiesel https://philipp.tiesel.net/ --Apple-Mail=_A4BD20FD-3019-4AC6-B397-D18B776B0FFF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

On 14. Nov 2019, at 23:16, Tommy Pauly = <tpauly=3D40apple.com@dmarc.ietf.org> wrote:
On = Nov 14, 2019, at 10:18 AM, Mirja Kuehlewind <ietf@kuehlewind.net>= wrote:

Hi taps folks (also cc=E2=80=99ing = the WebTransport list),

I assume that = people on the taps list are aware of the WebTransport effort that will = have a BoF meeting on 13:30-15:00 Wednesday. I had another look at the = WebTransport documents today in order to better understand the scope of = WebTransport compared to taps. 

Looking at https://tools.ietf.org/html/draft-vvv-webtransport-overview-00<= /a> I believe that this should be covered by pooled connections in taps = + use of partial messages. WebTransport proposes to use streams as the = base concept while we in taps explicitly decided against this but to use = messages instead which also aligns with other protocols that are = discussed in WebTransports like Websockets and WebRTC data channels. = Unfortunately the draft doesn=E2=80=99t give any reasoning for that = choice but I would still think that use of particle messages in taps = should be equivalent at it is explicitly designed to address = applications that actually need streaming. What do people think?

I think the notion of stream here is just a multiplexing = concept; the terminology doesn't follow the terminology in TAPS, but = it's not at odds. It's just a different phrasing.



Further looking at https://tools.ietf.org/html/draft-vvv-webtransport-quic-00<= span class=3D"Apple-converted-space"> this draft defines a = new ALPN value and a QUIC extension. I guess in taps we have not = explicitly considered ALPN so far but we really would need to do that in = any case! I guess one could see this as a protocol specific property but = maybe it=E2=80=99s even worth to be more explicit here. Did anybody = consider ALPN already?

ALPN is a TLS option, so it fits = into the protocol-specific options. We certainly have support for that = in our implementation! (https://developer.apple.com/documentation/security/2976269-sec_= protocol_options_add_tls_app?language=3Dobjc)

in the long run, making the ALPN a TLS option may = be a little short sighted.
We should consider to making it an = optional part of the remote endpoint (remote.with_alp(=E2=80=9Chttp=E2=80=9D= ), as a future QUIC version that may not be based on TLS would certainly = also support this concept. I can also imagine Applications only = specifying a ALPN and a host name while the transport systems fills in = port candidates or use appropriate proxy chains.
This can also = be used to address services in Kybernetis like cloud = infrastructures.

Regarding the new QUIC transport parameter I have to say that = the purpose it not fully clear to me from the draft. However it seems = that this is supposed to support some kind of access control that is = performed on the application layer but by a more trusted entity than the = client application itself. It is not fully clear to me what the trust = assumptions are, however it does seems that is should not be a transport = parameter that is protocol specific but rather some function on the = higher layer. However, to be able to make a proposal here, I would = probably need to understand the purpose better. Do people have any = insights?

=46rom the TAPS side, transport parameters in QUIC do need to = be able to be configured by the app or set as a default for a given use = case, so that shouldn't be an issue.

Full ACK =E2=80=93 But I would discourage using it as = it makes protocol evolution harder.


Do people have = thoughts? What is missing in taps to also cover the full web use case? = Is that something we want to account for in taps? Or what is the = difference that would not fit with the taps approach? What am I = missing?

Fundamentally, TAPS is about API shape and approach. It alone = doesn't define any new protocol knobs. If WebTransport needs new = on-the-wire protocol changes, those need to be independent. However, the = shape of creating connections, and sending and receiving messages, is = something that can certainly conform to a TAPS-compliant = interface.

If you read = through draft-vvv-webtransport-overview, it largely outlines something = that is a TAPS interface, just without referencing TAPS or calling that = out.

So, one way = to view the relationship is that WebTransport as described is a specific = set of protocol features that a web-focused implementation of a TAPS = system ought to build, plus a few protocol tweaks below.

Agreed.

AVE!
   Philipp S. = Tiesel

--  
Philipp S. Tiesel
https://philipp.tiesel.net/

= --Apple-Mail=_A4BD20FD-3019-4AC6-B397-D18B776B0FFF-- From nobody Fri Nov 15 23:11:23 2019 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 2E5FB1200E5 for ; Fri, 15 Nov 2019 23:11:21 -0800 (PST) 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, SPF_HELO_NONE=0.001, 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 FYz8ct3dA7L3 for ; Fri, 15 Nov 2019 23:11:19 -0800 (PST) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 DAE6712008D for ; Fri, 15 Nov 2019 23:11:18 -0800 (PST) Received: by mail-pj1-x102f.google.com with SMTP id a10so251535pju.10 for ; Fri, 15 Nov 2019 23:11:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=l1oaXHHX3+bS7wsI+CQxjTtBCqUHJRjGQ67EgcH0N3U=; b=sNaKTVufIs+mCWoFEJUyFq21Lnxn98JJt985E35AWYiZR6g7ieaqGpUl+hYukbCUbW A1ocY3oVdQ5ugR98kf7iOKTMKeeZ3XMqQ4JmRtQ+p20o8jtYFfslGmlf34rShkKWSayo yNdeq9VY3Gxf6iZA9VOniUC99cWeb/Q8M7WD2oOe/u/qW42A6inTzHe2YVSeqpv+Un3Q hDSGQgrN1MN6V5dOO1S6HgaboMvFzKvr/5eAA/GWVgXmC2Cvnp/F4FOMuOGK/vzwM4tU 0IbRrMbRtwT8Vk9ke5A6zOfeJwuAn4JrC+zNk1/6pNM/xVOn4gL/eOrX6j8wHDTWIQeY uSjA== 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 :content-transfer-encoding; bh=l1oaXHHX3+bS7wsI+CQxjTtBCqUHJRjGQ67EgcH0N3U=; b=SPiIdk99Erohv/O2QY4r/Ff/PcnOiLCWRYLKDN+Q2+J2Wb0StKc3Ab66ROEG4gDwKq pA6ZqwR+/+nHC4URJMLh3C2wZ3GIuylKjpIkl7A/z+tylM167Yx01kC7gdggtX0OQXqS /BxHNLiksXcK1ao5rYEQjMt7H15rbSEU2y+hk8zNedKJ6DUXd8NxNVhZsU31O0oX3fYA pI41nxXpovAYAx1IzRFIdyk1yaWe42xGwR/7Nd6itvCgZLWU+FHPtB2EaVP2Xa8d2bMo N3hID9t09a2qHqdHl4tLljn09+Ctvb2QCe/25FZ1Y9umOtY3F34ykB58yEHLcBdjCspw YXqg== X-Gm-Message-State: APjAAAUypLOXVFmpZu6k6hAie4nKGsy2LsEWmgLJDUzxXt9dqxjwKKHX Auy+nLmfLHnNgFrpq1xEpymM/sQ9ko0= X-Google-Smtp-Source: APXvYqxaej0f59JnYOYN0MLIHqJkiCe4NRs2FPIxs5Sit5g+I7Lx43g7X1WFqAExdcEdEC4JUZjD3Q== X-Received: by 2002:a17:90a:1a56:: with SMTP id 22mr25623628pjl.100.1573888277843; Fri, 15 Nov 2019 23:11:17 -0800 (PST) Received: from [172.19.217.107] ([2001:67c:1232:144:180b:da27:6960:3f6f]) by smtp.gmail.com with ESMTPSA id j20sm12409770pff.182.2019.11.15.23.11.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Nov 2019 23:11:17 -0800 (PST) From: "Aaron Falk" To: "taps WG" Date: Sat, 16 Nov 2019 15:11:15 +0800 X-Mailer: MailMate (1.13r5655) Message-ID: <33DEC7AC-738B-436B-A42E-FC1500033283@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_B8AE35AC-C4E8-4E4F-AE50-758AC0CD125B_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: [Taps] finishing things 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, 16 Nov 2019 07:11:21 -0000 --=_MailMate_B8AE35AC-C4E8-4E4F-AE50-758AC0CD125B_= Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Hey Working Group, Before we meet on Tuesday I wanted to put an idea on the table that I think will shape our wg discussion. What do you think of setting a goal of WGLC for our three in-progress docs before the March IETF? This would require increasing wg activity, for example, having monthly calls to consider and resolve open issues. I think we’re reaching a point where wg engagement is starting to drop and I’m concerned if we delay closing out the docs there will be few people engaged to do a serious review of the results. A lot of work has gone into TAPS and I think we should aspire to finish strong. Comments? I’m especially interested to hear what the doc editors think. --aaron --=_MailMate_B8AE35AC-C4E8-4E4F-AE50-758AC0CD125B_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Hey Working Group,

Before we meet on Tuesday I wanted to put an idea on the = table that I think will shape our wg discussion. What do you think of se= tting a goal of WGLC for our three in-progress docs before the March IETF= ? This would require increasing wg activity, for example, having monthly= calls to consider and resolve open issues. I think we=E2=80=99re reachi= ng a point where wg engagement is starting to drop and I=E2=80=99m concer= ned if we delay closing out the docs there will be few people engaged to = do a serious review of the results. A lot of work has gone into TAPS and= I think we should aspire to finish strong. Comments? I=E2=80=99m espec= ially interested to hear what the doc editors think.

--aaron

--=_MailMate_B8AE35AC-C4E8-4E4F-AE50-758AC0CD125B_=-- From nobody Fri Nov 15 23:14:11 2019 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 7D7261200E5 for ; Fri, 15 Nov 2019 23:14:09 -0800 (PST) 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_HELO_NONE=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 WTpzCpDLd9LZ for ; Fri, 15 Nov 2019 23:14:06 -0800 (PST) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E0EC12007A for ; Fri, 15 Nov 2019 23:14:06 -0800 (PST) Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iVsHU-0006Ek-41; Sat, 16 Nov 2019 08:14:04 +0100 Received: from [103.24.106.34] (helo=[192.167.2.118]) by mail-mx11.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92.3) (envelope-from ) id 1iVsHT-0002cP-5k; Sat, 16 Nov 2019 08:14:04 +0100 From: Michael Welzl Message-Id: <22F60336-87F7-499E-A8AF-5646CF4D9FD7@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_1433E19F-A6A0-4B19-BB6F-69886E248FE4" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sat, 16 Nov 2019 15:13:57 +0800 In-Reply-To: <33DEC7AC-738B-436B-A42E-FC1500033283@gmail.com> Cc: "taps@ietf.org" To: Aaron Falk References: <33DEC7AC-738B-436B-A42E-FC1500033283@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 103.24.106.34 is neither permitted nor denied by domain of ifi.uio.no) client-ip=103.24.106.34; envelope-from=michawe@ifi.uio.no; helo=[192.167.2.118]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 321929D4B4144B22E0639DB35E05A3143A38BE0A Archived-At: Subject: Re: [Taps] finishing things 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, 16 Nov 2019 07:14:09 -0000 --Apple-Mail=_1433E19F-A6A0-4B19-BB6F-69886E248FE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think this is a great idea. Cheers, Michael > On Nov 16, 2019, at 3:11 PM, Aaron Falk wrote: >=20 > Hey Working Group, >=20 > Before we meet on Tuesday I wanted to put an idea on the table that I = think will shape our wg discussion. What do you think of setting a goal = of WGLC for our three in-progress docs before the March IETF? This would = require increasing wg activity, for example, having monthly calls to = consider and resolve open issues. I think we=E2=80=99re reaching a point = where wg engagement is starting to drop and I=E2=80=99m concerned if we = delay closing out the docs there will be few people engaged to do a = serious review of the results. A lot of work has gone into TAPS and I = think we should aspire to finish strong. Comments? I=E2=80=99m = especially interested to hear what the doc editors think. >=20 > --aaron >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_1433E19F-A6A0-4B19-BB6F-69886E248FE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = think this is a great idea.

Cheers,
Michael


On Nov 16, 2019, at 3:11 PM, = Aaron Falk <aaron.falk@gmail.com> wrote:

Hey = Working Group,

Before we meet on Tuesday I = wanted to put an idea on the table that I think will shape our wg = discussion. What do you think of setting a goal of WGLC for our three = in-progress docs before the March IETF? This would require increasing = wg activity, for example, having monthly calls to consider and resolve = open issues. I think we=E2=80=99re reaching a point where wg engagement = is starting to drop and I=E2=80=99m concerned if we delay closing out = the docs there will be few people engaged to do a serious review of the = results. A lot of work has gone into TAPS and I think we should aspire = to finish strong. Comments? I=E2=80=99m especially interested to hear = what the doc editors think.

--aaron

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

= --Apple-Mail=_1433E19F-A6A0-4B19-BB6F-69886E248FE4-- From nobody Sat Nov 16 06:37:48 2019 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 E9359120131 for ; Sat, 16 Nov 2019 06:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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 sdJTLkc0FJx8 for ; Sat, 16 Nov 2019 06:37:43 -0800 (PST) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 37F8912012D for ; Sat, 16 Nov 2019 06:37:43 -0800 (PST) Received: from smtp-2-0001.mail.infomaniak.ch (smtp-2-0001.mail.infomaniak.ch [10.5.36.108]) by smtp-sh2.infomaniak.ch (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id xAGEbdVf243738 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 16 Nov 2019 15:37:39 +0100 Received: from [10.128.30.18] (unknown [61.8.238.244]) by smtp-2-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 76B411008755A; Sat, 16 Nov 2019 15:37:37 +0100 (CET) Content-Type: multipart/alternative; boundary=Apple-Mail-453E74DF-A14A-4B9F-BC38-159A7D9C14E2 Mime-Version: 1.0 (1.0) From: "Brian Trammell (IETF)" X-Mailer: iPhone Mail (16G102) In-Reply-To: <22F60336-87F7-499E-A8AF-5646CF4D9FD7@ifi.uio.no> Date: Sat, 16 Nov 2019 22:37:35 +0800 Cc: Aaron Falk , "taps@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <33DEC7AC-738B-436B-A42E-FC1500033283@gmail.com> <22F60336-87F7-499E-A8AF-5646CF4D9FD7@ifi.uio.no> To: Michael Welzl X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Taps] finishing things 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, 16 Nov 2019 14:37:47 -0000 --Apple-Mail-453E74DF-A14A-4B9F-BC38-159A7D9C14E2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1; we should allocate time on our agenda here to actually set the schedule f= or these interims, to avoid the =E2=80=9Dlet=E2=80=99s think about that late= r=E2=80=9D problem. Sent from my iPhone > On 16 Nov 2019, at 15:13, Michael Welzl wrote: >=20 > I think this is a great idea. >=20 > Cheers, > Michael >=20 >=20 >> On Nov 16, 2019, at 3:11 PM, Aaron Falk wrote: >>=20 >> Hey Working Group, >>=20 >> Before we meet on Tuesday I wanted to put an idea on the table that I thi= nk will shape our wg discussion. What do you think of setting a goal of WGLC= for our three in-progress docs before the March IETF? This would require in= creasing wg activity, for example, having monthly calls to consider and reso= lve open issues. I think we=E2=80=99re reaching a point where wg engagement i= s starting to drop and I=E2=80=99m concerned if we delay closing out the doc= s there will be few people engaged to do a serious review of the results. A l= ot of work has gone into TAPS and I think we should aspire to finish strong.= Comments? I=E2=80=99m especially interested to hear what the doc editors th= ink. >>=20 >> --aaron >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail-453E74DF-A14A-4B9F-BC38-159A7D9C14E2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1; we should allocate time on our agenda h= ere to actually set the schedule for these interims, to avoid the =E2=80=9Dl= et=E2=80=99s think about that later=E2=80=9D problem.

Sent from my iPhone

On= 16 Nov 2019, at 15:13, Michael Welzl <michawe@ifi.uio.no> wrote:

I think this is a great idea.

<= /div>
Cheers,
Michael


On Nov 16, 2019, at 3:11 PM, Aaron Falk= <aaron.falk@gmail.com= > wrote:

Hey Working Group,

Before we meet on Tuesday I wanted to put an idea on the t= able that I think will shape our wg discussion. What do you think of settin= g a goal of WGLC for our three in-progress docs before the March IETF? This= would require increasing wg activity, for example, having monthly calls to c= onsider and resolve open issues. I think we=E2=80=99re reaching a point whe= re wg engagement is starting to drop and I=E2=80=99m concerned if we delay c= losing out the docs there will be few people engaged to do a serious review o= f the results. A lot of work has gone into TAPS and I think we should aspir= e to finish strong. Comments? I=E2=80=99m especially interested to hear wh= at the doc editors think.

--aaron

_______________________________________________
Taps mailing l= ist
Taps@ietf.org<= /a>
htt= ps://www.ietf.org/mailman/listinfo/taps

_______________________________________________Taps mailing list
T= aps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
<= /blockquote>= --Apple-Mail-453E74DF-A14A-4B9F-BC38-159A7D9C14E2-- From nobody Sat Nov 16 16:26:39 2019 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 1496C12006E for ; Sat, 16 Nov 2019 16:26:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 UZZKIzFtiGCl for ; Sat, 16 Nov 2019 16:26:34 -0800 (PST) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:638:809:ff11:130:149:220:242]) by ietfa.amsl.com (Postfix) with ESMTP id 61F5D120043 for ; Sat, 16 Nov 2019 16:26:34 -0800 (PST) Received: from [IPv6:2001:67c:370:128:8886:4e4d:3337:db26] (unknown [IPv6:2001:67c:370:128:8886:4e4d:3337:db26]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id 41F1929A for ; Sun, 17 Nov 2019 01:26:32 +0100 (CET) To: taps@ietf.org References: <33DEC7AC-738B-436B-A42E-FC1500033283@gmail.com> <22F60336-87F7-499E-A8AF-5646CF4D9FD7@ifi.uio.no> From: Theresa Enghardt Openpgp: preference=signencrypt Autocrypt: addr=theresa@inet.tu-berlin.de; prefer-encrypt=mutual; keydata= mQENBE2ktqYBCAC+3mnQMUTPJEPjKD0EaURx171qWkp4M60Zk97aeG6hSDU2GJAKG/IZ9/w7 NXLZxlfmfK9+y4Fia3aHfdhtdh+hZ/nkzhNHEahpt+coChrcaM/xyLmw7QOfYw6pLEe/snPY bdeiNdg3dsM8SFbLPvzs0REiAS9aVsux7fyDFmmJ4BGqJtjSzAv+l3X508wGeKgbUxT1Ceb5 /6DT5U1cPeSSCsXghHi5pcIfwW0KU00Ug56k3gSIRZ3YlahtBXVyIGOfPMLcvxpVypNejCt3 haLfbK6zI1GFHW39ietsk12DEODM0GiOhlCEx0qL+JxmR+A/IHKkINe5aj8Tl/Ie9TfZABEB AAG0N1RoZXJlc2EgRW5naGFyZHQgKFJlc2VhcmNoKSA8dGhlcmVzYUBpbmV0LnR1LWJlcmxp bi5kZT6JAVUEEwEKAD8CGyMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAFiEE7xG3phZ0Plgk 2BDpgz007xx2oPcFAlqgJ40FCRC919sACgkQgz007xx2oPfiHggAsCfbxjo+hlUYdEHmg/a8 RGDZfOqgmNrEWfWbB+H06A3izNpvfRbqdxhi64F8MXtKPxhPGBrB9H3/E3WfsOHc9tJe+19Y GkHBOMhbXmp/o92BVHw6q/l5bcvLO8sgcemqrh8GYZgZrho7F3UTIpb8dkCjt+jCAbsAAFzR 4ziEAqw+2KVmZw5t2/1KygnPsgMz70JGAfq2jTt+NR9DxMizXNa7pZjdSmqhBjCbTlzPnn0C rAkK1/IXSM3Y704asyQrHD2pNxXQyXEe/K5uN6w80gHdyK4bBWVIVZULaRngcKrcX9gillK+ 8zs3nr8eDgsq1cURk8nmkIkFm++6PgO8lLkBDQRNpLamAQgAz5qAZBAFqJoFLTYeKHqy149J BtI8Oh4Ywktc1ExLuZDP7KPjLKGJv5ebMHblU579BiSMgj35Bw4H7V5zzgB2DzklLG61ZAjN d6uFEdFNLtf+2/QqjVqqZjlXfCIlNeq+2U002q1SPzLniX9xm4uHUfL3dZqgOkAWa4fB/X1W mMcXMQX+Npwv9plEJOLdd1J6/XtwsUmnJnkicDiuyb7G8v4fPDJtc0m2sQIdXSL71VIHbme5 w8p8OYN41q0vqefBaMp0PnppG/K32Xa9/zW5fTKMcXxcCFZH7Ww2tpnFqZe0zhrL9UjAfQsg Xurujk0OvEFhhkQonVRXUYmLTM0EXQARAQABiQE8BBgBCgAmAhsMFiEE7xG3phZ0Plgk2BDp gz007xx2oPcFAlqgJ40FCRC91+cACgkQgz007xx2oPfRiwf9H9BNITXs2wLFjrej7wV8XoCO 5z3iN4TTeKz/2XA0CQr7OjkqbEkllnlGvywJOsCsrficHGL+eXk7tWXf8LMm0QOA1pEgA7oN ynGp7O65WG4kN93j9PFA/0k+nkqWtztuw3KBApSqytEBaaqwdeOG5mCWYawAjpSII2Bo+r9I ghH9miMgAsT044OPj3QMKSZAzTEzHekEuYa/AZqfFxLFE27WdDZpEqzvQ3uaIDbYx5HbT+xt LJJczpENdiTwyvHN4PwNSfWacyv1TA7WM2Qusgs5OVRwaJIQypvoGRl0YawaHHgxpLgs/x3r 2IqmnTXThea+Wx/iYSrPFFv4rEbS/w== Message-ID: Date: Sun, 17 Nov 2019 08:26:30 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5D6A6881941CCD59BE82B545" Content-Language: en-US Archived-At: Subject: Re: [Taps] finishing things 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: Sun, 17 Nov 2019 00:26:38 -0000 This is a multi-part message in MIME format. --------------5D6A6881941CCD59BE82B545 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Agree to both aim for WGLC before March and scheduling more interims. Speaking for myself, I'm pretty confident I'll have more time for TAPS in the coming months than I had in the previous months. Best, Theresa On 16.11.19 22:37, Brian Trammell (IETF) wrote: > +1; we should allocate time on our agenda here to actually set the > schedule for these interims, to avoid the ”let’s think about that > later” problem. > > Sent from my iPhone > > On 16 Nov 2019, at 15:13, Michael Welzl > wrote: > >> I think this is a great idea. >> >> Cheers, >> Michael >> >> >>> On Nov 16, 2019, at 3:11 PM, Aaron Falk >> > wrote: >>> >>> Hey Working Group, >>> >>> Before we meet on Tuesday I wanted to put an idea on the table that >>> I think will shape our wg discussion. What do you think of setting a >>> goal of WGLC for our three in-progress docs before the March IETF? >>> This would require increasing wg activity, for example, having >>> monthly calls to consider and resolve open issues. I think we’re >>> reaching a point where wg engagement is starting to drop and I’m >>> concerned if we delay closing out the docs there will be few people >>> engaged to do a serious review of the results. A lot of work has >>> gone into TAPS and I think we should aspire to finish strong. >>> Comments? I’m especially interested to hear what the doc editors think. >>> >>> --aaron >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --------------5D6A6881941CCD59BE82B545 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Agree to both aim for WGLC before March and scheduling more interims.

Speaking for myself, I'm pretty confident I'll have more time for TAPS in the coming months than I had in the previous months.

Best,
Theresa


On 16.11.19 22:37, Brian Trammell (IETF) wrote:
+1; we should allocate time on our agenda here to actually set the schedule for these interims, to avoid the ”let’s think about that later” problem.

Sent from my iPhone

On 16 Nov 2019, at 15:13, Michael Welzl <michawe@ifi.uio.no> wrote:

I think this is a great idea.

Cheers,
Michael


On Nov 16, 2019, at 3:11 PM, Aaron Falk <aaron.falk@gmail.com> wrote:

Hey Working Group,

Before we meet on Tuesday I wanted to put an idea on the table that I think will shape our wg discussion. What do you think of setting a goal of WGLC for our three in-progress docs before the March IETF? This would require increasing wg activity, for example, having monthly calls to consider and resolve open issues. I think we’re reaching a point where wg engagement is starting to drop and I’m concerned if we delay closing out the docs there will be few people engaged to do a serious review of the results. A lot of work has gone into TAPS and I think we should aspire to finish strong. Comments? I’m especially interested to hear what the doc editors think.

--aaron

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

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

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
--------------5D6A6881941CCD59BE82B545-- From nobody Sat Nov 16 18:39:14 2019 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 D6A16120823 for ; Sat, 16 Nov 2019 18:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 zoLk5e6plWsh for ; Sat, 16 Nov 2019 18:39:10 -0800 (PST) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 7FE8412081D for ; Sat, 16 Nov 2019 18:39:10 -0800 (PST) Received: by mail-pl1-x62d.google.com with SMTP id bb5so7479704plb.4 for ; Sat, 16 Nov 2019 18:39:10 -0800 (PST) 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=lUXyDFCvn8/mVd79KQCxZovgybmlNinKqtQrIgATWjE=; b=FTHG/uWx2FlmmfHG7u2YFiTz2/EfJfZgn5/U3+4/qoUloiTc0/KbYN8meU+tHEFW8Y jNaWJBy1SWFgED40Brm15QHNwxfBx4Iidyo9d7hSV5oO5dYezY8ngbr7NJNaU2ngd1EU nLslLa1+MTO0rilPylZPygEQUoWDmGewL8KqDUHf+RJ5PySgEfiymZ1InNoQ+0hmG7nn XwnqsDr0J2cYbOu9DQiI+F8qQZG9N8vx34q1WioPaT0moZIceV4Qk6mYv5opSv+rBQwd a0A2CShfRPX0pA81kMqagaSlWLHljWNDKqq/5HizrBqwaev7lt5dmlMdUCTDrkbL70SC Jd9A== 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=lUXyDFCvn8/mVd79KQCxZovgybmlNinKqtQrIgATWjE=; b=oGIcCqocd1p2beQpzP/H9rWFnQOq6QXW7t5tgUcdIHFgLrOmUz5zs2KfG3zTOIKqry QdPnJScXr9DihbARuFRcXCPFhlbWhjkloEgLSSCACb2Z4me0ooILCOV+gg7edwIYzoDQ Jn2cHkfEl9JeDmUHmq/dSkUQMBPX6xm32Wv0c1TcVZnQ99AeYnrESwNDAyq5ErwMrqQH 19Ch26OCuLK491fokz8zJ2w9PbvasQ8/HT5y3QG19cDdCPqe5E3RW5cCE7DS7NA7DK7U jbEYKUxuFgla7mtK2i7TV6/vel9Y/AzUcd/kZrGNnLKTjpP6HvOwZROA2MLLhwLwy9PT jxkg== X-Gm-Message-State: APjAAAUTePN8qNCn4rIqsALLpWzaqxFaBPZ1N/X13QI4LXN3XiucRS4A AV+WrP+yWQpzcZgmSyZgpgI= X-Google-Smtp-Source: APXvYqwkV8+3awKpTmwtiYjMsmTlWY7mcey23Yh7ZNkJMYDGl4Wel/K0u2ZvF1EROZGg4XeHpkXsiA== X-Received: by 2002:a17:90a:4d8f:: with SMTP id m15mr20866545pjh.71.1573958349824; Sat, 16 Nov 2019 18:39:09 -0800 (PST) Received: from [31.133.130.252] ([2001:67c:370:128:b958:9514:f0ec:edae]) by smtp.gmail.com with ESMTPSA id o125sm15275059pfg.118.2019.11.16.18.39.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 16 Nov 2019 18:39:09 -0800 (PST) From: "Aaron Falk" To: "Brian Trammell" Cc: "Michael Welzl" , taps@ietf.org Date: Sun, 17 Nov 2019 10:39:07 +0800 X-Mailer: MailMate (1.13r5655) Message-ID: <24E6F5C5-ABF2-40F6-A6CB-A33EB4D4A42C@gmail.com> In-Reply-To: References: <33DEC7AC-738B-436B-A42E-FC1500033283@gmail.com> <22F60336-87F7-499E-A8AF-5646CF4D9FD7@ifi.uio.no> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_41DF6C6C-7274-4D83-B491-8A5B89E33EF1_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[610, 2624], "plain":[296, 1395], "uuid":"3909D60D-730D-4C93-B499-308F61D1941A"}] Archived-At: Subject: Re: [Taps] finishing things 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: Sun, 17 Nov 2019 02:39:13 -0000 --=_MailMate_41DF6C6C-7274-4D83-B491-8A5B89E33EF1_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Excellent point. Suppose at a minimum we assign an owner to each issue to propose and socialize a resolution? If it’s already known or obvious, can the folks preparing for Tuesday’s meeting put names of nominal owners by issues? On 16 Nov 2019, at 22:37, Brian Trammell (IETF) wrote: > +1; we should allocate time on our agenda here to actually set the > schedule for these interims, to avoid the ”let’s think about that > later” problem. > > Sent from my iPhone > >> On 16 Nov 2019, at 15:13, Michael Welzl wrote: >> >> I think this is a great idea. >> >> Cheers, >> Michael >> >> >>> On Nov 16, 2019, at 3:11 PM, Aaron Falk >>> wrote: >>> >>> Hey Working Group, >>> >>> Before we meet on Tuesday I wanted to put an idea on the table that >>> I think will shape our wg discussion. What do you think of setting a >>> goal of WGLC for our three in-progress docs before the March IETF? >>> This would require increasing wg activity, for example, having >>> monthly calls to consider and resolve open issues. I think we’re >>> reaching a point where wg engagement is starting to drop and I’m >>> concerned if we delay closing out the docs there will be few people >>> engaged to do a serious review of the results. A lot of work has >>> gone into TAPS and I think we should aspire to finish strong. >>> Comments? I’m especially interested to hear what the doc editors >>> think. >>> >>> --aaron >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps --=_MailMate_41DF6C6C-7274-4D83-B491-8A5B89E33EF1_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Excellent point. Suppose at a minimum we assign an owner = to each issue to propose and socialize a resolution? If it=E2=80=99s alr= eady known or obvious, can the folks preparing for Tuesday=E2=80=99s meet= ing put names of nominal owners by issues?

On 16 Nov 2019, at 22:37, Brian Trammell (IETF) wrote:

+1; we should allocate time on our agenda here to actuall= y set the schedule for these interims, to avoid the =E2=80=9Dlet=E2=80=99= s think about that later=E2=80=9D problem.

Sent from my iPhone

On 16 N= ov 2019, at 15:13, Michael Welzl <michawe@ifi.uio.no> wrote:

I think this is a great idea.

Cheers,
Michael


On Nov 16, 2019, at 3:1= 1 PM, Aaron Falk <a= aron.falk@gmail.com> wrote:

Hey Working Group,

Before we meet on Tuesday I wanted to put an idea= on the table that I think will shape our wg discussion. What do you thi= nk of setting a goal of WGLC for our three in-progress docs before the Ma= rch IETF? This would require increasing wg activity, for example, having= monthly calls to consider and resolve open issues. I think we=E2=80=99r= e reaching a point where wg engagement is starting to drop and I=E2=80=99= m concerned if we delay closing out the docs there will be few people eng= aged to do a serious review of the results. A lot of work has gone into = TAPS and I think we should aspire to finish strong. Comments? I=E2=80=99= m especially interested to hear what the doc editors think.

--aaron

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

______________________________________= _________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo= /taps
--=_MailMate_41DF6C6C-7274-4D83-B491-8A5B89E33EF1_=-- From nobody Sat Nov 16 19:40:03 2019 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 A1C95120837 for ; Sat, 16 Nov 2019 19:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 df2RoAkwguMi for ; Sat, 16 Nov 2019 19:39:59 -0800 (PST) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC219120838 for ; Sat, 16 Nov 2019 19:39:58 -0800 (PST) Received: from mail-mx03.uio.no ([129.240.10.15]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iWBPn-0006HJ-4O; Sun, 17 Nov 2019 04:39:55 +0100 Received: from [103.24.106.34] (helo=[192.167.2.106]) by mail-mx03.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92.3) (envelope-from ) id 1iWBPk-000Fpi-Li; Sun, 17 Nov 2019 04:39:55 +0100 Content-Type: multipart/alternative; boundary=Apple-Mail-C4F73ACE-7ED7-49DE-8908-159BAE3F2D53 Content-Transfer-Encoding: 7bit From: Michael Welzl Mime-Version: 1.0 (1.0) Date: Sun, 17 Nov 2019 11:39:48 +0800 Message-Id: <7655533F-77AD-4DEF-AA5A-3FA3367D2C64@ifi.uio.no> References: <24E6F5C5-ABF2-40F6-A6CB-A33EB4D4A42C@gmail.com> Cc: Brian Trammell , taps@ietf.org In-Reply-To: <24E6F5C5-ABF2-40F6-A6CB-A33EB4D4A42C@gmail.com> To: Aaron Falk X-Mailer: iPhone Mail (17A878) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx03.uio.no: 103.24.106.34 is neither permitted nor denied by domain of ifi.uio.no) client-ip=103.24.106.34; envelope-from=michawe@ifi.uio.no; helo=[192.167.2.106]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=-0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 86C4F1DDEE33B5E2508DA2A97E28235E593A596E Archived-At: Subject: Re: [Taps] finishing things 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: Sun, 17 Nov 2019 03:40:01 -0000 --Apple-Mail-C4F73ACE-7ED7-49DE-8908-159BAE3F2D53 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable but many issues already have people assigned in github.... just a matter o= f making sure all are assigned to someone? that should be easy Sent from my iPhone > On 17 Nov 2019, at 10:39, Aaron Falk wrote: >=20 > =EF=BB=BF > Excellent point. Suppose at a minimum we assign an owner to each issue to p= ropose and socialize a resolution? If it=E2=80=99s already known or obvious,= can the folks preparing for Tuesday=E2=80=99s meeting put names of nominal o= wners by issues? >=20 > On 16 Nov 2019, at 22:37, Brian Trammell (IETF) wrote: >=20 > +1; we should allocate time on our agenda here to actually set the schedul= e for these interims, to avoid the =E2=80=9Dlet=E2=80=99s think about that l= ater=E2=80=9D problem. >=20 > Sent from my iPhone >=20 >> On 16 Nov 2019, at 15:13, Michael Welzl wrote: >>=20 >> I think this is a great idea. >>=20 >> Cheers, >> Michael >>=20 >>=20 >>> On Nov 16, 2019, at 3:11 PM, Aaron Falk wrote: >>>=20 >>> Hey Working Group, >>>=20 >>> Before we meet on Tuesday I wanted to put an idea on the table that I th= ink will shape our wg discussion. What do you think of setting a goal of WGL= C for our three in-progress docs before the March IETF? This would require i= ncreasing wg activity, for example, having monthly calls to consider and res= olve open issues. I think we=E2=80=99re reaching a point where wg engagement= is starting to drop and I=E2=80=99m concerned if we delay closing out the d= ocs there will be few people engaged to do a serious review of the results. A= lot of work has gone into TAPS and I think we should aspire to finish stron= g. Comments? I=E2=80=99m especially interested to hear what the doc editors t= hink. >>>=20 >>> --aaron >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 --Apple-Mail-C4F73ACE-7ED7-49DE-8908-159BAE3F2D53 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable but many issues already have people assigne= d in github....   just a matter of making sure all are assigned to some= one?  that should be easy


Sent from my iPh= one

On 17 Nov 2019, at 1= 0:39, Aaron Falk <aaron.falk@gmail.com> wrote:

=EF=BB=BF

Excellent point. Suppose at a minimum we assign an owner to eac= h issue to propose and socialize a resolution? If it=E2=80=99s already know= n or obvious, can the folks preparing for Tuesday=E2=80=99s meeting put name= s of nominal owners by issues?

On 16 Nov 2019, at 22:37, Brian Trammell (IETF) wrote:

+1; we should allocate time on our agenda here to actually set the= schedule for these interims, to avoid the =E2=80=9Dlet=E2=80=99s think abou= t that later=E2=80=9D problem.

Sent from my iPhone

On 16 Nov 2019, at 15:13,= Michael Welzl <michawe@ifi.uio.no<= /a>> wrote:

I think t= his is a great idea.

Che= ers,
Michael

=

Hey Working Group,

Before we meet on Tuesday I wanted to put an idea on the t= able that I think will shape our wg discussion. What do you think of settin= g a goal of WGLC for our three in-progress docs before the March IETF? This= would require increasing wg activity, for example, having monthly calls to c= onsider and resolve open issues. I think we=E2=80=99re reaching a point whe= re wg engagement is starting to drop and I=E2=80=99m concerned if we delay c= losing out the docs there will be few people engaged to do a serious review o= f the results. A lot of work has gone into TAPS and I think we should aspir= e to finish strong. Comments? I=E2=80=99m especially interested to hear wh= at the doc editors think.

--aaron

_______________________________________________
Taps mailing l= ist
Taps@ietf.org<= /a>
htt= ps://www.ietf.org/mailman/listinfo/taps

_______________________________________________Taps mailing list
T= aps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
<= /blockquote>
= --Apple-Mail-C4F73ACE-7ED7-49DE-8908-159BAE3F2D53-- From nobody Sun Nov 17 06:48:38 2019 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 1F4EF12006D for ; Sun, 17 Nov 2019 06:48:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.248 X-Spam-Level: X-Spam-Status: No, score=0.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, 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 (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6BXzRrVoiRu for ; Sun, 17 Nov 2019 06:48:30 -0800 (PST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80135.outbound.protection.outlook.com [40.107.8.135]) (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 B874212010C for ; Sun, 17 Nov 2019 06:48:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lLRpvSEWvGpKXjo0bumMzZOMfHtd1okAfd4qKyLx7zk5Mj7q/EFjgze6eCT8Ybham3qVM4PSxEhrE1n0HKsPNe/uOyzxseZERT9dI1aMaWxn03V9S7EsutDUJPlggJ9PIZouijU91XP5r59VqHtb58GpQf9x4ePftFofNWP+RGlfWs6KvTzUK0U+ojY4DDA+auemjOnYpB9TEjILzPiDfWqYFj7Xp5+lp8vIyeG9L+WsK9tQyqWJoXnwTediwjQ6Trel/PKCBPbnVwif0FH7eYIaDnLPQO4MAYuYlKQ36ESZGJbP27BsDtg2CgUWxTYchZhk8WWwffB4aJJrBiVtEA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gDFpzJ58sPprdYbqj8N0DfvfMeiiZFan8il1C+loJo4=; b=RsQUlB6q247iLNDMS3unXzuY2Wy6G0ktQOTEmY2EN+fMz8OZ0dkd4XheKPoRQcuIQQMyAcBngTXCG5+oLbQz+RGG8KTMBNWU9Naai+Nd+/VargH3uIHW+kfnD3rTI9m+PFLeJhkpjTWLPRXSUt3eDnGJGyFIFXZW53SwOFNQbHG1ZQTYSuomlyfp0IjTb/csyrpAuQlpQ0VowPxL0hGKkG1vOdM/EH9IotgomRZ3QfiPyZNBGbab4NATrFn2vy+XBG2qBZEL5/oT098STcHxCV/yk70baRpnOirs+Qp/4mZmNtvpO0n2J2Cr2HXJjJsq9YDMw6MSY2yCfagvNfHtWQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gDFpzJ58sPprdYbqj8N0DfvfMeiiZFan8il1C+loJo4=; b=pWpEzTXo5VMcBTnmVNdlgvxW7Ui2WPW6w8D73ygFJs3WIn82b6N/W0kQqjMYPm1LZf8SIhwQHnw9kcIbeYKRnBxITG2plVaO832aUp4Rl+bSbqdtl8QT/u1iVQr2SDMGWJq1Cq05eLO9JUMT04zZEDW6sMjlENsJyZrtuhGwaaQ= Received: from AM0PR07MB5716.eurprd07.prod.outlook.com (20.178.115.216) by AM0PR07MB4643.eurprd07.prod.outlook.com (52.135.150.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.10; Sun, 17 Nov 2019 14:48:26 +0000 Received: from AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::8d07:c426:c2d7:51f2]) by AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::8d07:c426:c2d7:51f2%3]) with mapi id 15.20.2474.012; Sun, 17 Nov 2019 14:48:26 +0000 From: tom petch To: Aaron Falk , taps WG Thread-Topic: [Taps] finishing things Thread-Index: AQHVnVYRDZ2cOlZUtkag5A9HAx0/CA== Date: Sun, 17 Nov 2019 14:48:26 +0000 Message-ID: <024601d59d56$03820aa0$4001a8c0@gateway.2wire.net> References: <33DEC7AC-738B-436B-A42E-FC1500033283@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0286.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a1::34) To AM0PR07MB5716.eurprd07.prod.outlook.com (2603:10a6:208:11e::24) authentication-results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.211.103] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c36952ba-895b-4a64-e05d-08d76b6d33ac x-ms-traffictypediagnostic: AM0PR07MB4643: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 02243C58C6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(39860400002)(396003)(376002)(346002)(189003)(199004)(13464003)(386003)(6506007)(478600001)(26005)(102836004)(966005)(6306002)(44736005)(229853002)(5660300002)(6436002)(186003)(53546011)(9686003)(6512007)(81166006)(6246003)(66446008)(64756008)(66556008)(66476007)(66946007)(25786009)(8676002)(81156014)(71190400001)(81686011)(76176011)(81816011)(6486002)(50226002)(71200400001)(52116002)(446003)(8936002)(4720700003)(44716002)(62236002)(305945005)(14496001)(110136005)(256004)(99286004)(7736002)(316002)(14454004)(476003)(2906002)(86362001)(1556002)(3846002)(66066001)(486006)(6116002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4643; H:AM0PR07MB5716.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MFm0oDP8dYqECWlb+hA6lhzHi5hx2y3igk3GyBXiN3o1xeAKTgAUuCfrIQKzgBqEq66yTUtulACMnZUmPTcxF9K332V44xMwyrw6R/CVdEWdLk28DSmcuHc4tkz4t96gw9A2SLfr9DYqaNa5zt+ZjTVl2tRgWTPXGvWYYFncgNKU/9VkR4v9ygkld4eiV+R4+coSMzga3TaOiXwGgv02pABcFfTYzHVV1Ecm1J50qkDSecQpTNaLgVa7aMNVyB+BaDCp3CaSbwsnbyjay5CnOC9EHj7Uxon1zW6qDlYzJRto99xvCIIhZF7/JlFGidsaDe+u4g6aZ0jjPp3Ol6HDUWrw+gNkQDCLl/LkNZCSwXtnZyCd4jfDThxjB/kMC8Pr4I8ebLbxDcn1HAOQJo0kGl9ciinag59zd4Yq5sXO3RQhyIQQBeCC/BBWvsPUDJG+ x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <7332303FA92C524C8A72734F3461D04D@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: c36952ba-895b-4a64-e05d-08d76b6d33ac X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2019 14:48:26.1967 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: cIPIcY6QCRi25OaHyXjp7O8+ipDnkptzAt2F/FBYRb9r9jwKUHD5pbvxSz/EZs9liqvCAPbkXys3J2w0SduR4g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4643 Archived-At: Subject: Re: [Taps] finishing things 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: Sun, 17 Nov 2019 14:48:32 -0000 LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiAiQWFyb24gRmFsayIgPGFhcm9uLmZh bGtAZ21haWwuY29tPg0KVG86ICJ0YXBzIFdHIiA8dGFwc0BpZXRmLm9yZz4NClNlbnQ6IFNhdHVy ZGF5LCBOb3ZlbWJlciAxNiwgMjAxOSA3OjExIEFNDQpTdWJqZWN0OiBbVGFwc10gZmluaXNoaW5n IHRoaW5ncw0KDQoNCj4gSGV5IFdvcmtpbmcgR3JvdXAsDQo+DQo+IEJlZm9yZSB3ZSBtZWV0IG9u IFR1ZXNkYXkgSSB3YW50ZWQgdG8gcHV0IGFuIGlkZWEgb24gdGhlIHRhYmxlIHRoYXQgSQ0KPiB0 aGluayB3aWxsIHNoYXBlIG91ciB3ZyBkaXNjdXNzaW9uLiAgV2hhdCBkbyB5b3UgdGhpbmsgb2Yg c2V0dGluZyBhDQpnb2FsDQo+IG9mIFdHTEMgZm9yIG91ciB0aHJlZSBpbi1wcm9ncmVzcyBkb2Nz IGJlZm9yZSB0aGUgTWFyY2ggSUVURj8gIFRoaXMNCj4gd291bGQgcmVxdWlyZSBpbmNyZWFzaW5n IHdnIGFjdGl2aXR5LCBmb3IgZXhhbXBsZSwgaGF2aW5nIG1vbnRobHkNCmNhbGxzDQo+IHRvIGNv bnNpZGVyIGFuZCByZXNvbHZlIG9wZW4gaXNzdWVzLiAgSSB0aGluayB3ZeKAmXJlIHJlYWNoaW5n IGEgcG9pbnQNCj4gd2hlcmUgd2cgZW5nYWdlbWVudCBpcyBzdGFydGluZyB0byBkcm9wIGFuZCBJ 4oCZbSBjb25jZXJuZWQgaWYgd2UgZGVsYXkNCj4gY2xvc2luZyBvdXQgdGhlIGRvY3MgdGhlcmUg d2lsbCBiZSBmZXcgcGVvcGxlIGVuZ2FnZWQgdG8gZG8gYSBzZXJpb3VzDQo+IHJldmlldyBvZiB0 aGUgcmVzdWx0cy4gIEEgbG90IG9mIHdvcmsgaGFzIGdvbmUgaW50byBUQVBTIGFuZCBJIHRoaW5r DQp3ZQ0KPiBzaG91bGQgYXNwaXJlIHRvIGZpbmlzaCBzdHJvbmcuICBDb21tZW50cz8gIEnigJlt IGVzcGVjaWFsbHkgaW50ZXJlc3RlZA0KPiB0byBoZWFyIHdoYXQgdGhlIGRvYyBlZGl0b3JzIHRo aW5rLg0KDQpBYXJvbg0KDQpJIGFtIG5vdCBzdXJlIHdoaWNoIHRocmVlIHlvdSBoYXZlIGluIG1p bmQgYnV0IHN1c3BlY3QgdGhhdCBpdCBkb2VzIG5vdA0KaW5jbHVkZQ0KZHJhZnQtamhvbGxhbmQt dGFwcy1hcGkteWFuZw0KDQpUb20gUGV0Y2gNCg0KPiAtLWFhcm9uDQoNCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQotLS0tLS0tLQ0KDQoNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gVGFwcyBtYWlsaW5nIGxpc3QNCj4gVGFwc0BpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RhcHMNCj4NCg0K From nobody Sun Nov 17 18:28:15 2019 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 E6615120251 for ; Sun, 17 Nov 2019 18:28:13 -0800 (PST) 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_HELO_NONE=0.001, 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 Vr5toHSacGkb for ; Sun, 17 Nov 2019 18:28:12 -0800 (PST) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 1FCE1120048 for ; Sun, 17 Nov 2019 18:28:12 -0800 (PST) Received: by mail-pl1-x631.google.com with SMTP id e3so8835939plt.7 for ; Sun, 17 Nov 2019 18:28:12 -0800 (PST) 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; bh=vrGf1vnbJc35KCrZpVbdD7qLvpFETZjt0Xsl99egP1M=; b=AJhXFFx1hPFlnpo88uQww1jj18YO31ZJO7bygD5KHwzoioIbSkfpP+QdAtqWI8y31m 102tCAZ51SPTBPFlnqcFVKxVzsvfuBk4rEDtifexaSsN0kv9R/HQdAyMjtmcUXT1eZb+ BepB+6+7rQ39pP6Yd3nbL4gV5haLLRZ4ynNGOx16x3EgyxsN/giqkaUsbNyR/AawcyAQ g0e63xDiukRiiE7DnUJStPszljNFl/YNI319Tr+pKvVJh+mS7ZF50d+dPlvatTHknQ4t 7sHqW1oS4W8OLW5ZWIR2yq1ByeVOEPWKaK7dk7uYy6hIiddnvPTzMwjwVMGeU2QOfu2I L1RA== 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; bh=vrGf1vnbJc35KCrZpVbdD7qLvpFETZjt0Xsl99egP1M=; b=UMJcgrM8/10DQCa5OuDTJJBemz/ez5ZfLG7aNcVrRNXlnuUcACg50yk4qHH6Uix/fZ 1bBdQOvUuBBXOlraSNhTNEb4b/mpsweCsKLer7OGFDN+5oDzeGNfaYFACb9JuvveLKZ0 fPTBXhxAys2FyJaD+uWsCIerWAdlxzA/1bACmCsjNYb1e19QQc3u+x+aj4auwpo05MDR SClluPQwDIKqYE8QbBcdaHw/9nhHEAXSpjQp+mA1wv+JCENUKRcvv6z/vHvfdtXVTD2N JDE5nDheKGVaHNMTRcPG4nTMAUw8HIpGvS9+FfCjThyytAqAOLtnzS6X6yUMMOkYgXoL moHw== X-Gm-Message-State: APjAAAUyNUe+x18FfbJjGhNuhwtr2RX5hsqK9aFOnriSna4zGY1k4GoO r1xUUy2aaJHr88n+HtkyAf7QPoL18g62YA== X-Google-Smtp-Source: APXvYqxa8OtYdBfUG1+AH+jyXZwlPa1nd4nGObRJqfvmsxoKkTto/0Dj7C0WE2ccEtSnwGV350C2KQ== X-Received: by 2002:a17:90a:e28a:: with SMTP id d10mr37492803pjz.116.1574044091505; Sun, 17 Nov 2019 18:28:11 -0800 (PST) Received: from [172.19.217.89] ([2001:67c:370:128:a9d3:73e9:5a0f:be2c]) by smtp.gmail.com with ESMTPSA id m13sm17811664pga.70.2019.11.17.18.28.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Nov 2019 18:28:10 -0800 (PST) From: "Aaron Falk" To: "tom petch" Cc: "taps WG" Date: Mon, 18 Nov 2019 10:28:07 +0800 X-Mailer: MailMate (1.13r5655) Message-ID: <54F6C8B9-6F39-4315-B376-AA11D0B6F2E6@gmail.com> In-Reply-To: <024601d59d56$03820aa0$4001a8c0@gateway.2wire.net> References: <33DEC7AC-738B-436B-A42E-FC1500033283@gmail.com> <024601d59d56$03820aa0$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_7E72B675-E39C-40CB-8F16-2700BC18D19E_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] finishing things 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, 18 Nov 2019 02:28:14 -0000 --=_MailMate_7E72B675-E39C-40CB-8F16-2700BC18D19E_= Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit On 17 Nov 2019, at 22:48, tom petch wrote: > I am not sure which three you have in mind but suspect that it does > not > include > draft-jholland-taps-api-yang > > Tom Petch Thanks for bringing this up, Tom. Note that TAPS hasn’t adopted this draft as a working group item. We have some options. It could be absorbed into one of the TAPS docs if a) folks thought it was in-scope and sufficiently useful and b) it was mature enough. If not, we could consider adopting it in TAPS as a new work item. I’d prefer that it did not slow down completion of the 3 wg drafts. Thoughts? --aaron --=_MailMate_7E72B675-E39C-40CB-8F16-2700BC18D19E_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">On 17 Nov 2019, at 22:48, tom petch wrote:

I am not sure which three you have = in mind but suspect that it does not
include
draft-jholland-taps-api-yang

Tom Petch

Thanks for bringing this up, Tom. Note that= TAPS hasn=E2=80=99t adopted this draft as a working group item. We have= some options. It could be absorbed into one of the TAPS docs if a) folk= s thought it was in-scope and sufficiently useful and b) it was mature en= ough. If not, we could consider adopting it in TAPS as a new work item. = I=E2=80=99d prefer that it did not slow down completion of the 3 wg draft= s. Thoughts?

--aaron

--=_MailMate_7E72B675-E39C-40CB-8F16-2700BC18D19E_=-- From nobody Sun Nov 17 19:55:25 2019 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 5E607120826 for ; Sun, 17 Nov 2019 19:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 PIWKV_GSyrHW for ; Sun, 17 Nov 2019 19:55:21 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 7D8C6120850 for ; Sun, 17 Nov 2019 19:55:21 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id xAI3sUX0008360; Mon, 18 Nov 2019 03:55:18 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=gPcbdtNUjf+4yBuB+eL3+bCWafRYsNDzZcCHNRgrvWs=; b=f3sQFdv/lYEFBNOSy7oPJeYS1LwhXBALqz7ufco8KSDj5RrB/C1pDOl0CCrwnfCmGiq8 h2UDUX8zBbPYPSEoucbrAtZmCcMDSA1IhPfKQXY9PEcoMHvx3b5yhZkFaHkPt9rDAhyB YMQCpiJEmKIlbbR83fclgxV4A2Wa+Q5VoDnC62bqlkiqa1R27fzALSXLPs1Xr67J0HT7 r0V+oidaZGqyPRjXYD9MJgs4OGmx1dNeHLBYL4uykGWUr6qLIO9FtZK8XA7XNiMVcimi LR+3puVhqF/8xO+HIjafLgUlwL+4PF9yHV51PZatJVzLOZSsn4M6ZSOvCx+nMasQfwi5 4g== Received: from prod-mail-ppoint8 (prod-mail-ppoint8.akamai.com [96.6.114.122] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2wafqy6jkr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Nov 2019 03:55:17 +0000 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.27/8.16.0.27) with SMTP id xAI3l6wL011970; Sun, 17 Nov 2019 22:55:17 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.116]) by prod-mail-ppoint8.akamai.com with ESMTP id 2wadayy8gw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 17 Nov 2019 22:55:16 -0500 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.165.122) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.165.121) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 17 Nov 2019 21:55:15 -0600 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.165.122]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.165.122]) with mapi id 15.00.1473.005; Sun, 17 Nov 2019 21:55:15 -0600 From: "Holland, Jake" To: Aaron Falk , tom petch CC: taps WG Thread-Topic: [Taps] finishing things Thread-Index: AQHVnE0Tpi9zWVri3UOKosPPqqf7aKeQm5qA//+SOoA= Date: Mon, 18 Nov 2019 03:55:15 +0000 Message-ID: <8B6B4D22-64F5-451E-AE02-5F66719F5584@akamai.com> References: <33DEC7AC-738B-436B-A42E-FC1500033283@gmail.com> <024601d59d56$03820aa0$4001a8c0@gateway.2wire.net> <54F6C8B9-6F39-4315-B376-AA11D0B6F2E6@gmail.com> In-Reply-To: <54F6C8B9-6F39-4315-B376-AA11D0B6F2E6@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191110 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.216.241] Content-Type: multipart/alternative; boundary="_000_8B6B4D2264F5451EAE025F66719F5584akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-17_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1911140001 definitions=main-1911180030 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-17_05:2019-11-15,2019-11-17 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 mlxlogscore=999 clxscore=1011 priorityscore=1501 lowpriorityscore=0 bulkscore=0 mlxscore=0 suspectscore=0 impostorscore=0 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911180031 Archived-At: Subject: Re: [Taps] finishing things 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, 18 Nov 2019 03:55:23 -0000 --_000_8B6B4D2264F5451EAE025F66719F5584akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBtb3N0bHkgYWdyZWUsIHdpdGggYSBjYXZlYXQuDQoNCkEgY291cGxlIG9mIG5vdGVzIGFzIGF1 dGhvcjoNCg0KICAqICAgSeKAmWQgYmUgd2lsbGluZyB0byBjb250aW51ZSB0aGlzIHdvcmsgYXMg YSBXRyBpdGVtIGlmIHRoZSBXRyB3b3VsZCBsaWtlIHRvIGFkb3B0IGl0LCBlc3BlY2lhbGx5IGlm IGl0IG1lYW5zIHNvbWUgcGVvcGxlIHdpbGwgcmV2aWV3IGFuZCBhc3Npc3QgOikNCiAgKiAgIEkg dGhpbmsgaXTigJlzIG5vdCBjdXJyZW50bHkgbWF0dXJlIGVub3VnaCB0byBpbnRlZ3JhdGUgaW50 byBhbiBpbW1pbmVudCBsYXN0LWNhbGwgZHJhZnQgKHBhcnRpY3VsYXJseSBhcyByZWdhcmRzIHRo ZSBzZWN1cml0eSBwYXJhbWV0ZXJzLCBhcyBtZW50aW9uZWQgcHJldmlvdXNseSBvbi1saXN0LCBi dXQgbGlrZWx5IHNvbWUgb3RoZXIgYXJlYXMgYXJlIHdlYWsgYXMgd2VsbCkNCg0KDQpBbmQgbXkg Y2F2ZWF0LCBub3QgYXMgYXV0aG9yIGJ1dCBhcyB3ZyBwYXJ0aWNpcGFudDoNCkFsdGhvdWdoIEkg YWdyZWUgaXQgd291bGQgYmUgbmljZSB0byBhdm9pZCBibG9ja2luZyBwcm9ncmVzcyBvbiB0aGUg b3RoZXIgZHJhZnRzLCBJIHdvdWxkbuKAmXQgYmUgc3VycHJpc2VkIGlmIGEgd2lkZXIgZGV0YWls ZWQgcmV2aWV3IGFuZCBkaXNjdXNzaW9uIG9mIHRoZSB5YW5nIG1vZGVsIGNvdWxkIGJyaW5nIHRv IGxpZ2h0IHNvbWUgYW1iaWd1aXRpZXMgdGhhdCBoYXZlIGJlZW4gb3Zlcmxvb2tlZCBpbiB0aGUg ZXhpc3RpbmcgZHJhZnRzLCBwYXJ0aWN1bGFybHkgdGFwcy1pbnRlcmZhY2UuICBJbiB0aGF0IHNl bnNlLCBpdCBtaWdodCBtYWtlIHNlbnNlIHRvIGdldCBzdGFydGVkIHF1aWNrbHksIGlmIHdlIGlu dGVuZCB0byBkbyB0aGlzLg0KDQogICogICBub3RlIHRoYXQgdGhlIHNhbWUgaXMgdHJ1ZSBhcyBt b3JlLWNvbXBsZXRlIEFQSSBpbXBsZW1lbnRhdGlvbnMgYXJlIGRldmVsb3BlZCwgcmVnYXJkbGVz cyBvZiB3aGV0aGVyIGFzIGEgd2cgdGhlIGlzc3VlcyBhcmUgdGFja2xlZCB3aXRoIHRoZSB5YW5n IG1vZGVsLiAgKFRoZSBleGVyY2lzZSBvZiBhcHBseWluZyBhIG5ldyBsZXZlbCBvZiByaWdvciBh bmQgc3BlY2lmaWNpdHkgdG8gdGhlIGFic3RyYWN0aW9ucyB3cml0dGVuIGluIHRoZSBjdXJyZW50 IGRyYWZ0IGlzIHdoYXTigJlzIGxpa2VseSB0byBnZW5lcmF0ZSBzb21lIGluc2lnaHRzIHRoYXQg bWlnaHQgYmUgYmVzdCBhcHBsaWVkIHRvIHRleHQgb2YgdGhlIGRyYWZ0LCBub3QgdGhlIHlhbmcg bW9kZWwgc3BlY2lmaWNhbGx5KS4NCiAgKiAgIFRoaXMgaXMgYSBwb2ludCBpbiB0ZW5zaW9uIHdp dGggdGhlIGdvYWwgb2Ygd3JhcHBpbmcgdXAgdGhlIGV4aXN0aW5nIGRyYWZ0cy4gIE5vdCBzdXJl IGhvdyB0byBoYW5kbGUgaXQsIGJ1dCBwdWJsaXNoaW5nIHRhcHMtaW50ZXJmYWNlIHdpdGhvdXQg Zmlyc3QgdHJ5aW5nIHRvIG5haWwgZG93biBzcGVjaWZpY3MgaW4gc29tZSBkZXRhaWwsIElNTywg d2lsbCBkcmFtYXRpY2FsbHkgaW5jcmVhc2UgdGhlIGNoYW5jZXMgdGhhdCB3ZeKAmWxsIG5lZWQg dG8gaXNzdWUgZXJyYXRhIG9yIGxpdmUgd2l0aCByZWdyZXRzIG9uIHRoZSBwdWJsaXNoZWQgbGFu Z3VhZ2Ugb24gdGFwcyBSRkNzLiAgTWF5YmUgdGhhdOKAmXMgZmluZSwgdGhlcmUgYXJlIG1hbnkg aW1wZXJmZWN0IFJGQ3MsIGJ1dCB3b3J0aCB0aGlua2luZyBhYm91dC4NCg0KQmVzdCwNCkpha2UN Cg0KRnJvbTogQWFyb24gRmFsayA8YWFyb24uZmFsa0BnbWFpbC5jb20+DQpEYXRlOiAyMDE5LTEx LTE4IGF0IDEwOjI4DQpUbzogdG9tIHBldGNoIDxkYWVkdWx1c0BidGNvbm5lY3QuY29tPg0KQ2M6 IHRhcHMgV0cgPHRhcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1RhcHNdIGZpbmlzaGluZyB0 aGluZ3MNCg0KDQpPbiAxNyBOb3YgMjAxOSwgYXQgMjI6NDgsIHRvbSBwZXRjaCB3cm90ZToNCg0K SSBhbSBub3Qgc3VyZSB3aGljaCB0aHJlZSB5b3UgaGF2ZSBpbiBtaW5kIGJ1dCBzdXNwZWN0IHRo YXQgaXQgZG9lcyBub3QNCmluY2x1ZGUNCmRyYWZ0LWpob2xsYW5kLXRhcHMtYXBpLXlhbmcNCg0K VG9tIFBldGNoDQoNClRoYW5rcyBmb3IgYnJpbmdpbmcgdGhpcyB1cCwgVG9tLiBOb3RlIHRoYXQg VEFQUyBoYXNu4oCZdCBhZG9wdGVkIHRoaXMgZHJhZnQgYXMgYSB3b3JraW5nIGdyb3VwIGl0ZW0u IFdlIGhhdmUgc29tZSBvcHRpb25zLiBJdCBjb3VsZCBiZSBhYnNvcmJlZCBpbnRvIG9uZSBvZiB0 aGUgVEFQUyBkb2NzIGlmIGEpIGZvbGtzIHRob3VnaHQgaXQgd2FzIGluLXNjb3BlIGFuZCBzdWZm aWNpZW50bHkgdXNlZnVsIGFuZCBiKSBpdCB3YXMgbWF0dXJlIGVub3VnaC4gSWYgbm90LCB3ZSBj b3VsZCBjb25zaWRlciBhZG9wdGluZyBpdCBpbiBUQVBTIGFzIGEgbmV3IHdvcmsgaXRlbS4gSeKA mWQgcHJlZmVyIHRoYXQgaXQgZGlkIG5vdCBzbG93IGRvd24gY29tcGxldGlvbiBvZiB0aGUgMyB3 ZyBkcmFmdHMuIFRob3VnaHRzPw0KDQotLWFhcm9uDQo= --_000_8B6B4D2264F5451EAE025F66719F5584akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiBcKEJvZHkgQ1NcKSI7DQoJcGFub3NlLTE6MiAxMSA2IDQg MiAyIDIgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0 UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDAN Cgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJZm9udC12YXJpYW50 Om5vcm1hbCAhaW1wb3J0YW50Ow0KCWNvbG9yOndpbmRvd3RleHQ7DQoJdGV4dC10cmFuc2Zvcm06 bm9uZTsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lOw0KCXZlcnRpY2FsLWFsaWduOmJhc2Vs aW5lO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjI4OTI0MDY0MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6LTc0ODI0OTQ2NiAxNDYxODc0OTYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxp c3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoyMDA7DQoJbXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1m b250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGww OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30N Ci0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIg dmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgbW9zdGx5IGFncmVlLCB3aXRoIGEgY2F2ZWF0LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BIGNvdXBsZSBvZiBub3RlcyBhcyBhdXRob3I6PG86cD48L286cD48L3A+DQo8dWwg c3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ SeKAmWQgYmUgd2lsbGluZyB0byBjb250aW51ZSB0aGlzIHdvcmsgYXMgYSBXRyBpdGVtIGlmIHRo ZSBXRyB3b3VsZCBsaWtlIHRvIGFkb3B0IGl0LCBlc3BlY2lhbGx5IGlmIGl0IG1lYW5zIHNvbWUg cGVvcGxlIHdpbGwgcmV2aWV3IGFuZCBhc3Npc3QgOik8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxl dmVsMSBsZm8xIj5JIHRoaW5rIGl04oCZcyBub3QgY3VycmVudGx5IG1hdHVyZSBlbm91Z2ggdG8g aW50ZWdyYXRlIGludG8gYW4gaW1taW5lbnQgbGFzdC1jYWxsIGRyYWZ0IChwYXJ0aWN1bGFybHkg YXMgcmVnYXJkcyB0aGUgc2VjdXJpdHkgcGFyYW1ldGVycywgYXMgbWVudGlvbmVkIHByZXZpb3Vz bHkgb24tbGlzdCwgYnV0IGxpa2VseQ0KIHNvbWUgb3RoZXIgYXJlYXMgYXJlIHdlYWsgYXMgd2Vs bCk8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgbXkgY2F2ZWF0LCBub3QgYXMgYXV0aG9yIGJ1dCBhcyB3 ZyBwYXJ0aWNpcGFudDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsdGhv dWdoIEkgYWdyZWUgaXQgd291bGQgYmUgbmljZSB0byBhdm9pZCBibG9ja2luZyBwcm9ncmVzcyBv biB0aGUgb3RoZXIgZHJhZnRzLCBJIHdvdWxkbuKAmXQgYmUgc3VycHJpc2VkIGlmIGEgd2lkZXIg ZGV0YWlsZWQgcmV2aWV3IGFuZCBkaXNjdXNzaW9uIG9mIHRoZSB5YW5nIG1vZGVsIGNvdWxkIGJy aW5nIHRvIGxpZ2h0IHNvbWUgYW1iaWd1aXRpZXMgdGhhdCBoYXZlIGJlZW4gb3Zlcmxvb2tlZCBp biB0aGUNCiBleGlzdGluZyBkcmFmdHMsIHBhcnRpY3VsYXJseSB0YXBzLWludGVyZmFjZS4mbmJz cDsgSW4gdGhhdCBzZW5zZSwgaXQgbWlnaHQgbWFrZSBzZW5zZSB0byBnZXQgc3RhcnRlZCBxdWlj a2x5LCBpZiB3ZSBpbnRlbmQgdG8gZG8gdGhpcy48bzpwPjwvbzpwPjwvcD4NCjx1bCBzdHlsZT0i bWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5ub3RlIHRo YXQgdGhlIHNhbWUgaXMgdHJ1ZSBhcyBtb3JlLWNvbXBsZXRlIEFQSSBpbXBsZW1lbnRhdGlvbnMg YXJlIGRldmVsb3BlZCwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIGFzIGEgd2cgdGhlIGlzc3VlcyBh cmUgdGFja2xlZCB3aXRoIHRoZSB5YW5nIG1vZGVsLiZuYnNwOyAoVGhlIGV4ZXJjaXNlIG9mIGFw cGx5aW5nDQogYSBuZXcgbGV2ZWwgb2Ygcmlnb3IgYW5kIHNwZWNpZmljaXR5IHRvIHRoZSBhYnN0 cmFjdGlvbnMgd3JpdHRlbiBpbiB0aGUgY3VycmVudCBkcmFmdCBpcyB3aGF04oCZcyBsaWtlbHkg dG8gZ2VuZXJhdGUgc29tZSBpbnNpZ2h0cyB0aGF0IG1pZ2h0IGJlIGJlc3QgYXBwbGllZCB0byB0 ZXh0IG9mIHRoZSBkcmFmdCwgbm90IHRoZSB5YW5nIG1vZGVsIHNwZWNpZmljYWxseSkuPG86cD48 L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+VGhpcyBpcyBhIHBvaW50IGluIHRlbnNpb24g d2l0aCB0aGUgZ29hbCBvZiB3cmFwcGluZyB1cCB0aGUgZXhpc3RpbmcgZHJhZnRzLiZuYnNwOyBO b3Qgc3VyZSBob3cgdG8gaGFuZGxlIGl0LCBidXQgcHVibGlzaGluZyB0YXBzLWludGVyZmFjZSB3 aXRob3V0IGZpcnN0IHRyeWluZyB0byBuYWlsIGRvd24gc3BlY2lmaWNzIGluDQogc29tZSBkZXRh aWwsIElNTywgd2lsbCBkcmFtYXRpY2FsbHkgaW5jcmVhc2UgdGhlIGNoYW5jZXMgdGhhdCB3ZeKA mWxsIG5lZWQgdG8gaXNzdWUgZXJyYXRhIG9yIGxpdmUgd2l0aCByZWdyZXRzIG9uIHRoZSBwdWJs aXNoZWQgbGFuZ3VhZ2Ugb24gdGFwcyBSRkNzLiZuYnNwOyBNYXliZSB0aGF04oCZcyBmaW5lLCB0 aGVyZSBhcmUgbWFueSBpbXBlcmZlY3QgUkZDcywgYnV0IHdvcnRoIHRoaW5raW5nIGFib3V0Ljxv OnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SmFrZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+QWFyb24gRmFsayAmbHQ7YWFyb24uZmFsa0BnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0 ZTogPC9iPjIwMTktMTEtMTggYXQgMTA6Mjg8YnI+DQo8Yj5UbzogPC9iPnRvbSBwZXRjaCAmbHQ7 ZGFlZHVsdXNAYnRjb25uZWN0LmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPnRhcHMgV0cgJmx0O3Rh cHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbVGFwc10gZmluaXNoaW5n IHRoaW5nczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5P biAxNyBOb3YgMjAxOSwgYXQgMjI6NDgsIHRvbSBwZXRjaCB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Izc3Nzc3NyAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjBpbjtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206My43NXB0Ij4NCjxwPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM3Nzc3NzciPkkg YW0gbm90IHN1cmUgd2hpY2ggdGhyZWUgeW91IGhhdmUgaW4gbWluZCBidXQgc3VzcGVjdCB0aGF0 IGl0IGRvZXMgbm90PGJyPg0KaW5jbHVkZTxicj4NCmRyYWZ0LWpob2xsYW5kLXRhcHMtYXBpLXlh bmc8YnI+DQo8YnI+DQpUb20gUGV0Y2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+VGhhbmtzIGZvciBicmluZ2luZyB0aGlzIHVwLCBUb20uIE5vdGUgdGhhdCBUQVBTIGhh c27igJl0IGFkb3B0ZWQgdGhpcyBkcmFmdCBhcyBhIHdvcmtpbmcgZ3JvdXAgaXRlbS4gV2UgaGF2 ZSBzb21lIG9wdGlvbnMuIEl0IGNvdWxkIGJlIGFic29yYmVkIGludG8gb25lIG9mIHRoZSBUQVBT IGRvY3MgaWYgYSkgZm9sa3MgdGhvdWdodCBpdCB3YXMgaW4tc2NvcGUgYW5kDQogc3VmZmljaWVu dGx5IHVzZWZ1bCBhbmQgYikgaXQgd2FzIG1hdHVyZSBlbm91Z2guIElmIG5vdCwgd2UgY291bGQg Y29uc2lkZXIgYWRvcHRpbmcgaXQgaW4gVEFQUyBhcyBhIG5ldyB3b3JrIGl0ZW0uIEnigJlkIHBy ZWZlciB0aGF0IGl0IGRpZCBub3Qgc2xvdyBkb3duIGNvbXBsZXRpb24gb2YgdGhlIDMgd2cgZHJh ZnRzLiBUaG91Z2h0cz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+LS1hYXJvbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8B6B4D2264F5451EAE025F66719F5584akamaicom_-- From nobody Sun Nov 17 22:16:35 2019 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 1D60212089D for ; Sun, 17 Nov 2019 22:16:34 -0800 (PST) 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_HELO_NONE=0.001, 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 5_CFN9raoGeD for ; Sun, 17 Nov 2019 22:16:30 -0800 (PST) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 9AEF3120072 for ; Sun, 17 Nov 2019 22:16:30 -0800 (PST) Received: by mail-pg1-x534.google.com with SMTP id 15so9116664pgh.5 for ; Sun, 17 Nov 2019 22:16:30 -0800 (PST) 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=SHId87OP971+yUTESkSTsjr2N9UjBlWRjXMdW7wvtLI=; b=kAAyWr/pYM3A4d3Lj8n1TSszQYEQIArfwGDFNsRDiD1LFieLAkzD7D6i6O+8ka3637 msEOLUkmAA/ulUR1Frcqs7S6+iwwdFIfz0QL3UhClKZRpTx11mmeHzv26cCb9sHs8kli Ox8loKUXGs/FkZp1EBf8MDI2K9zoohxTqwszQYstOb3uRq+mcJgDo9JYNXikAI32X3nu 2fY+Yihn+oaipF4pw3MEI2Li4WqB9RKFR98gQWOJKwO364eKneu3U4rQwfB0DRVTnqe1 mAUuQEy+EFiA5WvuH+c1cxpjrjN36Vqg3MmIPhvRxFAer+rDipD+j1b9JcgOcmFNjPHF si3A== 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=SHId87OP971+yUTESkSTsjr2N9UjBlWRjXMdW7wvtLI=; b=D4HuIOEapKuh5Z/EagdY9QSu883M+fBIFlUPe6QqS2wnyDmhQm+uYj1bMihHqXwIIx 6NkYlZG+zlVfn1tIG6YILoOyt62MPwOWw1HOl37fpyYWtTmM+hkMCoTbYhF6jOa1R1dV Vz8xUqVNYgccIIqiG5ssM0Rb5IGzv1sCq9jkYJWkG1boBJHziPTYae2vRviIMj8NU3vP 7j1HAzbbPO9wsHImIsi2BR24zeMg1LZxU2N8ccM8BQSDVjeEJMDWGCm1Gf8jVHlzZr88 9A1YUbA+xdJ/nMuFrERzgLWwUj845LEhegZKNho5gV5GHYkALtzd4JbhwGBqR6juEAuT ERkg== X-Gm-Message-State: APjAAAWTGg+Sb4gn3UCuq91Bb5WLDB+5flDHw7iRsrMlnckwuc2Eu8hG ACdN/LHV5KfU9wUem32jhHk= X-Google-Smtp-Source: APXvYqz0NqV01OmyveCnLIj6LWAqrs2iuaGLRgALEfO/ctfr9WL/RMu4A/C7ro/QYF/C9Y/11z2fdg== X-Received: by 2002:a63:4246:: with SMTP id p67mr4821397pga.243.1574057789876; Sun, 17 Nov 2019 22:16:29 -0800 (PST) Received: from [172.19.219.31] ([2001:67c:370:128:19b5:382f:b016:5269]) by smtp.gmail.com with ESMTPSA id x3sm16912504pjq.10.2019.11.17.22.16.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Nov 2019 22:16:29 -0800 (PST) From: "Aaron Falk" To: "Holland, Jake" Cc: "tom petch" , "taps WG" Date: Mon, 18 Nov 2019 14:16:26 +0800 X-Mailer: MailMate (1.13r5655) Message-ID: <9445002A-3B1C-4B36-8502-EF22598D66B5@gmail.com> In-Reply-To: <8B6B4D22-64F5-451E-AE02-5F66719F5584@akamai.com> References: <33DEC7AC-738B-436B-A42E-FC1500033283@gmail.com> <024601d59d56$03820aa0$4001a8c0@gateway.2wire.net> <54F6C8B9-6F39-4315-B376-AA11D0B6F2E6@gmail.com> <8B6B4D22-64F5-451E-AE02-5F66719F5584@akamai.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_20369419-329A-4E79-B1D0-9A18619C4FF6_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[1243, 5452], "plain":[912, 2503], "uuid":"94F3782D-EA9A-46A1-B6C4-809DF3ADED8F"}] Archived-At: Subject: Re: [Taps] finishing things 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, 18 Nov 2019 06:16:34 -0000 --=_MailMate_20369419-329A-4E79-B1D0-9A18619C4FF6_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit I think your point about working on the YANG model may help validate or refine elements of the -interface spec but I think that will only happen if folks actually engage and work on it. IMO this is part of a larger question of whether it is better to hold the documents to allow them to mature as for more implementation and, in this case, alternative analysis, or publish them and expect to revise them if TAPS gets traction and we learn from experience what we got wrong. As I said in my earlier note, given what I see is diminishing energy in the working group I fear that waiting now will result in a reduced number of reviewers for WGLC and the associated conversations. This is just One Person’s Opinion and I will of course defer to wg consensus on what to do but it’s my gut feeling we need to push for closure now. Discussion welcome. --aaron On 18 Nov 2019, at 11:55, Holland, Jake wrote: > I mostly agree, with a caveat. > > A couple of notes as author: > > * I’d be willing to continue this work as a WG item if the WG > would like to adopt it, especially if it means some people will review > and assist :) > * I think it’s not currently mature enough to integrate into an > imminent last-call draft (particularly as regards the security > parameters, as mentioned previously on-list, but likely some other > areas are weak as well) > > > And my caveat, not as author but as wg participant: > Although I agree it would be nice to avoid blocking progress on the > other drafts, I wouldn’t be surprised if a wider detailed review and > discussion of the yang model could bring to light some ambiguities > that have been overlooked in the existing drafts, particularly > taps-interface. In that sense, it might make sense to get started > quickly, if we intend to do this. > > * note that the same is true as more-complete API implementations > are developed, regardless of whether as a wg the issues are tackled > with the yang model. (The exercise of applying a new level of rigor > and specificity to the abstractions written in the current draft is > what’s likely to generate some insights that might be best applied > to text of the draft, not the yang model specifically). > * This is a point in tension with the goal of wrapping up the > existing drafts. Not sure how to handle it, but publishing > taps-interface without first trying to nail down specifics in some > detail, IMO, will dramatically increase the chances that we’ll need > to issue errata or live with regrets on the published language on taps > RFCs. Maybe that’s fine, there are many imperfect RFCs, but worth > thinking about. > > Best, > Jake > > From: Aaron Falk > Date: 2019-11-18 at 10:28 > To: tom petch > Cc: taps WG > Subject: Re: [Taps] finishing things > > > On 17 Nov 2019, at 22:48, tom petch wrote: > > I am not sure which three you have in mind but suspect that it does > not > include > draft-jholland-taps-api-yang > > Tom Petch > > Thanks for bringing this up, Tom. Note that TAPS hasn’t adopted this > draft as a working group item. We have some options. It could be > absorbed into one of the TAPS docs if a) folks thought it was in-scope > and sufficiently useful and b) it was mature enough. If not, we could > consider adopting it in TAPS as a new work item. I’d prefer that it > did not slow down completion of the 3 wg drafts. Thoughts? > > --aaron --=_MailMate_20369419-329A-4E79-B1D0-9A18619C4FF6_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">I think your point about working on the YANG model may hel= p validate or refine elements of the -interface spec but I think that wil= l only happen if folks actually engage and work on it. IMO this is part = of a larger question of whether it is better to hold the documents to all= ow them to mature as for more implementation and, in this case, alternati= ve analysis, or publish them and expect to revise them if TAPS gets tract= ion and we learn from experience what we got wrong. As I said in my earl= ier note, given what I see is diminishing energy in the working group I f= ear that waiting now will result in a reduced number of reviewers for WGL= C and the associated conversations. This is just One Person=E2=80=99s Op= inion and I will of course defer to wg consensus on what to do but it=E2=80= =99s my gut feeling we need to push for closure now. Discussion welcome.=

--aaron

On 18 Nov 2019, at 11:55, Holland, Jake wrote:

I mostly agree, with a caveat.

=C2=A0

A couple of notes as author:

  • I=E2=80=99d be willing to continue thi= s work as a WG item if the WG would like to adopt it, especially if it me= ans some people will review and assist :)
  • I think it=E2=80=99s not currently mature enough to integrate int= o an imminent last-call draft (particularly as regards the security param= eters, as mentioned previously on-list, but likely some other areas are weak as well)

=C2=A0

=C2=A0

And my caveat, not as author but as wg participan= t:

Although I agree it would be nice to avoid blocki= ng progress on the other drafts, I wouldn=E2=80=99t be surprised if a wid= er detailed review and discussion of the yang model could bring to light = some ambiguities that have been overlooked in the existing drafts, particularly taps-interface.=C2=A0 In that sense, it mi= ght make sense to get started quickly, if we intend to do this.

  • note that the same is true as more-com= plete API implementations are developed, regardless of whether as a wg th= e issues are tackled with the yang model.=C2=A0 (The exercise of applying= a new level of rigor and specificity to the abstractions written in the = current draft is what=E2=80=99s likely to generate some insights that mig= ht be best applied to text of the draft, not the yang model specifically)= =2E
  • This is a point in tension wit= h the goal of wrapping up the existing drafts.=C2=A0 Not sure how to hand= le it, but publishing taps-interface without first trying to nail down sp= ecifics in some detail, IMO, will dramatically increase the chances that we=E2=80=99= ll need to issue errata or live with regrets on the published language on= taps RFCs.=C2=A0 Maybe that=E2=80=99s fine, there are many imperfect RFC= s, but worth thinking about.

=C2=A0

Best,

Jake

=C2=A0

F= rom: Aaron Falk &= lt;aaron.falk@gmail.com>
Date: 2019-11-18 at 10:28
To: tom petch <daedulus@btconnect.com>
Cc: taps WG <taps@ietf.org>
Subject: Re: [Taps] finishing things

=C2=A0

On 17 Nov 2019, at 22:4= 8, tom petch wrote:

=

I am not = sure which three you have in mind but suspect that it does not
include
draft-jholland-taps-api-yang

Tom Petch

Thanks for bringing thi= s up, Tom. Note that TAPS hasn=E2=80=99t adopted this draft as a working = group item. We have some options. It could be absorbed into one of the TA= PS docs if a) folks thought it was in-scope and sufficiently useful and b) it was mature enough. If not, we could consid= er adopting it in TAPS as a new work item. I=E2=80=99d prefer that it did= not slow down completion of the 3 wg drafts. Thoughts?

--aaron

--=_MailMate_20369419-329A-4E79-B1D0-9A18619C4FF6_=-- From nobody Sun Nov 17 22:45:03 2019 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 9B62C1200B3; Sun, 17 Nov 2019 22:45:01 -0800 (PST) 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.110.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: taps@ietf.org Message-ID: <157405950150.24213.3242690672708559632@ietfa.amsl.com> Date: Sun, 17 Nov 2019 22:45:01 -0800 Archived-At: Subject: [Taps] I-D Action: draft-ietf-taps-transport-security-10.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, 18 Nov 2019 06:45: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 the Interaction Between Security Protocols and Transport Services Authors : Theresa Enghardt Tommy Pauly Colin Perkins Kyle Rose Christopher A. Wood Filename : draft-ietf-taps-transport-security-10.txt Pages : 19 Date : 2019-11-17 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 by describing the interfaces required to add security protocols. 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 Transport Services 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-10 https://datatracker.ietf.org/doc/html/draft-ietf-taps-transport-security-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-taps-transport-security-10 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 Sun Nov 17 22:48:35 2019 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 0B7731200B3 for ; Sun, 17 Nov 2019 22:48:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 g-vRckIXVf8X for ; Sun, 17 Nov 2019 22:48:29 -0800 (PST) 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 E43F212089E for ; Sun, 17 Nov 2019 22:48:28 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id xAI6fsAV011382; Sun, 17 Nov 2019 22:48:27 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=9gPlS5eQWpowGEOEtpk0HPfaj0V57XMq2PEp3gWqLnc=; b=pTU2bVTF/GHDdCv/vt48FtV4HUMC4u1uVKhJQvfJthfUcLxJh8Ug6E3lGYSyz9akYsmd CM4K9pYyk1e29XZrTMi7fT33b9ZgmJY362B3401Y/ZfW/Tu0HsNrxpfFJOP4d1rgsKO8 aeyej+AJHMqsRw9iD5CJR2yq+zroR+agCEkfq3OnVZi9U7yzoEHhcQXyHb8bs2+oxIVE H+X/ZjUbHSowGWzYBXznNjZ6X0qCwyJH1Sd9kPOAV/TDJZqQDv+DzQXBWwRvcHLbbZy4 kyeUprOS95ZDihX9wR+Ja+4nNf0nU+QsqoYatoTzHJ3Y/l9hk/8hjJhr/iXcftYYJ/d1 1w== Received: from sg3-postinop-sz01.asia.apple.com (sg3-postinop-sz01.asia.apple.com [17.84.80.96]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2wb27np5n9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sun, 17 Nov 2019 22:48:27 -0800 Received: from sg3-mmpp-sz01.asia.apple.com (sg3-mmpp-sz01.asia.apple.com [17.84.80.93]) by sg3-postinop-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q1500BJYK8P1Q00@sg3-postinop-sz01.asia.apple.com>; Mon, 18 Nov 2019 14:48:25 +0800 (+08) Received: from process_milters-daemon.sg3-mmpp-sz01.asia.apple.com by sg3-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q1500N00J713000@sg3-mmpp-sz01.asia.apple.com>; Mon, 18 Nov 2019 14:48:25 +0800 (+08) X-Va-A: X-Va-T-CD: 5808c5f95406ec7719a15f5c3784581a X-Va-E-CD: 2faf3e1f7d62a2d6e9aecda335234026 X-Va-R-CD: 472b0024ed4b43a0ce09777bf5364f9a X-Va-CD: 0 X-Va-ID: 063cc4f9-18d1-494c-9574-e1993ba22e91 X-V-A: X-V-T-CD: 5808c5f95406ec7719a15f5c3784581a X-V-E-CD: 2faf3e1f7d62a2d6e9aecda335234026 X-V-R-CD: 472b0024ed4b43a0ce09777bf5364f9a X-V-CD: 0 X-V-ID: 34365d34-cf0c-4660-9c52-97c29a765a4f X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-17_05:,, signatures=0 Received: from [17.235.152.245] by sg3-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q15002CBK8EAO40@sg3-mmpp-sz01.asia.apple.com>; Mon, 18 Nov 2019 14:48:14 +0800 (+08) Sender: tpauly@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) From: Tommy Pauly In-reply-to: <157405950150.24213.3242690672708559632@ietfa.amsl.com> Date: Mon, 18 Nov 2019 14:48:13 +0800 Cc: Eric Rescorla Content-transfer-encoding: quoted-printable Message-id: <7A3FD581-4C22-4843-9561-7001C9B3DA74@apple.com> References: <157405950150.24213.3242690672708559632@ietfa.amsl.com> To: taps WG X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-17_05:, , signatures=0 Archived-At: Subject: Re: [Taps] I-D Action: draft-ietf-taps-transport-security-10.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, 18 Nov 2019 06:48:31 -0000 Hello all, The authors of the Transport Security Survey have heavily edited the = document in light of the review from ekr to clarify the scope and intent = of the document, and to emphasize the focus on interfaces up and down = the stack as opposed to security protocol details. To anyone who's been following this document, please do take a look at = this revision and provide your input! Best, Tommy > On Nov 18, 2019, at 2:45 PM, internet-drafts@ietf.org wrote: >=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 : A Survey of the Interaction Between Security = Protocols and Transport Services > Authors : Theresa Enghardt > Tommy Pauly > Colin Perkins > Kyle Rose > Christopher A. Wood > Filename : draft-ietf-taps-transport-security-10.txt > Pages : 19 > Date : 2019-11-17 >=20 > 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 by describing the > interfaces required to add security protocols. 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 = Transport > Services system may need to support. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-taps-transport-security/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-taps-transport-security-10 > = https://datatracker.ietf.org/doc/html/draft-ietf-taps-transport-security-1= 0 >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-taps-transport-security-10 >=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 From nobody Tue Nov 19 02:09:10 2019 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 3D5E212008D for ; Tue, 19 Nov 2019 02:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.247 X-Spam-Level: X-Spam-Status: No, score=0.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RATWARE_MS_HASH=2.148, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sRU3d4lOGRp for ; Tue, 19 Nov 2019 02:09:08 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00094.outbound.protection.outlook.com [40.107.0.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A453A120C04 for ; Tue, 19 Nov 2019 02:09:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CIQZpnfkz0Mbfyr5EF1zK7K3KBqefTQwK+NPp1eLUEE6r+Td3g8+cHNTDDDZBOkMI0Q5skQ/YFJnvHL3X1s7XFtEVhZEzRm9Nkl1WTukn/0xfJG+2bBl6giB0VyGKxrQGGcKfYXpsv0yMQx/pe0cvx0pYzzU1o7NjecqWtK65XG7OmRJ+qUBTKkjl6wGhqLpEHnlTnNsNAgHEcb2ob5rE/Y9nbO4LRsWYn7gB6d5FYBUEw5+MTKR68puo+eNkqLuf08BPxcg29aMo7/WB/lPy0jL+/6UMjZjQ3MPgFDwLyACJ8kQsIhmdvOSRCbktkrVEzqBn9/JJcrkQJFJFnghUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9crVhTclWvLFViVhIxRtAMb81MH/uLGbomJipw2fNX4=; b=MUmcrgMucRIo7BAp+WgjtI/wuRsG2Oi7jhxyOPcHolWw5JEssl0ueC48HMgdB/iKhhcNGIsW95r9S2JMNPgi4Mw8rQMGazEJgwTYFG762JVv+j0XkBM5RnPKU7gllaUC3DrFNHMt+6YDVTCXXmzH77j9swoc9GdXnrKZdyO0KYD2DJnUvfvF6qZJkWW0F0z3sAHzvGsBbFBhT5P89FCOAo6ur2yP3d1+rUw/WjK8EQt/JI5tVC0eYXnoDEw3U1hWbaa3a1EHcQE0up5W/kEzssTqzTZSgOGpr7FoQAio//WyIy5oU7AoI+E4isFOLC2Vx1kFg13lUNd0xTvvZ9HuzA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9crVhTclWvLFViVhIxRtAMb81MH/uLGbomJipw2fNX4=; b=pL2TD6PWxydcfb8jjqtZX6+IS6atdsfZciz0YahIwCei+3fXxej9CO+7aw+HNufsgG7x6YfVWBV1sKwyam6cA/rpbVTpsTTuq8g6PCrBDT76rorlhIc5nDh5f+OtS5cOwd8vk5ivzy2fiJzXkKutF9mkpNWjkKe9kEOYL5pvEfo= Received: from AM0PR07MB5716.eurprd07.prod.outlook.com (20.178.115.216) by AM0PR07MB4642.eurprd07.prod.outlook.com (52.135.149.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.10; Tue, 19 Nov 2019 10:09:04 +0000 Received: from AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::8d07:c426:c2d7:51f2]) by AM0PR07MB5716.eurprd07.prod.outlook.com ([fe80::8d07:c426:c2d7:51f2%3]) with mapi id 15.20.2474.015; Tue, 19 Nov 2019 10:09:04 +0000 From: tom petch To: Aaron Falk CC: taps WG Thread-Topic: [Taps] finishing things Thread-Index: AQHVnVYRDZ2cOlZUtkag5A9HAx0/CA== Date: Tue, 19 Nov 2019 10:09:04 +0000 Message-ID: <015001d59ec1$4f9a80e0$4001a8c0@gateway.2wire.net> References: <33DEC7AC-738B-436B-A42E-FC1500033283@gmail.com> <024601d59d56$03820aa0$4001a8c0@gateway.2wire.net> <54F6C8B9-6F39-4315-B376-AA11D0B6F2E6@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: CWLP123CA0083.GBRP123.PROD.OUTLOOK.COM (2603:10a6:401:5b::23) To AM0PR07MB5716.eurprd07.prod.outlook.com (2603:10a6:208:11e::24) authentication-results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Microsoft Outlook Express 6.00.2800.1106 x-originating-ip: [86.139.211.103] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0b69a517-758a-4597-6090-08d76cd881d3 x-ms-traffictypediagnostic: AM0PR07MB4642: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 022649CC2C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(136003)(366004)(376002)(346002)(13464003)(199004)(189003)(1556002)(476003)(14496001)(86362001)(14444005)(256004)(6916009)(71190400001)(186003)(446003)(3846002)(6246003)(6116002)(6486002)(71200400001)(4720700003)(44736005)(14454004)(26005)(8676002)(52116002)(6506007)(53546011)(81156014)(9686003)(6512007)(386003)(81166006)(76176011)(81816011)(81686011)(66066001)(99286004)(50226002)(8936002)(478600001)(102836004)(229853002)(316002)(4326008)(7736002)(66556008)(305945005)(64756008)(5660300002)(25786009)(62236002)(44716002)(66446008)(66476007)(486006)(66946007)(2906002)(6436002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4642; H:AM0PR07MB5716.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: t6nP68dF+Wk2CmtBHTajHwoB+AgAtIeHS9vHvQtUXYTzdWJyNpAQsKhpJNaiLvi91OyuU3jbzQ6BTDVOBHk+p0NMvDJI0Jzq6raBZg+/DRPi1QGy8P1E5FQnSYGCXBPeAJDf4YH5kUsuDug7YrXfcEtGKno5wbXjHJh6JmOa1X/0JpoFVIxTaA6+HT+te4SHVKIdSFWxBqfWnqBW3EmQ7UMXhLnrAm0hepne+UWj+5Scvel5oDR0dMEYsCcb1IMEQPFsLqb33YAk1aOI2Xm5gumu/amsyPJb3aLbuw/bDDConfybXzCxjWptruuJuu2H4Es9ZdXKdP1EbA9uUNRSQYS1g/pkM5Ee6WoEGIbMgnKNXcl+A7OZBAYEXIcF8mUwAEBiTjYuiTwpnYQIgGKAXXPyU61XJfMSYyMAYuZvg725YgOu+Q6l114qsKpk97gp x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0b69a517-758a-4597-6090-08d76cd881d3 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2019 10:09:04.4423 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: cMrlc9/ocwvwPO5Fw5X+Ms7LL70+vr1mfC3Hl4+Y9P9j1A9UJnfCu7+7KVCD+avl7QUN4YMmJ5vjxpwAzDwAtw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4642 Archived-At: Subject: Re: [Taps] finishing things 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, 19 Nov 2019 10:09:09 -0000 LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIkFhcm9uIEZhbGsiIDxhYXJvbi5m YWxrQGdtYWlsLmNvbT4NClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTgsIDIwMTkgMjoyOCBBTQ0K DQo+IE9uIDE3IE5vdiAyMDE5LCBhdCAyMjo0OCwgdG9tIHBldGNoIHdyb3RlOg0KPg0KPiA+IEkg YW0gbm90IHN1cmUgd2hpY2ggdGhyZWUgeW91IGhhdmUgaW4gbWluZCBidXQgc3VzcGVjdCB0aGF0 IGl0IGRvZXMNCj4gPiBub3QNCj4gPiBpbmNsdWRlDQo+ID4gZHJhZnQtamhvbGxhbmQtdGFwcy1h cGkteWFuZw0KPiA+DQo+ID4gVG9tIFBldGNoDQo+DQo+IFRoYW5rcyBmb3IgYnJpbmdpbmcgdGhp cyB1cCwgVG9tLiAgTm90ZSB0aGF0IFRBUFMgaGFzbuKAmXQgYWRvcHRlZCB0aGlzDQo+IGRyYWZ0 IGFzIGEgd29ya2luZyBncm91cCBpdGVtLiAgV2UgaGF2ZSBzb21lIG9wdGlvbnMuICBJdCBjb3Vs ZCBiZQ0KPiBhYnNvcmJlZCBpbnRvIG9uZSBvZiB0aGUgVEFQUyBkb2NzIGlmIGEpIGZvbGtzIHRo b3VnaHQgaXQgd2FzIGluLXNjb3BlDQo+IGFuZCBzdWZmaWNpZW50bHkgdXNlZnVsIGFuZCBiKSBp dCB3YXMgbWF0dXJlIGVub3VnaC4gIElmIG5vdCwgd2UgY291bGQNCj4gY29uc2lkZXIgYWRvcHRp bmcgaXQgaW4gVEFQUyBhcyBhIG5ldyB3b3JrIGl0ZW0uIEnigJlkIHByZWZlciB0aGF0IGl0DQo+ IGRpZCBub3Qgc2xvdyBkb3duIGNvbXBsZXRpb24gb2YgdGhlIDMgd2cgZHJhZnRzLiAgVGhvdWdo dHM/DQoNCkkgYW0gc3RpbGwgbm90IHN1cmUgd2hpY2ggdGhyZWUgSS1EcyB5b3UgaGF2ZSBpbiBt aW5kIQ0KDQpUaGUgY2hhbGxlbmdlIHdpdGggdGhpcyBJLUQgaXMgdGhhdCBpdCBtYXkgYmVjb21l IGRlcGVuZGVudCBvbiBjb21tb24NCnNlY3VyaXR5IG1vZHVsZXMgd2hpY2ggZW1lcmdlIGZyb20g TmV0Y29uZiBhdCBzb21lIGZ1dHVyZSBkYXRlOyB0aGF0DQpkYXRlIGNvdWxkIGJlIGEgbG9uZyB3 YXkgb2ZmLiAgSSBzdWdnZXN0ZWQgdG8gSmFrZSB0aGF0IGhlIHNob3VsZCBzdGF5DQp3aXRoIFJZ TyBzZWN1cml0eSBzdHJ1Y3R1cmVzIGluIHdoaWNoIGNhc2UgSSB3b3VsZCBzZWUgaXQgYXMgZmVh c2libGUgdG8NCmluY29ycG9yYXRlIGl0IGluIHRoZSB0aW1lc2NhbGUgeW91IHN1Z2dlc3QsIGJ1 dCB0aGF0IGRvZXMgZGVwZW5kIG9uIGl0DQpnZXR0aW5nIGFkZXF1YXRlIHJldmlldy4NCg0KVG9t IFBldGNoDQoNCj4gLS1hYXJvbg0KDQo= From nobody Tue Nov 19 02:12:36 2019 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 88FC51208AB for ; Tue, 19 Nov 2019 02:12:34 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, 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 riujI-N5oMLC for ; Tue, 19 Nov 2019 02:12:29 -0800 (PST) Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 A80F31208A7 for ; Tue, 19 Nov 2019 02:12:29 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id xAJA8An9050752; Tue, 19 Nov 2019 02:12:25 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=MsOuTgiQTvkSv0CcYbN63fKEM8kXbUBVvIpXlW02ftI=; b=AgeQ7qLVm7sBbW1zU44uWFmVxpfiQCBpNk7HLU1dTc5fcwf5hezAfe63wod/hooLTSSj 4ZmA6ISLNh6DoDj25K+lX0IDM+i5aMkLLBmar/PQvqTN/ZU/jX6tyagw8hNtb2cdijZ+ mEQhWxkMNvb1pzGVzKkKLwmeB05PgnT2V+PjJ8PxYLfoYAJLdak5BlF/vXlip9FE2rUx T+wiRTk7/H5x7yufApUhrlRPSnGWsAhda2oB8cJSCVrfuO1V7OAi0B7E684ZVjPpLPYM mCp9vE8SiN1uFeeABfRH0d0SsvLhQV+AR3TF8/eOtqxiL0eOWC058Y3SuldcqdifVqwW UA== Received: from cistus.asia.apple.com (cistus.asia.apple.com [17.84.80.83]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2wagn6cjmr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 19 Nov 2019 02:12:25 -0800 Received: from sng-mmpp-sz01.asia.apple.com (sng-mmpp-sz01.asia.apple.com [17.84.80.62]) by cistus.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q1700872OCNH900@cistus.asia.apple.com>; Tue, 19 Nov 2019 18:12:23 +0800 (+08) Received: from process_milters-daemon.sng-mmpp-sz01.asia.apple.com by sng-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q1700700MNL3E00@sng-mmpp-sz01.asia.apple.com>; Tue, 19 Nov 2019 18:12:23 +0800 (+08) X-Va-A: X-Va-T-CD: 1978c7194ff51642a1ba37c073f213c9 X-Va-E-CD: 704bddd9ebc1619687cf90c050f1e52f X-Va-R-CD: 3940a1ab24091ddf08ad371913149d48 X-Va-CD: 0 X-Va-ID: b7c4369d-0d5f-457c-9d83-f937ba2bd8b9 X-V-A: X-V-T-CD: 1978c7194ff51642a1ba37c073f213c9 X-V-E-CD: 704bddd9ebc1619687cf90c050f1e52f X-V-R-CD: 3940a1ab24091ddf08ad371913149d48 X-V-CD: 0 X-V-ID: fae26357-54bf-4d67-9a7e-7e450f93a26f X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-19_02:,, signatures=0 Received: from [17.235.158.138] by sng-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q17002JYOC8HC10@sng-mmpp-sz01.asia.apple.com>; Tue, 19 Nov 2019 18:12:11 +0800 (+08) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <074229D9-2E05-413A-B585-3E1E0ED0F3DE@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_1623387F-6FBC-4A39-B435-0B64E0A8746E" MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Date: Tue, 19 Nov 2019 18:12:06 +0800 In-reply-to: <015001d59ec1$4f9a80e0$4001a8c0@gateway.2wire.net> Cc: Aaron Falk , taps WG To: tom petch References: <33DEC7AC-738B-436B-A42E-FC1500033283@gmail.com> <024601d59d56$03820aa0$4001a8c0@gateway.2wire.net> <54F6C8B9-6F39-4315-B376-AA11D0B6F2E6@gmail.com> <015001d59ec1$4f9a80e0$4001a8c0@gateway.2wire.net> X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-19_03:, , signatures=0 Archived-At: Subject: Re: [Taps] finishing things 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, 19 Nov 2019 10:12:34 -0000 --Apple-Mail=_1623387F-6FBC-4A39-B435-0B64E0A8746E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 19, 2019, at 6:09 PM, tom petch wrote: >=20 > ----- Original Message ----- > From: "Aaron Falk" > > Sent: Monday, November 18, 2019 2:28 AM >=20 >> On 17 Nov 2019, at 22:48, tom petch wrote: >>=20 >>> I am not sure which three you have in mind but suspect that it does >>> not >>> include >>> draft-jholland-taps-api-yang >>>=20 >>> Tom Petch >>=20 >> Thanks for bringing this up, Tom. Note that TAPS hasn=E2=80=99t = adopted this >> draft as a working group item. We have some options. It could be >> absorbed into one of the TAPS docs if a) folks thought it was = in-scope >> and sufficiently useful and b) it was mature enough. If not, we = could >> consider adopting it in TAPS as a new work item. I=E2=80=99d prefer = that it >> did not slow down completion of the 3 wg drafts. Thoughts? >=20 > I am still not sure which three I-Ds you have in mind! Our three core documents are (from = https://datatracker.ietf.org/wg/taps/documents/): https://datatracker.ietf.org/doc/draft-ietf-taps-arch/ https://datatracker.ietf.org/doc/draft-ietf-taps-interface/ https://datatracker.ietf.org/doc/draft-ietf-taps-impl/ >=20 > The challenge with this I-D is that it may become dependent on common > security modules which emerge from Netconf at some future date; that > date could be a long way off. I suggested to Jake that he should stay > with RYO security structures in which case I would see it as feasible = to > incorporate it in the timescale you suggest, but that does depend on = it > getting adequate review. As this is an individual document, and we're not sure as a group if we = want to adopt any such work, this won't be on the schedule for the short = term. Good to know the possible dependency though! Thanks, Tommy >=20 > Tom Petch >=20 >> --aaron >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps = --Apple-Mail=_1623387F-6FBC-4A39-B435-0B64E0A8746E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 19, 2019, at 6:09 PM, tom petch <daedulus@btconnect.com> wrote:

----- Original Message = -----
From: "Aaron = Falk" <aaron.falk@gmail.com>
Sent: Monday, November 18, 2019 2:28 AM

On 17 = Nov 2019, at 22:48, tom petch wrote:

I am not sure which = three you have in mind but suspect that it does
not
include
draft-jholland-taps-api-yang

Tom Petch

Thanks for bringing this up, Tom.  Note that TAPS = hasn=E2=80=99t adopted this
draft as a working group item. =  We have some options.  It could be
absorbed = into one of the TAPS docs if a) folks thought it was in-scope
and sufficiently useful and b) it was mature enough.  If = not, we could
consider adopting it in TAPS as a new work = item. I=E2=80=99d prefer that it
did not slow down = completion of the 3 wg drafts.  Thoughts?

I am still not sure which three I-Ds you have in = mind!

Our three = core documents are (from https://datatracker.ietf.org/wg/taps/documents/):

https://datatracker.ietf.org/doc/draft-ietf-taps-arch/
https://datatracker.ietf.org/doc/draft-ietf-taps-impl/


The challenge = with this I-D is that it may become dependent on common
security modules which emerge = from Netconf at some future date; that
date could be a long way off.  I suggested to Jake that = he should stay
with RYO security structures in which case I would see it as = feasible to
incorporate = it in the timescale you suggest, but that does depend on it
getting adequate = review.

As = this is an individual document, and we're not sure as a group if we want = to adopt any such work, this won't be on the schedule for the short = term. Good to know the possible dependency though!

Thanks,
Tommy


Tom Petch

--aaron

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

= --Apple-Mail=_1623387F-6FBC-4A39-B435-0B64E0A8746E-- From nobody Tue Nov 19 02:46:56 2019 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 D621F1208DD for ; Tue, 19 Nov 2019 02:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=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 hC30oqVjvCne for ; Tue, 19 Nov 2019 02:46:52 -0800 (PST) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 82FF71208AB for ; Tue, 19 Nov 2019 02:46:49 -0800 (PST) Received: from smtp-3-0001.mail.infomaniak.ch (smtp-3-0001.mail.infomaniak.ch [10.4.36.108]) by smtp-sh2.infomaniak.ch (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id xAJAkkWP226846 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 19 Nov 2019 11:46:46 +0100 Received: from dhcp-93f4.meeting.ietf.org (unknown [31.133.147.244]) by smtp-3-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 27001101316A5 for ; Tue, 19 Nov 2019 11:46:45 +0100 (CET) From: "Brian Trammell (IETF)" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Tue, 19 Nov 2019 18:46:45 +0800 To: taps WG X-Mailer: Apple Mail (2.3445.104.11) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: [Taps] Authors' meeting, Friday 08:30 - 10:00, VIP B (IAB room) 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, 19 Nov 2019 10:46:55 -0000 Greetings, all, We'll have a TAPS author's meeting (laptops open, writing PRs) from 8:30 = - 10:00 on Friday in the VIP B room at the venue (across from the Olivia = / Sophia rooms, since the signage is suboptimal). Cheers, Brian= From nobody Wed Nov 20 07:15:50 2019 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 B1D79120805 for ; Wed, 20 Nov 2019 07:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 OnyV5qH9pa-D for ; Wed, 20 Nov 2019 07:15:47 -0800 (PST) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 7359E120024 for ; Wed, 20 Nov 2019 07:15:46 -0800 (PST) Received: from smtp-2-0001.mail.infomaniak.ch (smtp-2-0001.mail.infomaniak.ch [10.5.36.108]) by smtp-sh2.infomaniak.ch (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id xAKFFijW179963 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 20 Nov 2019 16:15:44 +0100 Received: from [10.128.30.18] (unknown [61.8.238.244]) by smtp-2-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 2E64210037F1A for ; Wed, 20 Nov 2019 16:15:43 +0100 (CET) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 From: "Brian Trammell (IETF)" Mime-Version: 1.0 (1.0) Date: Wed, 20 Nov 2019 23:15:41 +0800 Message-Id: <8A8FE49C-39CA-42CC-86EA-8B07BC5C3F01@trammell.ch> In-Reply-To: References: To: taps WG X-Mailer: iPhone Mail (16G102) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Taps] Authors' meeting, Friday 08:30 - 10:00, VIP B (IAB room) 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, 20 Nov 2019 15:15:50 -0000 Greetings, all The Friday time, it turns out, is less than ideal; I=E2=80=99ll have trouble= showing up early enough to be useful and at least one other author told me= they=E2=80=99d have to bow out of a breakfast meeting to make it. Jet lag, it=E2=80=99s a hell of a drug. Short notice, I know, but would people be available for an authors=E2=80=99 m= eeting / editing session tomorrow (Thursday) over lunch? The idea is to brin= g food and meet in the IESG room (Mirja has offered to reserve it to us); if= we can make good progress there, then we=E2=80=99re done. if not, I still h= ave the Friday IAB room reservation. In either case the plan is to sit down and write, discussing suggested text a= nd merging PRs to take advantage of higher bandwidth of everyone being here.= Thanks, cheers, and apologies for the organizational skill, Brian=20 > On 19 Nov 2019, at 18:46, Brian Trammell (IETF) wrote: >=20 > Greetings, all, >=20 > We'll have a TAPS author's meeting (laptops open, writing PRs) from 8:30 -= 10:00 on Friday in the VIP B room at the venue (across from the Olivia / So= phia rooms, since the signage is suboptimal). >=20 > Cheers, >=20 > Brian From nobody Wed Nov 20 07:34:48 2019 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 AD344120805 for ; Wed, 20 Nov 2019 07:34:46 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 3jSZJpTiDV9K for ; Wed, 20 Nov 2019 07:34:44 -0800 (PST) Received: from mail-out02.uio.no (mail-out02.uio.no [IPv6:2001:700:100:8210::71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06DCF120013 for ; Wed, 20 Nov 2019 07:34:43 -0800 (PST) Received: from mail-mx11.uio.no ([129.240.10.83]) by mail-out02.uio.no with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iXS08-000Fct-MH; Wed, 20 Nov 2019 16:34:40 +0100 Received: from dhcp-96d5.meeting.ietf.org ([31.133.150.213]) by mail-mx11.uio.no with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.92.3) (envelope-from ) id 1iXS06-00019U-Tc; Wed, 20 Nov 2019 16:34:40 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Michael Welzl In-Reply-To: <8A8FE49C-39CA-42CC-86EA-8B07BC5C3F01@trammell.ch> Date: Wed, 20 Nov 2019 23:34:34 +0800 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <8A8FE49C-39CA-42CC-86EA-8B07BC5C3F01@trammell.ch> To: "Brian Trammell (IETF)" X-Mailer: Apple Mail (2.3445.104.11) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx11.uio.no: 31.133.150.213 is neither permitted nor denied by domain of ifi.uio.no) client-ip=31.133.150.213; envelope-from=michawe@ifi.uio.no; helo=dhcp-96d5.meeting.ietf.org; 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: 7B3CCFFB1B624B7B369C18D0839A83D2DFCBFECC Archived-At: Subject: Re: [Taps] Authors' meeting, Friday 08:30 - 10:00, VIP B (IAB room) 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, 20 Nov 2019 15:34:47 -0000 > On Nov 20, 2019, at 11:15 PM, Brian Trammell (IETF) = wrote: >=20 > Greetings, all >=20 > The Friday time, it turns out, is less than ideal; I=E2=80=99ll have = trouble showing up early enough to be useful and at least one other = author told me they=E2=80=99d have to bow out of a breakfast meeting to = make it. >=20 > Jet lag, it=E2=80=99s a hell of a drug. >=20 > Short notice, I know, but would people be available for an authors=E2=80= =99 meeting / editing session tomorrow (Thursday) over lunch? The idea = is to bring food and meet in the IESG room (Mirja has offered to reserve = it to us); if we can make good progress there, then we=E2=80=99re done. = if not, I still have the Friday IAB room reservation. Works fine for me > In either case the plan is to sit down and write, discussing suggested = text and merging PRs to take advantage of higher bandwidth of everyone = being here. >=20 > Thanks, cheers, and apologies for the organizational skill, >=20 > Brian=20 >=20 >=20 >=20 >> On 19 Nov 2019, at 18:46, Brian Trammell (IETF) = wrote: >>=20 >> Greetings, all, >>=20 >> We'll have a TAPS author's meeting (laptops open, writing PRs) from = 8:30 - 10:00 on Friday in the VIP B room at the venue (across from the = Olivia / Sophia rooms, since the signage is suboptimal). >>=20 >> Cheers, >>=20 >> Brian >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Wed Nov 20 16:46:30 2019 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 B588D12006B for ; Wed, 20 Nov 2019 16:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 LAVqFdBwIvzq for ; Wed, 20 Nov 2019 16:46:27 -0800 (PST) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 CDB5C1208CA for ; Wed, 20 Nov 2019 16:46:26 -0800 (PST) Received: from smtp-3-0000.mail.infomaniak.ch (smtp-3-0000.mail.infomaniak.ch [10.4.36.107]) by smtp-sh2.infomaniak.ch (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id xAL0kOWG079760 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 Nov 2019 01:46:24 +0100 Received: from [IPv6:2001:67c:370:128:11d8:71b3:9cc6:1684] (unknown [IPV6:2001:67c:370:128:11d8:71b3:9cc6:1684]) by smtp-3-0000.mail.infomaniak.ch (Postfix) with ESMTPA id A58C01006CB1B; Thu, 21 Nov 2019 01:46:23 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Brian Trammell (IETF)" In-Reply-To: Date: Thu, 21 Nov 2019 08:46:21 +0800 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <10652F90-512E-4119-9CEC-64302443D96D@trammell.ch> References: <8A8FE49C-39CA-42CC-86EA-8B07BC5C3F01@trammell.ch> To: Michael Welzl X-Mailer: Apple Mail (2.3445.104.11) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Taps] Authors' meeting, Friday 08:30 - 10:00, VIP B (IAB room) 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, 21 Nov 2019 00:46:30 -0000 ...and we've confirmed the IESG room reservation over lunchtime. It = seems at least Michael and I will be there, please join if you can and = we can all close some issues together. Cheers, Brian > On 20 Nov 2019, at 23:34, Michael Welzl wrote: >=20 >> On Nov 20, 2019, at 11:15 PM, Brian Trammell (IETF) = wrote: >>=20 >> Greetings, all >>=20 >> The Friday time, it turns out, is less than ideal; I=E2=80=99ll have = trouble showing up early enough to be useful and at least one other = author told me they=E2=80=99d have to bow out of a breakfast meeting to = make it. >>=20 >> Jet lag, it=E2=80=99s a hell of a drug. >>=20 >> Short notice, I know, but would people be available for an authors=E2=80= =99 meeting / editing session tomorrow (Thursday) over lunch? The idea = is to bring food and meet in the IESG room (Mirja has offered to reserve = it to us); if we can make good progress there, then we=E2=80=99re done. = if not, I still have the Friday IAB room reservation. >=20 > Works fine for me >=20 >=20 >> In either case the plan is to sit down and write, discussing = suggested text and merging PRs to take advantage of higher bandwidth of = everyone being here. >>=20 >> Thanks, cheers, and apologies for the organizational skill, >>=20 >> Brian=20 >>=20 >>=20 >>=20 >>> On 19 Nov 2019, at 18:46, Brian Trammell (IETF) = wrote: >>>=20 >>> Greetings, all, >>>=20 >>> We'll have a TAPS author's meeting (laptops open, writing PRs) from = 8:30 - 10:00 on Friday in the VIP B room at the venue (across from the = Olivia / Sophia rooms, since the signage is suboptimal). >>>=20 >>> Cheers, >>>=20 >>> Brian >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps From nobody Wed Nov 20 16:48:30 2019 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 238351208D6 for ; Wed, 20 Nov 2019 16:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 Xg6jjSMBCzIO for ; Wed, 20 Nov 2019 16:48:27 -0800 (PST) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (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 2A31C12006B for ; Wed, 20 Nov 2019 16:48:27 -0800 (PST) Received: by mail-pf1-x431.google.com with SMTP id 3so688243pfb.10 for ; Wed, 20 Nov 2019 16:48:27 -0800 (PST) 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=bupnB+UyCjabo2TrQzawR5IU6phXQeUAGhMJYjJPVtQ=; b=X4SIBG/4kr/gymsmY4AS5mwe5363n34H64RkMAwlgLCKwctDhY1FDM4+zBcnsydREf CW2U+wScsQi9KMDX28GxYwNS9PfcHkFs2Y5SnziZYPNwc53HuwSE0EZk3RIIcBRchCMK bGXnFD7PbObyaydIlvCuvRxGxZdM0DUUZwLdiggHeMEMjsUEa/REMZBDPpe3H4HQNk6t 5b9FPB6t5rW/uTuUsBFcR6Wnm3cnbFpcV+519mHntJFUpEkmz68XID91lx03t/pWs6Nt dUc5L52XtdsJuXBqfQQA4Be1UYBhe/dutRmtJ1nZyu673kU00T4DA8mVsO3UqV2wfhVs LGDQ== 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=bupnB+UyCjabo2TrQzawR5IU6phXQeUAGhMJYjJPVtQ=; b=oTsVS9d3x1YNRvfAqWMbWVZWRi02nMbBjmWu69WpO9ag9JEe/DKZE+7TaXZCfh5Wrt 5asszBW/OE/csOdUTXeRQOO3RXmOAHNYyg3Yp3vnPgydZ38kg4/zFdviwZFCJg5XDvjk Li8Fr8HX1XwGAjjhoe2/4qhaPgQ/DUDlrlfFWvt1SMyGtPlcqNkvS9PS1OspJAuiPdh2 qhtm9jjcek5yFjaGvaNRKu04NT6j7oVboMW/Fu5ERvKfizcPsg9UzYe/DUZfz3E/0jQW NFrtLrN6y/D/ntyJswhQFJh25dvzZLCnuaWky4Isz6V8m1t755+btEXtrXzx5f5v8Zh3 7FbA== X-Gm-Message-State: APjAAAVdDxKp4TR4ku2VCQGSGEykoqiTN6ZHj2n+JXM+ZNeD0RUEeFT0 bjJVH02ZLtSFGm3UxN4K/hoST9zGv9h7q2oDDW0= X-Google-Smtp-Source: APXvYqzbbyp+asaVRo9PiK3rAQeEy2wtqLxHLeUdnrR26tLcwTFn40598JBMaPozsruMFc5OvyP8cFXrXntJFM1BcKs= X-Received: by 2002:a63:445c:: with SMTP id t28mr6459624pgk.348.1574297306239; Wed, 20 Nov 2019 16:48:26 -0800 (PST) MIME-Version: 1.0 References: <8A8FE49C-39CA-42CC-86EA-8B07BC5C3F01@trammell.ch> <10652F90-512E-4119-9CEC-64302443D96D@trammell.ch> In-Reply-To: <10652F90-512E-4119-9CEC-64302443D96D@trammell.ch> From: Aaron Falk Date: Thu, 21 Nov 2019 08:48:15 +0800 Message-ID: To: "Brian Trammell (IETF)" Cc: Michael Welzl , "taps@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b5975a0597d0a72c" Archived-At: Subject: Re: [Taps] Authors' meeting, Friday 08:30 - 10:00, VIP B (IAB room) 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, 21 Nov 2019 00:48:29 -0000 --000000000000b5975a0597d0a72c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Does the IESG room have another name for routing purposes? On Thu, Nov 21, 2019 at 8:46 AM Brian Trammell (IETF) wrote: > ...and we've confirmed the IESG room reservation over lunchtime. It seems > at least Michael and I will be there, please join if you can and we can a= ll > close some issues together. > > Cheers, > > Brian > > > On 20 Nov 2019, at 23:34, Michael Welzl wrote: > > > >> On Nov 20, 2019, at 11:15 PM, Brian Trammell (IETF) > wrote: > >> > >> Greetings, all > >> > >> The Friday time, it turns out, is less than ideal; I=E2=80=99ll have t= rouble > showing up early enough to be useful and at least one other author told = me > they=E2=80=99d have to bow out of a breakfast meeting to make it. > >> > >> Jet lag, it=E2=80=99s a hell of a drug. > >> > >> Short notice, I know, but would people be available for an authors=E2= =80=99 > meeting / editing session tomorrow (Thursday) over lunch? The idea is to > bring food and meet in the IESG room (Mirja has offered to reserve it to > us); if we can make good progress there, then we=E2=80=99re done. if not,= I still > have the Friday IAB room reservation. > > > > Works fine for me > > > > > >> In either case the plan is to sit down and write, discussing suggested > text and merging PRs to take advantage of higher bandwidth of everyone > being here. > >> > >> Thanks, cheers, and apologies for the organizational skill, > >> > >> Brian > >> > >> > >> > >>> On 19 Nov 2019, at 18:46, Brian Trammell (IETF) > wrote: > >>> > >>> Greetings, all, > >>> > >>> We'll have a TAPS author's meeting (laptops open, writing PRs) from > 8:30 - 10:00 on Friday in the VIP B room at the venue (across from the > Olivia / Sophia rooms, since the signage is suboptimal). > >>> > >>> Cheers, > >>> > >>> Brian > >> > >> _______________________________________________ > >> Taps mailing list > >> Taps@ietf.org > >> https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > --000000000000b5975a0597d0a72c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Does the IESG room have another name for routing pur= poses?

On Thu, Nov 21, 2019 at 8:46 AM Brian Trammell (IETF) <= ietf@trammell.ch> wrote:
...and we've confirmed the IESG room r= eservation over lunchtime. It seems at least Michael and I will be there, p= lease join if you can and we can all close some issues together.

Cheers,

Brian

> On 20 Nov 2019, at 23:34, Michael Welzl <michawe@ifi.uio.no> wrote:
>
>> On Nov 20, 2019, at 11:15 PM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:=
>>
>> Greetings, all
>>
>> The Friday time, it turns out, is less than ideal; I=E2=80=99ll ha= ve trouble showing up early enough to be useful and at least one other=C2= =A0 author told me they=E2=80=99d have to bow out of a breakfast meeting to= make it.
>>
>> Jet lag, it=E2=80=99s a hell of a drug.
>>
>> Short notice, I know, but would people be available for an authors= =E2=80=99 meeting / editing session tomorrow (Thursday) over lunch? The ide= a is to bring food and meet in the IESG room (Mirja has offered to reserve = it to us); if we can make good progress there, then we=E2=80=99re done. if = not, I still have the Friday IAB room reservation.
>
> Works fine for me
>
>
>> In either case the plan is to sit down and write, discussing sugge= sted text and merging PRs to take advantage of higher bandwidth of everyone= being here.
>>
>> Thanks, cheers, and apologies for the organizational skill,
>>
>> Brian
>>
>>
>>
>>> On 19 Nov 2019, at 18:46, Brian Trammell (IETF) <ietf@trammell.ch> wrote:=
>>>
>>> Greetings, all,
>>>
>>> We'll have a TAPS author's meeting (laptops open, writ= ing PRs) from 8:30 - 10:00 on Friday in the VIP B room at the venue (across= from the Olivia / Sophia rooms, since the signage is suboptimal).
>>>
>>> Cheers,
>>>
>>> Brian
>>
>> _______________________________________________
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
--000000000000b5975a0597d0a72c-- From nobody Wed Nov 20 17:50:14 2019 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 D0CAC12012E for ; Wed, 20 Nov 2019 17:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 6SFuBcV1qFPX for ; Wed, 20 Nov 2019 17:50:09 -0800 (PST) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (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 8801912010F for ; Wed, 20 Nov 2019 17:50:09 -0800 (PST) Received: from smtp-3-0001.mail.infomaniak.ch ([10.4.36.108]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id xAL1o7SN016916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 Nov 2019 02:50:07 +0100 Received: from dhcp-98a4.meeting.ietf.org (unknown [31.133.152.164]) by smtp-3-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 1DD3F100D1068; Thu, 21 Nov 2019 02:50:05 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Brian Trammell (IETF)" In-Reply-To: <10652F90-512E-4119-9CEC-64302443D96D@trammell.ch> Date: Thu, 21 Nov 2019 09:50:03 +0800 Cc: "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <8A8FE49C-39CA-42CC-86EA-8B07BC5C3F01@trammell.ch> <10652F90-512E-4119-9CEC-64302443D96D@trammell.ch> To: Michael Welzl X-Mailer: Apple Mail (2.3445.104.11) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Taps] Authors' meeting, Thursday 12:00 - 13:30 in Clark (IESG room, near the terminal room) 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, 21 Nov 2019 01:50:13 -0000 Now with a better subject line, including coordinates. > On 21 Nov 2019, at 08:46, Brian Trammell (IETF) = wrote: >=20 > ...and we've confirmed the IESG room reservation over lunchtime. It = seems at least Michael and I will be there, please join if you can and = we can all close some issues together. >=20 > Cheers, >=20 > Brian >=20 >> On 20 Nov 2019, at 23:34, Michael Welzl wrote: >>=20 >>> On Nov 20, 2019, at 11:15 PM, Brian Trammell (IETF) = wrote: >>>=20 >>> Greetings, all >>>=20 >>> The Friday time, it turns out, is less than ideal; I=E2=80=99ll have = trouble showing up early enough to be useful and at least one other = author told me they=E2=80=99d have to bow out of a breakfast meeting to = make it. >>>=20 >>> Jet lag, it=E2=80=99s a hell of a drug. >>>=20 >>> Short notice, I know, but would people be available for an = authors=E2=80=99 meeting / editing session tomorrow (Thursday) over = lunch? The idea is to bring food and meet in the IESG room (Mirja has = offered to reserve it to us); if we can make good progress there, then = we=E2=80=99re done. if not, I still have the Friday IAB room = reservation. >>=20 >> Works fine for me >>=20 >>=20 >>> In either case the plan is to sit down and write, discussing = suggested text and merging PRs to take advantage of higher bandwidth of = everyone being here. >>>=20 >>> Thanks, cheers, and apologies for the organizational skill, >>>=20 >>> Brian=20 >>>=20 >>>=20 >>>=20 >>>> On 19 Nov 2019, at 18:46, Brian Trammell (IETF) = wrote: >>>>=20 >>>> Greetings, all, >>>>=20 >>>> We'll have a TAPS author's meeting (laptops open, writing PRs) from = 8:30 - 10:00 on Friday in the VIP B room at the venue (across from the = Olivia / Sophia rooms, since the signage is suboptimal). >>>>=20 >>>> Cheers, >>>>=20 >>>> Brian >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps >=20 From nobody Wed Nov 20 18:23:05 2019 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 D0B901208AA for ; Wed, 20 Nov 2019 18:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Iy5njITQvvnT for ; Wed, 20 Nov 2019 18:23:01 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2: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 95536120077 for ; Wed, 20 Nov 2019 18:23:01 -0800 (PST) Received: from [31.133.155.18] (port=65234 helo=dhcp-9b12.meeting.ietf.org) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iXc7W-0005lu-PG; Thu, 21 Nov 2019 02:22:59 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Colin Perkins In-Reply-To: Date: Thu, 21 Nov 2019 10:22:50 +0800 Cc: Michael Welzl , "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0636FCB5-9CED-4930-9021-91168388F384@csperkins.org> References: <8A8FE49C-39CA-42CC-86EA-8B07BC5C3F01@trammell.ch> <10652F90-512E-4119-9CEC-64302443D96D@trammell.ch> To: Brian Trammell X-Mailer: Apple Mail (2.3445.104.11) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Taps] Authors' meeting, Thursday 12:00 - 13:30 in Clark (IESG room, near the terminal room) 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, 21 Nov 2019 02:23:04 -0000 Sorry, I=E2=80=99m confused =E2=80=93 is this moving to lunch today, = rather than tomorrow morning? Colin > On 21 Nov 2019, at 09:50, Brian Trammell (IETF) = wrote: >=20 > Now with a better subject line, including coordinates. >=20 >> On 21 Nov 2019, at 08:46, Brian Trammell (IETF) = wrote: >>=20 >> ...and we've confirmed the IESG room reservation over lunchtime. It = seems at least Michael and I will be there, please join if you can and = we can all close some issues together. >>=20 >> Cheers, >>=20 >> Brian >>=20 >>> On 20 Nov 2019, at 23:34, Michael Welzl wrote: >>>=20 >>>> On Nov 20, 2019, at 11:15 PM, Brian Trammell (IETF) = wrote: >>>>=20 >>>> Greetings, all >>>>=20 >>>> The Friday time, it turns out, is less than ideal; I=E2=80=99ll = have trouble showing up early enough to be useful and at least one other = author told me they=E2=80=99d have to bow out of a breakfast meeting to = make it. >>>>=20 >>>> Jet lag, it=E2=80=99s a hell of a drug. >>>>=20 >>>> Short notice, I know, but would people be available for an = authors=E2=80=99 meeting / editing session tomorrow (Thursday) over = lunch? The idea is to bring food and meet in the IESG room (Mirja has = offered to reserve it to us); if we can make good progress there, then = we=E2=80=99re done. if not, I still have the Friday IAB room = reservation. >>>=20 >>> Works fine for me >>>=20 >>>=20 >>>> In either case the plan is to sit down and write, discussing = suggested text and merging PRs to take advantage of higher bandwidth of = everyone being here. >>>>=20 >>>> Thanks, cheers, and apologies for the organizational skill, >>>>=20 >>>> Brian=20 >>>>=20 >>>>=20 >>>>=20 >>>>> On 19 Nov 2019, at 18:46, Brian Trammell (IETF) = wrote: >>>>>=20 >>>>> Greetings, all, >>>>>=20 >>>>> We'll have a TAPS author's meeting (laptops open, writing PRs) = from 8:30 - 10:00 on Friday in the VIP B room at the venue (across from = the Olivia / Sophia rooms, since the signage is suboptimal). >>>>>=20 >>>>> Cheers, >>>>>=20 >>>>> Brian >>>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >>=20 >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --=20 Colin Perkins https://csperkins.org/ From nobody Wed Nov 20 18:24:04 2019 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 3C9CD1208AA for ; Wed, 20 Nov 2019 18:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 4nk8uVRyAGqt for ; Wed, 20 Nov 2019 18:24:01 -0800 (PST) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 8157A120077 for ; Wed, 20 Nov 2019 18:24:00 -0800 (PST) Received: by mail-pg1-x52c.google.com with SMTP id q17so754366pgt.9 for ; Wed, 20 Nov 2019 18:24:00 -0800 (PST) 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; bh=F3MbXz3rxe7ahSjLCMrkA/ARpP5Y/FPKPRq79EiVZU0=; b=EU3aNj9G7BCsrgrkIuEzfR7DGbmfH/Stb8a3sO0nj8jy8hcNYhoNpaV6y4ea0aNG9s jKhWcUZtcUE33Z5E86ZX3YqXke11X+7HWm+5j3K6g3OGxKQ/VWlBZqiWQYx7X1TZ+dn/ R+pIfxk0RSLQ8nZ0c64cq8wsIxLxNcgNzm1tDy/hrO4Gi05lIcN0ZUTaO7DcSKuwIR4F e4+l5QRi9UX7bU7zeXsHBc6GkUHNYapLUQKgvaKQ5q97lBH2JfcAHMPckefyxZG1CzAB DbQBZWoZeOrFwnqs/g+TCXfHXM/5VGo7FfMTUN2EIFo0OFPp9uq5UGCRtKyZNrxpurDv tK4Q== 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; bh=F3MbXz3rxe7ahSjLCMrkA/ARpP5Y/FPKPRq79EiVZU0=; b=Hd5gU9yFFbWUE4D3jYp6WHK7zibFjuSbu9gmt1rPAwTEv1RElmMClI8lW+L53BGOtf nWkhzpMXEnoOKSrcGoaFjzqBqCJVtq0jq3JPdct3kAHUZgZgGH0oC1L/nR53aDSrqZ+H twnIb77OO8XQWOInfOMBt7wYQL5L0UeIZADDWfgIAI+wbbAhGfFedvCxp30usB0Muywf 9jWlQg6aHiqFfLgXCLoOXIQUpnBplw3lb0oPMkKRWYiYqeIv1Tnde+SFAKhhHD10ugtA PoR1XX77aIIBbDJruKOffFNQXCWSkgvc5QsUgQMBjm4V5Y4fhXjJntrUj2OTbmb/X17c cQSg== X-Gm-Message-State: APjAAAVQq/8u6A3YfvHkLHeP/ZOtnErHkwWC3okBYcK3K7YD3mk9jhqY DoztonJYJwRGNAGSFyFc7Q0= X-Google-Smtp-Source: APXvYqzgoxbS6HRjaV0cbZLgGiDRjvxST4b+aXFYZa9G3pRFRjQXflLUS2635qqrMePDufWEQ3R+yw== X-Received: by 2002:a62:e818:: with SMTP id c24mr7817010pfi.125.1574303039706; Wed, 20 Nov 2019 18:23:59 -0800 (PST) Received: from [172.19.216.177] ([2001:67c:370:128:6818:7df3:f4f5:b8ef]) by smtp.gmail.com with ESMTPSA id x190sm759537pfc.89.2019.11.20.18.23.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Nov 2019 18:23:59 -0800 (PST) From: "Aaron Falk" To: "Colin Perkins" Cc: "Brian Trammell" , "Michael Welzl" , taps@ietf.org Date: Thu, 21 Nov 2019 10:23:54 +0800 X-Mailer: MailMate (1.13r5655) Message-ID: In-Reply-To: <0636FCB5-9CED-4930-9021-91168388F384@csperkins.org> References: <8A8FE49C-39CA-42CC-86EA-8B07BC5C3F01@trammell.ch> <10652F90-512E-4119-9CEC-64302443D96D@trammell.ch> <0636FCB5-9CED-4930-9021-91168388F384@csperkins.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_4E42843C-0C95-4959-B42B-1F3AB032A5C9_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Taps] Authors' meeting, Thursday 12:00 - 13:30 in Clark (IESG room, near the terminal room) 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, 21 Nov 2019 02:24:03 -0000 --=_MailMate_4E42843C-0C95-4959-B42B-1F3AB032A5C9_= Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit I believe so, Colin. Tomorrow AM is a backup for add’l time. I plan to attend at lunch. --aaron On 21 Nov 2019, at 10:22, Colin Perkins wrote: > Sorry, I’m confused – is this moving to lunch today, rather than > tomorrow morning? > Colin > > > >> On 21 Nov 2019, at 09:50, Brian Trammell (IETF) >> wrote: >> >> Now with a better subject line, including coordinates. >> >>> On 21 Nov 2019, at 08:46, Brian Trammell (IETF) >>> wrote: >>> >>> ...and we've confirmed the IESG room reservation over lunchtime. It >>> seems at least Michael and I will be there, please join if you can >>> and we can all close some issues together. >>> >>> Cheers, >>> >>> Brian >>> >>>> On 20 Nov 2019, at 23:34, Michael Welzl wrote: >>>> >>>>> On Nov 20, 2019, at 11:15 PM, Brian Trammell (IETF) >>>>> wrote: >>>>> >>>>> Greetings, all >>>>> >>>>> The Friday time, it turns out, is less than ideal; I’ll have >>>>> trouble showing up early enough to be useful and at least one >>>>> other author told me they’d have to bow out of a breakfast >>>>> meeting to make it. >>>>> >>>>> Jet lag, it’s a hell of a drug. >>>>> >>>>> Short notice, I know, but would people be available for an >>>>> authors’ meeting / editing session tomorrow (Thursday) over >>>>> lunch? The idea is to bring food and meet in the IESG room (Mirja >>>>> has offered to reserve it to us); if we can make good progress >>>>> there, then we’re done. if not, I still have the Friday IAB room >>>>> reservation. >>>> >>>> Works fine for me >>>> >>>> >>>>> In either case the plan is to sit down and write, discussing >>>>> suggested text and merging PRs to take advantage of higher >>>>> bandwidth of everyone being here. >>>>> >>>>> Thanks, cheers, and apologies for the organizational skill, >>>>> >>>>> Brian >>>>> >>>>> >>>>> >>>>>> On 19 Nov 2019, at 18:46, Brian Trammell (IETF) >>>>>> wrote: >>>>>> >>>>>> Greetings, all, >>>>>> >>>>>> We'll have a TAPS author's meeting (laptops open, writing PRs) >>>>>> from 8:30 - 10:00 on Friday in the VIP B room at the venue >>>>>> (across from the Olivia / Sophia rooms, since the signage is >>>>>> suboptimal). >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Brian >>>>> >>>>> _______________________________________________ >>>>> Taps mailing list >>>>> Taps@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/taps >>> >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>> >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > > > -- > Colin Perkins > https://csperkins.org/ > > > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --=_MailMate_4E42843C-0C95-4959-B42B-1F3AB032A5C9_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">I believe so, Colin. Tomorrow AM is a backup for add=E2=80= =99l time. I plan to attend at lunch.

--aaron

On 21 Nov 2019, at 10:22, Colin Perkins wrote:

Sorry, I=E2=80=99m confused =E2=80=93= is this moving to lunch today, rather than tomorrow morning?
Colin


On 21 Nov 2= 019, at 09:50, Brian Trammell (IETF) <ietf@trammell.ch> wrote:

Now with a better subject line, including coordinates.

On 21 Nov 2= 019, at 08:46, Brian Trammell (IETF) <ietf@trammell.ch> wrote:

=2E..and we've confirmed the IESG room reservation over lunchtime. It see= ms at least Michael and I will be there, please join if you can and we ca= n all close some issues together.

Cheers,

Brian

On 20 Nov 2= 019, at 23:34, Michael Welzl <michawe@ifi.uio.no> wrote:

On Nov 20, = 2019, at 11:15 PM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:<= br>
Greetings, all

The Friday time, it turns out, is less than ideal; I=E2=80=99ll have trou= ble showing up early enough to be useful and at least one other author t= old me they=E2=80=99d have to bow out of a breakfast meeting to make it.<= br>
Jet lag, it=E2=80=99s a hell of a drug.

Short notice, I know, but would people be available for an authors=E2=80=99= meeting / editing session tomorrow (Thursday) over lunch? The idea is to= bring food and meet in the IESG room (Mirja has offered to reserve it to= us); if we can make good progress there, then we=E2=80=99re done. if not= , I still have the Friday IAB room reservation.

Works fine for me

In either c= ase the plan is to sit down and write, discussing suggested text and merg= ing PRs to take advantage of higher bandwidth of everyone being here.
=
Thanks, cheers, and apologies for the organizational skill,

Brian


On 19 Nov 2= 019, at 18:46, Brian Trammell (IETF) <ietf@trammell.ch> wrote:

Greetings, all,

We'll have a TAPS author's meeting (laptops open, writing PRs) from 8:30 = - 10:00 on Friday in the VIP B room at the venue (across from the Olivia = / Sophia rooms, since the signage is suboptimal).

Cheers,

Brian

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

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

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

--
Colin Perkins
https://csperkins= =2Eorg/




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

--=_MailMate_4E42843C-0C95-4959-B42B-1F3AB032A5C9_=-- From nobody Wed Nov 20 18:25:38 2019 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 504E112091F for ; Wed, 20 Nov 2019 18:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 uiAVzO_D4biC for ; Wed, 20 Nov 2019 18:25:35 -0800 (PST) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 D4E5812096F for ; Wed, 20 Nov 2019 18:25:34 -0800 (PST) Received: from smtp-2-0000.mail.infomaniak.ch (smtp-2-0000.mail.infomaniak.ch [10.5.36.107]) by smtp-sh2.infomaniak.ch (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id xAL2PVnk138359 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 Nov 2019 03:25:31 +0100 Received: from [IPv6:2001:67c:370:128:6d36:9372:614c:6a0c] (unknown [IPV6:2001:67c:370:128:6d36:9372:614c:6a0c]) by smtp-2-0000.mail.infomaniak.ch (Postfix) with ESMTPA id 751831009A0C7; Thu, 21 Nov 2019 03:25:30 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Brian Trammell (IETF)" In-Reply-To: <0636FCB5-9CED-4930-9021-91168388F384@csperkins.org> Date: Thu, 21 Nov 2019 10:25:27 +0800 Cc: Michael Welzl , "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <8A8FE49C-39CA-42CC-86EA-8B07BC5C3F01@trammell.ch> <10652F90-512E-4119-9CEC-64302443D96D@trammell.ch> <0636FCB5-9CED-4930-9021-91168388F384@csperkins.org> To: Colin Perkins X-Mailer: Apple Mail (2.3445.104.11) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Taps] Authors' meeting, Thursday 12:00 - 13:30 in Clark (IESG room, near the terminal room) 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, 21 Nov 2019 02:25:37 -0000 Yes, moving to lunch today; for those who cannot make lunch today, the = IAB room is still reserved for tomorrow. Tomorrow is backup for = additional time, though a few of us won't be able to make it. As with anything planned poorly and the last minute (sorry!) we're not = going to converge on getting everyone in the room, and that's OK. Let us = take "schedule enough side meeting time in Vancouver *in advance*" as a = goal for next time.=20 Cheers, Brian > On 21 Nov 2019, at 10:22, Colin Perkins wrote: >=20 > Sorry, I=E2=80=99m confused =E2=80=93 is this moving to lunch today, = rather than tomorrow morning? > Colin >=20 >=20 >=20 >> On 21 Nov 2019, at 09:50, Brian Trammell (IETF) = wrote: >>=20 >> Now with a better subject line, including coordinates. >>=20 >>> On 21 Nov 2019, at 08:46, Brian Trammell (IETF) = wrote: >>>=20 >>> ...and we've confirmed the IESG room reservation over lunchtime. It = seems at least Michael and I will be there, please join if you can and = we can all close some issues together. >>>=20 >>> Cheers, >>>=20 >>> Brian >>>=20 >>>> On 20 Nov 2019, at 23:34, Michael Welzl wrote: >>>>=20 >>>>> On Nov 20, 2019, at 11:15 PM, Brian Trammell (IETF) = wrote: >>>>>=20 >>>>> Greetings, all >>>>>=20 >>>>> The Friday time, it turns out, is less than ideal; I=E2=80=99ll = have trouble showing up early enough to be useful and at least one other = author told me they=E2=80=99d have to bow out of a breakfast meeting to = make it. >>>>>=20 >>>>> Jet lag, it=E2=80=99s a hell of a drug. >>>>>=20 >>>>> Short notice, I know, but would people be available for an = authors=E2=80=99 meeting / editing session tomorrow (Thursday) over = lunch? The idea is to bring food and meet in the IESG room (Mirja has = offered to reserve it to us); if we can make good progress there, then = we=E2=80=99re done. if not, I still have the Friday IAB room = reservation. >>>>=20 >>>> Works fine for me >>>>=20 >>>>=20 >>>>> In either case the plan is to sit down and write, discussing = suggested text and merging PRs to take advantage of higher bandwidth of = everyone being here. >>>>>=20 >>>>> Thanks, cheers, and apologies for the organizational skill, >>>>>=20 >>>>> Brian=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> On 19 Nov 2019, at 18:46, Brian Trammell (IETF) = wrote: >>>>>>=20 >>>>>> Greetings, all, >>>>>>=20 >>>>>> We'll have a TAPS author's meeting (laptops open, writing PRs) = from 8:30 - 10:00 on Friday in the VIP B room at the venue (across from = the Olivia / Sophia rooms, since the signage is suboptimal). >>>>>>=20 >>>>>> Cheers, >>>>>>=20 >>>>>> Brian >>>>>=20 >>>>> _______________________________________________ >>>>> Taps mailing list >>>>> Taps@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/taps >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>>=20 >>=20 >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps >=20 >=20 >=20 > --=20 > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 >=20 From nobody Wed Nov 20 18:29:49 2019 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 AD962120840 for ; Wed, 20 Nov 2019 18:29:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 IQM3l8MZgF9q for ; Wed, 20 Nov 2019 18:29:45 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2: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 C652A120077 for ; Wed, 20 Nov 2019 18:29:45 -0800 (PST) Received: from [31.133.155.18] (port=65363 helo=dhcp-9b12.meeting.ietf.org) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1iXcE2-0006aU-Ne; Thu, 21 Nov 2019 02:29:43 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Colin Perkins In-Reply-To: Date: Thu, 21 Nov 2019 10:29:38 +0800 Cc: Michael Welzl , "taps@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <8A8FE49C-39CA-42CC-86EA-8B07BC5C3F01@trammell.ch> <10652F90-512E-4119-9CEC-64302443D96D@trammell.ch> <0636FCB5-9CED-4930-9021-91168388F384@csperkins.org> To: Brian Trammell X-Mailer: Apple Mail (2.3445.104.11) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Taps] Authors' meeting, Thursday 12:00 - 13:30 in Clark (IESG room, near the terminal room) 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, 21 Nov 2019 02:29:48 -0000 Okay =E2=80=93 in which case, my apologies but I have another meeting = and won=E2=80=99t make it. For Vancouver, it=E2=80=99d be useful if we could schedule the side = meeting much earlier=E2=80=A6=20 Colin > On 21 Nov 2019, at 10:25, Brian Trammell (IETF) = wrote: >=20 > Yes, moving to lunch today; for those who cannot make lunch today, the = IAB room is still reserved for tomorrow. Tomorrow is backup for = additional time, though a few of us won't be able to make it. >=20 > As with anything planned poorly and the last minute (sorry!) we're not = going to converge on getting everyone in the room, and that's OK. Let us = take "schedule enough side meeting time in Vancouver *in advance*" as a = goal for next time.=20 >=20 > Cheers, >=20 > Brian >=20 >> On 21 Nov 2019, at 10:22, Colin Perkins wrote: >>=20 >> Sorry, I=E2=80=99m confused =E2=80=93 is this moving to lunch today, = rather than tomorrow morning? >> Colin >>=20 >>=20 >>=20 >>> On 21 Nov 2019, at 09:50, Brian Trammell (IETF) = wrote: >>>=20 >>> Now with a better subject line, including coordinates. >>>=20 >>>> On 21 Nov 2019, at 08:46, Brian Trammell (IETF) = wrote: >>>>=20 >>>> ...and we've confirmed the IESG room reservation over lunchtime. It = seems at least Michael and I will be there, please join if you can and = we can all close some issues together. >>>>=20 >>>> Cheers, >>>>=20 >>>> Brian >>>>=20 >>>>> On 20 Nov 2019, at 23:34, Michael Welzl = wrote: >>>>>=20 >>>>>> On Nov 20, 2019, at 11:15 PM, Brian Trammell (IETF) = wrote: >>>>>>=20 >>>>>> Greetings, all >>>>>>=20 >>>>>> The Friday time, it turns out, is less than ideal; I=E2=80=99ll = have trouble showing up early enough to be useful and at least one other = author told me they=E2=80=99d have to bow out of a breakfast meeting to = make it. >>>>>>=20 >>>>>> Jet lag, it=E2=80=99s a hell of a drug. >>>>>>=20 >>>>>> Short notice, I know, but would people be available for an = authors=E2=80=99 meeting / editing session tomorrow (Thursday) over = lunch? The idea is to bring food and meet in the IESG room (Mirja has = offered to reserve it to us); if we can make good progress there, then = we=E2=80=99re done. if not, I still have the Friday IAB room = reservation. >>>>>=20 >>>>> Works fine for me >>>>>=20 >>>>>=20 >>>>>> In either case the plan is to sit down and write, discussing = suggested text and merging PRs to take advantage of higher bandwidth of = everyone being here. >>>>>>=20 >>>>>> Thanks, cheers, and apologies for the organizational skill, >>>>>>=20 >>>>>> Brian=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>> On 19 Nov 2019, at 18:46, Brian Trammell (IETF) = wrote: >>>>>>>=20 >>>>>>> Greetings, all, >>>>>>>=20 >>>>>>> We'll have a TAPS author's meeting (laptops open, writing PRs) = from 8:30 - 10:00 on Friday in the VIP B room at the venue (across from = the Olivia / Sophia rooms, since the signage is suboptimal). >>>>>>>=20 >>>>>>> Cheers, >>>>>>>=20 >>>>>>> Brian >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Taps mailing list >>>>>> Taps@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/taps >>>>=20 >>>> _______________________________________________ >>>> Taps mailing list >>>> Taps@ietf.org >>>> https://www.ietf.org/mailman/listinfo/taps >>>>=20 >>>=20 >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 >>=20 >>=20 >> --=20 >> Colin Perkins >> https://csperkins.org/ >>=20 >>=20 >>=20 >>=20 >>=20 >=20 --=20 Colin Perkins https://csperkins.org/ From nobody Thu Nov 21 17:40:39 2019 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 81D5212008F; Thu, 21 Nov 2019 17:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 9Xd6gqoYxswC; Thu, 21 Nov 2019 17:40:35 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 84D4F1200A3; Thu, 21 Nov 2019 17:40:35 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id t3so2109099pgl.5; Thu, 21 Nov 2019 17:40:35 -0800 (PST) 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 :content-transfer-encoding; bh=DfkCI2zChqwW672DcYhzGPbPnR+XGpr5eJXlLAqVINk=; b=rNw5w3mo9/k7RhBJPYxzwR04TcU/GB66O2jdvDQzM1MH5S9tqsETz6VIN0tuxvjx4x AD45O/hn0o28NSk8RBouf28++2KS84vOcjAFgvnpuKU/CvzfrUTDKg9GV3BCm7OrA9KQ Q08ky+isyRuWeV4aPSCVjdKh+WLbu4bvki2BI3F1B7wrl0CoVF4P2BypvgJFQxSt9L8b Yw2tttnb++uPEsnky8pQyTcjCTqUqEhlMxhtMk/1Nrm7YvgABVgzBpG3JZq39zk64zTf nACc8hfqKeopNkYXcQ0INVQtxLk3JzRVwcvYxhyn5EA7piwNGEEoU4HB919mGonPMbjb OhKQ== 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 :content-transfer-encoding; bh=DfkCI2zChqwW672DcYhzGPbPnR+XGpr5eJXlLAqVINk=; b=eNmFQQCqoGD2ngd76lTVRHZQ4XUI2vs6tcw/mO0ZkA8L6B3o4czphomsfhohnBuVur wVvTE+juOkKEDvKReXfdjkTO2X8xt0DdGL5r1O9OXyM5IbDDuFE/xYUGw3x57/KOEfxH y9rVa+GLDmw5fDSIcqD2H6xWaEueYShfuN0MfaCQ14Yn7p8dwGzdVB66NdWD0/wLCU9K TWMXuQ5r0jupJ3vc//3tToe0S2Ql6rie3MFDL0uMcgVg+nyl66r7+Fm5Uxw5EfZB8R2c +q1bqk6UmjpIYnYupp0X5cUcfhtE6Tth+huhSBk9bPYqErQTMrb9nNS9xpD8obktp4+2 rXPA== X-Gm-Message-State: APjAAAVfztF1MdE+Zjg8+TAVaxwzrZGl0KJQSi0caluSEyMYT3TvbSRs d+geSjoU8v5N6JHkESxhTMGzpMq4A3s= X-Google-Smtp-Source: APXvYqyehoow9Ii0ry2QDxbpB4/cFttCx+gyAYQW3UhaDogo4Su1TaxyBreANr0cUCqGkijJACT/tw== X-Received: by 2002:a63:c805:: with SMTP id z5mr13057694pgg.14.1574386834566; Thu, 21 Nov 2019 17:40:34 -0800 (PST) Received: from [172.19.216.204] (dhcp-9e51.meeting.ietf.org. [31.133.158.81]) by smtp.gmail.com with ESMTPSA id 82sm4977324pfa.115.2019.11.21.17.40.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Nov 2019 17:40:33 -0800 (PST) From: "Aaron Falk" To: "taps WG" Cc: "Zaheduzzaman Sarker" , tsv-ads@ietf.org Date: Fri, 22 Nov 2019 09:40:27 +0800 X-Mailer: MailMate (1.13r5655) Message-ID: <4386E750-2C84-4BA9-9981-71FBFACD500E@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_AAA4A047-4764-493F-AE71-ED7BA7311D24_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: [Taps] ACTION REQUIRED BEFORE NOV 26: Interim scheduling 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, 22 Nov 2019 01:40:38 -0000 --=_MailMate_AAA4A047-4764-493F-AE71-ED7BA7311D24_= Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Here are doodle polls for the interim meetings we discussed leading up to IETF-107. We’ll close the polls Tuesday, November 26. December w/o Dec 16: https://doodle.com/poll/7fctt4tvh7zzf2d3 Topics: -arch WGLC discussion, -interface WGLC prep January w/o Jan 20: https://doodle.com/poll/gwif6y5anaha4xd8 Topics: -interface WGLC discussion, -implementation WGLC prep February w/o Feb 17: https://doodle.com/poll/7733w6v9uburfbkh Topics: -implementation WGLC discussion, IETF-107 prep All calls are 11am - 1pm EDT, 8am - 10am PDT, 4pm - 6pm UTC since we span EU & US west coast. Agendas will be refined as we get closer to the call. --aaron --=_MailMate_AAA4A047-4764-493F-AE71-ED7BA7311D24_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Here are doodle polls for the interim meetings we discusse= d leading up to IETF-107. We=E2=80=99ll close the polls Tuesday, Novembe= r 26.

December w/o Dec 16: https://doodle.com/poll/7fctt4tv= h7zzf2d3
Topics: -arch WGLC discussion, -interface WGLC prep

January w/o Jan 20: https://doodle.com/poll/gwif6y5an= aha4xd8
Topics: -interface WGLC discussion, -implementation WGLC prep

February w/o Feb 17: https://doodle.com/poll/7733w6v9= uburfbkh
Topics: -implementation WGLC discussion, IETF-107 prep

All calls are 11am - 1pm EDT, 8am - 10am PDT, 4pm - 6pm U= TC since we span EU & US west coast. Agendas will be refined as we g= et closer to the call.

--aaron

--=_MailMate_AAA4A047-4764-493F-AE71-ED7BA7311D24_=-- From nobody Fri Nov 22 00:02:27 2019 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 CF7E012003E for ; Fri, 22 Nov 2019 00:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 hSh6utdSI8Lv for ; Fri, 22 Nov 2019 00:02:22 -0800 (PST) Received: from magpie.corvid.ch (magpie.corvid.ch [46.101.110.207]) (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 E6A0812000F for ; Fri, 22 Nov 2019 00:02:21 -0800 (PST) Received: from [127.0.0.1] (helo=magpie.corvid.ch) by magpie.corvid.ch with esmtp (Exim 4.92) (envelope-from ) id 1iY3rN-00056B-VM for taps@ietf.org; Fri, 22 Nov 2019 08:00:09 +0000 Content-Type: multipart/alternative; boundary="===============1064909514116117964==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 22 Nov 2019 08:00:09 +0000 Archived-At: Subject: [Taps] Weekly github digest (TAPS GitHub Activity Digest) 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, 22 Nov 2019 08:02:26 -0000 --===============1064909514116117964== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * ietf-tapswg/api-drafts (+12/-25/=F0=9F=92=AC38) 12 issues created: - Experimental cost property: cost preference (by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/384 [API] [discuss] = - Multicast impact on architecture? (by abrunstrom) https://github.com/ietf-tapswg/api-drafts/issues/382 [Architecture] = - Multiple receives convenience feature (by MaxF12) https://github.com/ietf-tapswg/api-drafts/issues/375 = - Protocols in Figure 2 (by abrunstrom) https://github.com/ietf-tapswg/api-drafts/issues/374 [Architecture] = - Transport Properties are not Connection Objects (by abrunstrom) https://github.com/ietf-tapswg/api-drafts/issues/373 = - Do we need an example for an HTTP/1, HTTP/2, HTTP/3 agnostic connection= ? (by philsbln) https://github.com/ietf-tapswg/api-drafts/issues/371 = - Implementation - PMTU text is broken (by gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/367 [Implementation] [= ready for text] = - Some editorial (I hope) comments on implementation (by gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/366 = - Architecture: Editorial comments (by theri) https://github.com/ietf-tapswg/api-drafts/issues/365 = - Update wording where interface to security protocol implies racing/abst= raction (by squarooticus) https://github.com/ietf-tapswg/api-drafts/issues/364 = - "Access to Specialized Features" example: Security protocols (by theri) https://github.com/ietf-tapswg/api-drafts/issues/363 [Architecture] = - -impl should say more about use of ALPN (by mirjak) https://github.com/ietf-tapswg/api-drafts/issues/362 [Architecture] = 21 issues received 38 new comments: - #375 Multiple receives convenience feature (6 by britram, mwelzl, phils= bln, tfpauly, MaxF12) https://github.com/ietf-tapswg/api-drafts/issues/375 [API] [discuss] = - #384 Experimental cost property: cost preference (5 by philsbln, mwelzl= , gorryfair, tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/384 [API] [discuss] = - #362 -impl should say more about use of ALPN (3 by philsbln, gorryfair,= theri) https://github.com/ietf-tapswg/api-drafts/issues/362 [Implementation] = - #363 "Access to Specialized Features" example: Security protocols (3 by= philsbln, abrunstrom, squarooticus) https://github.com/ietf-tapswg/api-drafts/issues/363 [Architecture] = - #382 Multicast impact on architecture? (3 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/382 [Architecture] = - #305 Protocol stacks that are not equivalent (2 by britram, theri) https://github.com/ietf-tapswg/api-drafts/issues/305 [Architecture] = - #374 Protocols in Figure 2 (2 by mwelzl, tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/374 [Architecture] = - #258 Do we need a terminology section in arch? (1 by britram) https://github.com/ietf-tapswg/api-drafts/issues/258 [Architecture] [di= scuss] = - #145 Draft should point at implementations somewhere (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/145 [Implementation] [= ready for text] = - #150 Add Unidirectional Streams for Multicast / Source and Sink support= (1 by MaxF12) https://github.com/ietf-tapswg/api-drafts/issues/150 [API] [Implementat= ion] [ready for text] = - #154 Structure of implementation draft (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/154 [Implementation] = - #177 Privacy considerations section (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/177 [API] [Implementat= ion] [ready for text] = - #299 TAPS ARCH - Textual review to notes (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/299 [Architecture] = - #45 Do we need to make state storage explicit in the architecture and A= PI? (1 by britram) https://github.com/ietf-tapswg/api-drafts/issues/45 [API] [Architecture= ] [ready for text] = - #312 Detailed author review of Arch text for -03 to prepare -04 (1 by t= fpauly) https://github.com/ietf-tapswg/api-drafts/issues/312 [Architecture] [re= ady for text] = - #324 Add explicit protocol selection. (1 by britram) https://github.com/ietf-tapswg/api-drafts/issues/324 [API] [ready for t= ext] = - #334 Consider message send API that takes padding policy as input (1 by= britram) https://github.com/ietf-tapswg/api-drafts/issues/334 [API] [future work= ] = - #357 Default values (1 by britram) https://github.com/ietf-tapswg/api-drafts/issues/357 [API] [discuss] [r= eady for text] = - #364 Update wording where interface to security protocol implies racing= /abstraction (1 by theri) https://github.com/ietf-tapswg/api-drafts/issues/364 = - #365 Architecture: Editorial comments (1 by britram) https://github.com/ietf-tapswg/api-drafts/issues/365 [Architecture] = - #249 API needs a way to handle "STARTTLS" (1 by britram) https://github.com/ietf-tapswg/api-drafts/issues/249 [API] [Architectur= e] [discuss] = 25 issues closed: - Experimental cost property: cost preference https://github.com/ietf-tap= swg/api-drafts/issues/384 [API] [discuss] = - Add Unidirectional Streams for Multicast / Source and Sink support htt= ps://github.com/ietf-tapswg/api-drafts/issues/150 [API] [Implementation] [r= eady for text] = - Structure of implementation draft https://github.com/ietf-tapswg/api-dr= afts/issues/154 [Implementation] = - Draft should point at implementations somewhere https://github.com/ietf= -tapswg/api-drafts/issues/145 [Implementation] [ready for text] = - Multicast impact on architecture? https://github.com/ietf-tapswg/api-dr= afts/issues/382 [Architecture] = - Architecture: Editorial comments https://github.com/ietf-tapswg/api-dra= fts/issues/365 [Architecture] [ready for text] = - Protocols in Figure 2 https://github.com/ietf-tapswg/api-drafts/issues/= 374 [Architecture] = - Add explicit protocol selection. https://github.com/ietf-tapswg/api-dra= fts/issues/324 [API] [ready for text] = - Define the server-side equivalent of racing https://github.com/ietf-tap= swg/api-drafts/issues/206 [API] [Architecture] [ready for text] = - Clarification on queued receives https://github.com/ietf-tapswg/api-dra= fts/issues/309 [API] [ready for text] = - Architecture privacy and security considerations https://github.com/iet= f-tapswg/api-drafts/issues/178 [Architecture] [ready for text] = - "Events" versus "Callbacks" for security-relevant asynchrony https://gi= thub.com/ietf-tapswg/api-drafts/issues/347 [API] [Architecture] [ready for = text] = - Add property for address privacy https://github.com/ietf-tapswg/api-dra= fts/issues/300 [API] [ready for text] = - More expressive multipath transport property https://github.com/ietf-ta= pswg/api-drafts/issues/303 [API] [ready for text] = - Consider message send API that takes padding policy as input https://gi= thub.com/ietf-tapswg/api-drafts/issues/334 [API] [future work] = - Multiple receives convenience feature https://github.com/ietf-tapswg/ap= i-drafts/issues/375 [API] [discuss] = - TAPS ARCH - Textual review to notes https://github.com/ietf-tapswg/api-= drafts/issues/299 [Architecture] = - Do we need to make state storage explicit in the architecture and API? = https://github.com/ietf-tapswg/api-drafts/issues/45 [API] [Architecture] [r= eady for text] = - Implementation should describe how to handle proxies/TOR https://github= .com/ietf-tapswg/api-drafts/issues/282 [Implementation] [discuss] [help wan= ted] = - Default values https://github.com/ietf-tapswg/api-drafts/issues/357 [AP= I] [discuss] [ready for text] = - Failure of unsatisfiable configurations https://github.com/ietf-tapswg/= api-drafts/issues/306 [API] = - Add re-initiate() call for voluntary connection migration https://gith= ub.com/ietf-tapswg/api-drafts/issues/270 [API] [future work] = - Do we need a terminology section in arch? https://github.com/ietf-tapsw= g/api-drafts/issues/258 [Architecture] [discuss] = - API needs a way to handle "STARTTLS" https://github.com/ietf-tapswg/api= -drafts/issues/249 [API] [Architecture] [discuss] = - Detailed author review of Arch text for -03 to prepare -04 https://gith= ub.com/ietf-tapswg/api-drafts/issues/312 [Architecture] [ready for text] = Pull requests ------------- * ietf-tapswg/api-drafts (+13/-11/=F0=9F=92=AC11) 13 pull requests submitted: - Editorial comments, fixes #365 (by theri) https://github.com/ietf-tapswg/api-drafts/pull/383 = - Move Transport Properties text and close #373 (by philsbln) https://github.com/ietf-tapswg/api-drafts/pull/381 = - Add clarification on Multicast receive to API (by MaxF12) https://github.com/ietf-tapswg/api-drafts/pull/380 = - TAPS allows you to dynamically choose protocol stacks, we should say so= . (by britram) https://github.com/ietf-tapswg/api-drafts/pull/379 = - closes #324 (by mwelzl) https://github.com/ietf-tapswg/api-drafts/pull/378 = - Partial receives are not reordering preferences; fix #309 (by britram) https://github.com/ietf-tapswg/api-drafts/pull/377 = - Add text for server-side "racing" (by tfpauly) https://github.com/ietf-tapswg/api-drafts/pull/376 = - Address privacy property, #300 (by tfpauly) https://github.com/ietf-tapswg/api-drafts/pull/372 = - Add multipath property enumeration (by tfpauly) https://github.com/ietf-tapswg/api-drafts/pull/370 = - add dates to references, and clean up spurious ones (by britram) https://github.com/ietf-tapswg/api-drafts/pull/369 = - be explicit and careful about callbacks vs events; fix #347 (by britram) https://github.com/ietf-tapswg/api-drafts/pull/368 = - fixes for a few nits (by GrumpyOldTroll) https://github.com/ietf-tapswg/api-drafts/pull/361 = - udp multicast receive (#150) (by GrumpyOldTroll) https://github.com/ietf-tapswg/api-drafts/pull/360 = 3 pull requests received 11 new comments: - #360 udp multicast receive (#150) (9 by MaxF12, philsbln, mwelzl, theri) https://github.com/ietf-tapswg/api-drafts/pull/360 = - #378 closes #324 (1 by britram) https://github.com/ietf-tapswg/api-drafts/pull/378 = - #380 Add clarification on Multicast receive to API (1 by philsbln) https://github.com/ietf-tapswg/api-drafts/pull/380 = 11 pull requests merged: - Add clarification on Multicast receive to API https://github.com/ietf-tapswg/api-drafts/pull/380 = - Editorial comments, fixes #365 https://github.com/ietf-tapswg/api-drafts/pull/383 = - TAPS allows you to dynamically choose protocol stacks, we should say so. https://github.com/ietf-tapswg/api-drafts/pull/379 = - Add text for server-side "racing" https://github.com/ietf-tapswg/api-drafts/pull/376 = - Partial receives are not reordering preferences; fix #309 https://github.com/ietf-tapswg/api-drafts/pull/377 = - be explicit and careful about callbacks vs events; fix #347 https://github.com/ietf-tapswg/api-drafts/pull/368 = - Add multipath property enumeration https://github.com/ietf-tapswg/api-drafts/pull/370 = - Address privacy property, #300 https://github.com/ietf-tapswg/api-drafts/pull/372 = - add dates to references, and clean up spurious ones https://github.com/ietf-tapswg/api-drafts/pull/369 = - udp multicast receive (#150) https://github.com/ietf-tapswg/api-drafts/pull/360 = - fixes for a few nits https://github.com/ietf-tapswg/api-drafts/pull/361 = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============1064909514116117964== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday November 22, 2019

Issues

ietf-tapswg/api-drafts (+12/-25/=F0=9F=92=AC38)

12 issues created:

21 issues received 38 new comments:

25 issues closed:

Pull requests

ietf-tapswg/api-drafts (+13/-11/=F0=9F=92=AC11)

13 pull requests submitted:

3 pull requests received 11 new comments:

11 pull requests merged:

Repositories tracked by this digest:

--===============1064909514116117964==-- From nobody Fri Nov 22 00:04:44 2019 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 F162A12003E for ; Fri, 22 Nov 2019 00:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 KfvgcIrVEqFX for ; Fri, 22 Nov 2019 00:04:40 -0800 (PST) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 E471912000F for ; Fri, 22 Nov 2019 00:04:39 -0800 (PST) Received: from smtp-2-0000.mail.infomaniak.ch (smtp-2-0000.mail.infomaniak.ch [10.5.36.107]) by smtp-sh2.infomaniak.ch (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id xAM84bFA076666 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 22 Nov 2019 09:04:37 +0100 Received: from dhcp-9a1c.meeting.ietf.org (unknown [31.133.154.28]) by smtp-2-0000.mail.infomaniak.ch (Postfix) with ESMTPA id 3E925101E04DB for ; Fri, 22 Nov 2019 09:04:35 +0100 (CET) From: "Brian Trammell (IETF)" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 22 Nov 2019 16:04:33 +0800 References: To: taps WG In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.11) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Taps] Weekly github digest (TAPS GitHub Activity Digest) 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, 22 Nov 2019 08:04:43 -0000 Wow! The robot can write long messages, too. Good work, everyone! Cheers, Brian > On 22 Nov 2019, at 16:00, TAPS WG status robot = wrote: >=20 > Friday November 22, 2019 >=20 > Issues >=20 > ietf-tapswg/api-drafts (+12/-25/=F0=9F=92=AC38) > 12 issues created: >=20 > =E2=80=A2 #384 Experimental cost property: cost preference (by = mwelzl) API discuss > =E2=80=A2 #382 Multicast impact on architecture? (by abrunstrom) = Architecture > =E2=80=A2 #375 Multiple receives convenience feature (by MaxF12)=20= > =E2=80=A2 #374 Protocols in Figure 2 (by abrunstrom) = Architecture > =E2=80=A2 #373 Transport Properties are not Connection Objects = (by abrunstrom)=20 > =E2=80=A2 #371 Do we need an example for an HTTP/1, HTTP/2, = HTTP/3 agnostic connection? (by philsbln)=20 > =E2=80=A2 #367 Implementation - PMTU text is broken (by = gorryfair) Implementation ready for text > =E2=80=A2 #366 Some editorial (I hope) comments on = implementation (by gorryfair)=20 > =E2=80=A2 #365 Architecture: Editorial comments (by theri)=20 > =E2=80=A2 #364 Update wording where interface to security = protocol implies racing/abstraction (by squarooticus)=20 > =E2=80=A2 #363 "Access to Specialized Features" example: = Security protocols (by theri) Architecture > =E2=80=A2 #362 -impl should say more about use of ALPN (by = mirjak) Architecture > 21 issues received 38 new comments: >=20 > =E2=80=A2 #375 Multiple receives convenience feature (6 by = britram, mwelzl, philsbln, tfpauly, MaxF12) API discuss > =E2=80=A2 #384 Experimental cost property: cost preference (5 by = philsbln, mwelzl, gorryfair, tfpauly) API discuss > =E2=80=A2 #362 -impl should say more about use of ALPN (3 by = philsbln, gorryfair, theri) Implementation > =E2=80=A2 #363 "Access to Specialized Features" example: = Security protocols (3 by philsbln, abrunstrom, squarooticus) = Architecture > =E2=80=A2 #382 Multicast impact on architecture? (3 by tfpauly) = Architecture > =E2=80=A2 #305 Protocol stacks that are not equivalent (2 by = britram, theri) Architecture > =E2=80=A2 #374 Protocols in Figure 2 (2 by mwelzl, tfpauly) = Architecture > =E2=80=A2 #258 Do we need a terminology section in arch? (1 by = britram) Architecture discuss > =E2=80=A2 #145 Draft should point at implementations somewhere = (1 by tfpauly) Implementation ready for text > =E2=80=A2 #150 Add Unidirectional Streams for Multicast / Source = and Sink support (1 by MaxF12) API Implementation ready for text > =E2=80=A2 #154 Structure of implementation draft (1 by tfpauly) = Implementation > =E2=80=A2 #177 Privacy considerations section (1 by tfpauly) API = Implementation ready for text > =E2=80=A2 #299 TAPS ARCH - Textual review to notes (1 by = tfpauly) Architecture > =E2=80=A2 #45 Do we need to make state storage explicit in the = architecture and API? (1 by britram) API Architecture ready for text > =E2=80=A2 #312 Detailed author review of Arch text for -03 to = prepare -04 (1 by tfpauly) Architecture ready for text > =E2=80=A2 #324 Add explicit protocol selection. (1 by britram) = API ready for text > =E2=80=A2 #334 Consider message send API that takes padding = policy as input (1 by britram) API future work > =E2=80=A2 #357 Default values (1 by britram) API discuss ready = for text > =E2=80=A2 #364 Update wording where interface to security = protocol implies racing/abstraction (1 by theri)=20 > =E2=80=A2 #365 Architecture: Editorial comments (1 by britram) = Architecture > =E2=80=A2 #249 API needs a way to handle "STARTTLS" (1 by = britram) API Architecture discuss > 25 issues closed: >=20 > =E2=80=A2 #384 Experimental cost property: cost preference API = discuss > =E2=80=A2 #150 Add Unidirectional Streams for Multicast / Source = and Sink support API Implementation ready for text > =E2=80=A2 #154 Structure of implementation draft Implementation > =E2=80=A2 #145 Draft should point at implementations somewhere = Implementation ready for text > =E2=80=A2 #382 Multicast impact on architecture? Architecture > =E2=80=A2 #365 Architecture: Editorial comments Architecture = ready for text > =E2=80=A2 #374 Protocols in Figure 2 Architecture > =E2=80=A2 #324 Add explicit protocol selection. API ready for = text > =E2=80=A2 #206 Define the server-side equivalent of racing API = Architecture ready for text > =E2=80=A2 #309 Clarification on queued receives API ready for = text > =E2=80=A2 #178 Architecture privacy and security considerations = Architecture ready for text > =E2=80=A2 #347 "Events" versus "Callbacks" for security-relevant = asynchrony API Architecture ready for text > =E2=80=A2 #300 Add property for address privacy API ready for = text > =E2=80=A2 #303 More expressive multipath transport property API = ready for text > =E2=80=A2 #334 Consider message send API that takes padding = policy as input API future work > =E2=80=A2 #375 Multiple receives convenience feature API discuss > =E2=80=A2 #299 TAPS ARCH - Textual review to notes Architecture > =E2=80=A2 #45 Do we need to make state storage explicit in the = architecture and API? API Architecture ready for text > =E2=80=A2 #282 Implementation should describe how to handle = proxies/TOR Implementation discuss help wanted > =E2=80=A2 #357 Default values API discuss ready for text > =E2=80=A2 #306 Failure of unsatisfiable configurations API > =E2=80=A2 #270 Add re-initiate() call for voluntary connection = migration API future work > =E2=80=A2 #258 Do we need a terminology section in arch? = Architecture discuss > =E2=80=A2 #249 API needs a way to handle "STARTTLS" API = Architecture discuss > =E2=80=A2 #312 Detailed author review of Arch text for -03 to = prepare -04 Architecture ready for text > Pull requests >=20 > ietf-tapswg/api-drafts (+13/-11/=F0=9F=92=AC11) > 13 pull requests submitted: >=20 > =E2=80=A2 #383 Editorial comments, fixes #365 (by theri)=20 > =E2=80=A2 #381 Move Transport Properties text and close #373 (by = philsbln)=20 > =E2=80=A2 #380 Add clarification on Multicast receive to API (by = MaxF12)=20 > =E2=80=A2 #379 TAPS allows you to dynamically choose protocol = stacks, we should say so. (by britram)=20 > =E2=80=A2 #378 closes #324 (by mwelzl)=20 > =E2=80=A2 #377 Partial receives are not reordering preferences; = fix #309 (by britram)=20 > =E2=80=A2 #376 Add text for server-side "racing" (by tfpauly)=20 > =E2=80=A2 #372 Address privacy property, #300 (by tfpauly)=20 > =E2=80=A2 #370 Add multipath property enumeration (by tfpauly)=20= > =E2=80=A2 #369 add dates to references, and clean up spurious = ones (by britram)=20 > =E2=80=A2 #368 be explicit and careful about callbacks vs = events; fix #347 (by britram)=20 > =E2=80=A2 #361 fixes for a few nits (by GrumpyOldTroll)=20 > =E2=80=A2 #360 udp multicast receive (#150) (by GrumpyOldTroll)=20= > 3 pull requests received 11 new comments: >=20 > =E2=80=A2 #360 udp multicast receive (#150) (9 by MaxF12, = philsbln, mwelzl, theri)=20 > =E2=80=A2 #378 closes #324 (1 by britram)=20 > =E2=80=A2 #380 Add clarification on Multicast receive to API (1 = by philsbln)=20 > 11 pull requests merged: >=20 > =E2=80=A2 #380 Add clarification on Multicast receive to API > =E2=80=A2 #383 Editorial comments, fixes #365 > =E2=80=A2 #379 TAPS allows you to dynamically choose protocol = stacks, we should say so. > =E2=80=A2 #376 Add text for server-side "racing" > =E2=80=A2 #377 Partial receives are not reordering preferences; = fix #309 > =E2=80=A2 #368 be explicit and careful about callbacks vs = events; fix #347 > =E2=80=A2 #370 Add multipath property enumeration > =E2=80=A2 #372 Address privacy property, #300 > =E2=80=A2 #369 add dates to references, and clean up spurious = ones > =E2=80=A2 #360 udp multicast receive (#150) > =E2=80=A2 #361 fixes for a few nits > Repositories tracked by this digest: >=20 > =E2=80=A2 https://github.com/ietf-tapswg/api-drafts > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Fri Nov 22 00:07:14 2019 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 50AF412004A for ; Fri, 22 Nov 2019 00:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 sAQbKoGZJ8qo for ; Fri, 22 Nov 2019 00:07:10 -0800 (PST) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 1AE1E12003E for ; Fri, 22 Nov 2019 00:07:10 -0800 (PST) Received: by mail-pl1-x635.google.com with SMTP id ay6so2819605plb.0 for ; Fri, 22 Nov 2019 00:07:10 -0800 (PST) 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=Re4q3UrYr+c5vUV+B+WwpMObT0nCC73Xh/zz8PthXWg=; b=IUCXviwmso6J0HF8RpMo0kVp7rQE4BPhh8SAxmHQS5Ou8AB9nob0ni53QmLhnBPiQK +e0sHwYCM9oHR+/sKBoVXuN+eTKQKAwJO4omu/jqM5t4dH3NMX2Yy+1UEW2cCm0o3uer VjVTCahSO+sFFpTJDkFN5hYt2rbc2Qc3ivbpfvpGbnbwCZvQM0zguSgGqOnZhKgaazao QGTdRc7gPhvuZ4wWf+PmzLutl2bOLSMd2VrWht5dlKC8m7j5Pc71q1KzUR35TOds8GqI erLs0YewKBzaS1BvXf083ayaETRqahmcpnMQ4zDMslZvDsoW90k/rq756VfGmSYkl0Ad o9pg== 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=Re4q3UrYr+c5vUV+B+WwpMObT0nCC73Xh/zz8PthXWg=; b=Zo4qHqpUYmhUqWwFNBFImaArhPCBMtXO7YfFe+8dwL0IUOcmu8FqpCJAdHPyk4bSOf 4/YIaTMbKUI8NqhHv8zg+dgzuoIVBKo0TZD05mZIRZuDn6xZeZHYG7F1wFt/WEDU7f8j tvp8TvtYxdgtU4cqbSRhaltikdoZr25lVuMz+pVdjrmETrko1SpDDBY82bF1EgB30hIm mrFDAzPbFqJb0MPmuYVjXg3NTZ2dSNFEv0a02lQLUKbAEw1AI8O0/PyEe2iEjqSSWx56 XlrX+GHj4t7NE1EjZ+F3nMB6E+bcixg+p3c0hsNbGIbwxdvGChfiae/7CqO4HAPBXRZL MhNQ== X-Gm-Message-State: APjAAAURr3oyWfxsxt/JS2J9HBm3jAqw/f63RzyGbXGu5hUNPpHn+ipT ijF3fdhPzgeJAhmEC5Qtsm9rqrM4FbsoLWTJzMkj74oW X-Google-Smtp-Source: APXvYqwh6634/cFdwUJZxKdSj6BoixRLu9oEkVTrE2elQoliibse7WQK4J1tlD0Ac0JXhVJoBIASGXMTeq5upOp9T3U= X-Received: by 2002:a17:90a:a45:: with SMTP id o63mr17208131pjo.45.1574410028953; Fri, 22 Nov 2019 00:07:08 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Aaron Falk Date: Fri, 22 Nov 2019 16:06:57 +0800 Message-ID: To: "Brian Trammell (IETF)" Cc: taps WG Content-Type: multipart/alternative; boundary="00000000000081b7f00597eae6cd" Archived-At: Subject: Re: [Taps] Weekly github digest (TAPS GitHub Activity Digest) 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, 22 Nov 2019 08:07:12 -0000 --00000000000081b7f00597eae6cd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, indeed. This is awesome. Brian, do you think you can create a last cal-able version of -arch by the 1st week of December? On Fri, Nov 22, 2019 at 4:04 PM Brian Trammell (IETF) wrote: > Wow! The robot can write long messages, too. Good work, everyone! > > Cheers, > > Brian > > > On 22 Nov 2019, at 16:00, TAPS WG status robot > wrote: > > > > Friday November 22, 2019 > > > > Issues > > > > ietf-tapswg/api-drafts (+12/-25/=F0=9F=92=AC38) > > 12 issues created: > > > > =E2=80=A2 #384 Experimental cost property: cost preference (by mw= elzl) API > discuss > > =E2=80=A2 #382 Multicast impact on architecture? (by abrunstrom) > Architecture > > =E2=80=A2 #375 Multiple receives convenience feature (by MaxF12) > > =E2=80=A2 #374 Protocols in Figure 2 (by abrunstrom) Architecture > > =E2=80=A2 #373 Transport Properties are not Connection Objects (b= y > abrunstrom) > > =E2=80=A2 #371 Do we need an example for an HTTP/1, HTTP/2, HTTP/= 3 > agnostic connection? (by philsbln) > > =E2=80=A2 #367 Implementation - PMTU text is broken (by gorryfair= ) > Implementation ready for text > > =E2=80=A2 #366 Some editorial (I hope) comments on implementation= (by > gorryfair) > > =E2=80=A2 #365 Architecture: Editorial comments (by theri) > > =E2=80=A2 #364 Update wording where interface to security protoco= l implies > racing/abstraction (by squarooticus) > > =E2=80=A2 #363 "Access to Specialized Features" example: Security > protocols (by theri) Architecture > > =E2=80=A2 #362 -impl should say more about use of ALPN (by mirjak= ) > Architecture > > 21 issues received 38 new comments: > > > > =E2=80=A2 #375 Multiple receives convenience feature (6 by britra= m, > mwelzl, philsbln, tfpauly, MaxF12) API discuss > > =E2=80=A2 #384 Experimental cost property: cost preference (5 by = philsbln, > mwelzl, gorryfair, tfpauly) API discuss > > =E2=80=A2 #362 -impl should say more about use of ALPN (3 by phil= sbln, > gorryfair, theri) Implementation > > =E2=80=A2 #363 "Access to Specialized Features" example: Security > protocols (3 by philsbln, abrunstrom, squarooticus) Architecture > > =E2=80=A2 #382 Multicast impact on architecture? (3 by tfpauly) > Architecture > > =E2=80=A2 #305 Protocol stacks that are not equivalent (2 by brit= ram, > theri) Architecture > > =E2=80=A2 #374 Protocols in Figure 2 (2 by mwelzl, tfpauly) Archi= tecture > > =E2=80=A2 #258 Do we need a terminology section in arch? (1 by br= itram) > Architecture discuss > > =E2=80=A2 #145 Draft should point at implementations somewhere (1= by > tfpauly) Implementation ready for text > > =E2=80=A2 #150 Add Unidirectional Streams for Multicast / Source = and Sink > support (1 by MaxF12) API Implementation ready for text > > =E2=80=A2 #154 Structure of implementation draft (1 by tfpauly) > Implementation > > =E2=80=A2 #177 Privacy considerations section (1 by tfpauly) API > Implementation ready for text > > =E2=80=A2 #299 TAPS ARCH - Textual review to notes (1 by tfpauly) > Architecture > > =E2=80=A2 #45 Do we need to make state storage explicit in the > architecture and API? (1 by britram) API Architecture ready for text > > =E2=80=A2 #312 Detailed author review of Arch text for -03 to pre= pare -04 > (1 by tfpauly) Architecture ready for text > > =E2=80=A2 #324 Add explicit protocol selection. (1 by britram) AP= I ready > for text > > =E2=80=A2 #334 Consider message send API that takes padding polic= y as > input (1 by britram) API future work > > =E2=80=A2 #357 Default values (1 by britram) API discuss ready fo= r text > > =E2=80=A2 #364 Update wording where interface to security protoco= l implies > racing/abstraction (1 by theri) > > =E2=80=A2 #365 Architecture: Editorial comments (1 by britram) Ar= chitecture > > =E2=80=A2 #249 API needs a way to handle "STARTTLS" (1 by britram= ) API > Architecture discuss > > 25 issues closed: > > > > =E2=80=A2 #384 Experimental cost property: cost preference API di= scuss > > =E2=80=A2 #150 Add Unidirectional Streams for Multicast / Source = and Sink > support API Implementation ready for text > > =E2=80=A2 #154 Structure of implementation draft Implementation > > =E2=80=A2 #145 Draft should point at implementations somewhere > Implementation ready for text > > =E2=80=A2 #382 Multicast impact on architecture? Architecture > > =E2=80=A2 #365 Architecture: Editorial comments Architecture read= y for text > > =E2=80=A2 #374 Protocols in Figure 2 Architecture > > =E2=80=A2 #324 Add explicit protocol selection. API ready for tex= t > > =E2=80=A2 #206 Define the server-side equivalent of racing API > Architecture ready for text > > =E2=80=A2 #309 Clarification on queued receives API ready for tex= t > > =E2=80=A2 #178 Architecture privacy and security considerations > Architecture ready for text > > =E2=80=A2 #347 "Events" versus "Callbacks" for security-relevant > asynchrony API Architecture ready for text > > =E2=80=A2 #300 Add property for address privacy API ready for tex= t > > =E2=80=A2 #303 More expressive multipath transport property API r= eady for > text > > =E2=80=A2 #334 Consider message send API that takes padding polic= y as > input API future work > > =E2=80=A2 #375 Multiple receives convenience feature API discuss > > =E2=80=A2 #299 TAPS ARCH - Textual review to notes Architecture > > =E2=80=A2 #45 Do we need to make state storage explicit in the > architecture and API? API Architecture ready for text > > =E2=80=A2 #282 Implementation should describe how to handle proxi= es/TOR > Implementation discuss help wanted > > =E2=80=A2 #357 Default values API discuss ready for text > > =E2=80=A2 #306 Failure of unsatisfiable configurations API > > =E2=80=A2 #270 Add re-initiate() call for voluntary connection mi= gration > API future work > > =E2=80=A2 #258 Do we need a terminology section in arch? Architec= ture > discuss > > =E2=80=A2 #249 API needs a way to handle "STARTTLS" API Architect= ure > discuss > > =E2=80=A2 #312 Detailed author review of Arch text for -03 to pre= pare -04 > Architecture ready for text > > Pull requests > > > > ietf-tapswg/api-drafts (+13/-11/=F0=9F=92=AC11) > > 13 pull requests submitted: > > > > =E2=80=A2 #383 Editorial comments, fixes #365 (by theri) > > =E2=80=A2 #381 Move Transport Properties text and close #373 (by = philsbln) > > =E2=80=A2 #380 Add clarification on Multicast receive to API (by = MaxF12) > > =E2=80=A2 #379 TAPS allows you to dynamically choose protocol sta= cks, we > should say so. (by britram) > > =E2=80=A2 #378 closes #324 (by mwelzl) > > =E2=80=A2 #377 Partial receives are not reordering preferences; f= ix #309 > (by britram) > > =E2=80=A2 #376 Add text for server-side "racing" (by tfpauly) > > =E2=80=A2 #372 Address privacy property, #300 (by tfpauly) > > =E2=80=A2 #370 Add multipath property enumeration (by tfpauly) > > =E2=80=A2 #369 add dates to references, and clean up spurious one= s (by > britram) > > =E2=80=A2 #368 be explicit and careful about callbacks vs events;= fix #347 > (by britram) > > =E2=80=A2 #361 fixes for a few nits (by GrumpyOldTroll) > > =E2=80=A2 #360 udp multicast receive (#150) (by GrumpyOldTroll) > > 3 pull requests received 11 new comments: > > > > =E2=80=A2 #360 udp multicast receive (#150) (9 by MaxF12, philsbl= n, > mwelzl, theri) > > =E2=80=A2 #378 closes #324 (1 by britram) > > =E2=80=A2 #380 Add clarification on Multicast receive to API (1 b= y > philsbln) > > 11 pull requests merged: > > > > =E2=80=A2 #380 Add clarification on Multicast receive to API > > =E2=80=A2 #383 Editorial comments, fixes #365 > > =E2=80=A2 #379 TAPS allows you to dynamically choose protocol sta= cks, we > should say so. > > =E2=80=A2 #376 Add text for server-side "racing" > > =E2=80=A2 #377 Partial receives are not reordering preferences; f= ix #309 > > =E2=80=A2 #368 be explicit and careful about callbacks vs events;= fix #347 > > =E2=80=A2 #370 Add multipath property enumeration > > =E2=80=A2 #372 Address privacy property, #300 > > =E2=80=A2 #369 add dates to references, and clean up spurious one= s > > =E2=80=A2 #360 udp multicast receive (#150) > > =E2=80=A2 #361 fixes for a few nits > > Repositories tracked by this digest: > > > > =E2=80=A2 https://github.com/ietf-tapswg/api-drafts > > _______________________________________________ > > Taps mailing list > > Taps@ietf.org > > https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > --00000000000081b7f00597eae6cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, indeed. This is awesome.=C2=A0

Brian, do you think you can create= a last cal-able version of -arch by the 1st week of December?
On Fri, = Nov 22, 2019 at 4:04 PM Brian Trammell (IETF) <ietf@trammell.ch> wrote:
Wow! The robot can write long messages, too. Good work, everyone!
Cheers,

Brian

> On 22 Nov 2019, at 16:00, TAPS WG status robot <tapsbot@magpie.corvid.ch>= wrote:
>
> Friday November 22, 2019
>
> Issues
>
> ietf-tapswg/api-drafts (+12/-25/=F0=9F=92=AC38)
> 12 issues created:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #384 Experimental cost property: c= ost preference (by mwelzl) API discuss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #382 Multicast impact on architect= ure? (by abrunstrom) Architecture
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #375 Multiple receives convenience= feature (by MaxF12)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #374 Protocols in Figure 2 (by abr= unstrom) Architecture
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #373 Transport Properties are not = Connection Objects (by abrunstrom)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #371 Do we need an example for an = HTTP/1, HTTP/2, HTTP/3 agnostic connection? (by philsbln)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #367 Implementation - PMTU text is= broken (by gorryfair) Implementation ready for text
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #366 Some editorial (I hope) comme= nts on implementation (by gorryfair)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #365 Architecture: Editorial comme= nts (by theri)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #364 Update wording where interfac= e to security protocol implies racing/abstraction (by squarooticus)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #363 "Access to Specialized F= eatures" example: Security protocols (by theri) Architecture
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #362 -impl should say more about u= se of ALPN (by mirjak) Architecture
> 21 issues received 38 new comments:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #375 Multiple receives convenience= feature (6 by britram, mwelzl, philsbln, tfpauly, MaxF12) API discuss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #384 Experimental cost property: c= ost preference (5 by philsbln, mwelzl, gorryfair, tfpauly) API discuss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #362 -impl should say more about u= se of ALPN (3 by philsbln, gorryfair, theri) Implementation
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #363 "Access to Specialized F= eatures" example: Security protocols (3 by philsbln, abrunstrom, squar= ooticus) Architecture
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #382 Multicast impact on architect= ure? (3 by tfpauly) Architecture
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #305 Protocol stacks that are not = equivalent (2 by britram, theri) Architecture
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #374 Protocols in Figure 2 (2 by m= welzl, tfpauly) Architecture
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #258 Do we need a terminology sect= ion in arch? (1 by britram) Architecture discuss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #145 Draft should point at impleme= ntations somewhere (1 by tfpauly) Implementation ready for text
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #150 Add Unidirectional Streams fo= r Multicast / Source and Sink support (1 by MaxF12) API Implementation read= y for text
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #154 Structure of implementation d= raft (1 by tfpauly) Implementation
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #177 Privacy considerations sectio= n (1 by tfpauly) API Implementation ready for text
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #299 TAPS ARCH - Textual review to= notes (1 by tfpauly) Architecture
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #45 Do we need to make state stora= ge explicit in the architecture and API? (1 by britram) API Architecture re= ady for text
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #312 Detailed author review of Arc= h text for -03 to prepare -04 (1 by tfpauly) Architecture ready for text >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #324 Add explicit protocol selecti= on. (1 by britram) API ready for text
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #334 Consider message send API tha= t takes padding policy as input (1 by britram) API future work
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #357 Default values (1 by britram)= API discuss ready for text
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #364 Update wording where interfac= e to security protocol implies racing/abstraction (1 by theri)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #365 Architecture: Editorial comme= nts (1 by britram) Architecture
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #249 API needs a way to handle &qu= ot;STARTTLS" (1 by britram) API Architecture discuss
> 25 issues closed:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #384 Experimental cost property: c= ost preference API discuss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #150 Add Unidirectional Streams fo= r Multicast / Source and Sink support API Implementation ready for text
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #154 Structure of implementation d= raft Implementation
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #145 Draft should point at impleme= ntations somewhere Implementation ready for text
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #382 Multicast impact on architect= ure? Architecture
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #365 Architecture: Editorial comme= nts Architecture ready for text
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #374 Protocols in Figure 2 Archite= cture
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #324 Add explicit protocol selecti= on. API ready for text
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #206 Define the server-side equiva= lent of racing API Architecture ready for text
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #309 Clarification on queued recei= ves API ready for text
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #178 Architecture privacy and secu= rity considerations Architecture ready for text
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #347 "Events" versus &qu= ot;Callbacks" for security-relevant asynchrony API Architecture ready = for text
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #300 Add property for address priv= acy API ready for text
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #303 More expressive multipath tra= nsport property API ready for text
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #334 Consider message send API tha= t takes padding policy as input API future work
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #375 Multiple receives convenience= feature API discuss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #299 TAPS ARCH - Textual review to= notes Architecture
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #45 Do we need to make state stora= ge explicit in the architecture and API? API Architecture ready for text >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #282 Implementation should describ= e how to handle proxies/TOR Implementation discuss help wanted
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #357 Default values API discuss re= ady for text
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #306 Failure of unsatisfiable conf= igurations API
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #270 Add re-initiate() call for vo= luntary connection migration API future work
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #258 Do we need a terminology sect= ion in arch? Architecture discuss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #249 API needs a way to handle &qu= ot;STARTTLS" API Architecture discuss
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #312 Detailed author review of Arc= h text for -03 to prepare -04 Architecture ready for text
> Pull requests
>
> ietf-tapswg/api-drafts (+13/-11/=F0=9F=92=AC11)
> 13 pull requests submitted:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #383 Editorial comments, fixes #36= 5 (by theri)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #381 Move Transport Properties tex= t and close #373 (by philsbln)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #380 Add clarification on Multicas= t receive to API (by MaxF12)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #379 TAPS allows you to dynamicall= y choose protocol stacks, we should say so. (by britram)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #378 closes #324 (by mwelzl)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #377 Partial receives are not reor= dering preferences; fix #309 (by britram)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #376 Add text for server-side &quo= t;racing" (by tfpauly)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #372 Address privacy property, #30= 0 (by tfpauly)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #370 Add multipath property enumer= ation (by tfpauly)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #369 add dates to references, and = clean up spurious ones (by britram)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #368 be explicit and careful about= callbacks vs events; fix #347 (by britram)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #361 fixes for a few nits (by Grum= pyOldTroll)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #360 udp multicast receive (#150) = (by GrumpyOldTroll)
> 3 pull requests received 11 new comments:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #360 udp multicast receive (#150) = (9 by MaxF12, philsbln, mwelzl, theri)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #378 closes #324 (1 by britram) >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #380 Add clarification on Multicas= t receive to API (1 by philsbln)
> 11 pull requests merged:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #380 Add clarification on Multicas= t receive to API
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #383 Editorial comments, fixes #36= 5
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #379 TAPS allows you to dynamicall= y choose protocol stacks, we should say so.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #376 Add text for server-side &quo= t;racing"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #377 Partial receives are not reor= dering preferences; fix #309
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #368 be explicit and careful about= callbacks vs events; fix #347
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #370 Add multipath property enumer= ation
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #372 Address privacy property, #30= 0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #369 add dates to references, and = clean up spurious ones
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #360 udp multicast receive (#150)<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 #361 fixes for a few nits
> Repositories tracked by this digest:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 https://github.com= /ietf-tapswg/api-drafts
> _______________________________________________
> Taps mailing list
> Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps

_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
--00000000000081b7f00597eae6cd-- From nobody Sat Nov 23 21:03:55 2019 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 0B5B812008F for ; Sat, 23 Nov 2019 21:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 kddOVbqQubTD for ; Sat, 23 Nov 2019 21:03:49 -0800 (PST) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (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 7CA35120071 for ; Sat, 23 Nov 2019 21:03:49 -0800 (PST) Received: from smtp-3-0001.mail.infomaniak.ch ([10.4.36.108]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id xAO53jq0004916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 24 Nov 2019 06:03:45 +0100 Received: from [10.11.33.88] (unknown [145.14.214.39]) by smtp-3-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 73257100764F3; Sun, 24 Nov 2019 06:03:45 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: "Brian Trammell (IETF)" In-Reply-To: Date: Sun, 24 Nov 2019 06:03:45 +0100 Cc: taps WG Content-Transfer-Encoding: quoted-printable Message-Id: <7A167010-F87D-47D5-90D7-CAB5B45E0E56@trammell.ch> References: To: Aaron Falk X-Mailer: Apple Mail (2.3445.104.11) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Taps] Weekly github digest (TAPS GitHub Activity Digest) 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: Sun, 24 Nov 2019 05:03:53 -0000 hi Aaron, > On 22 Nov 2019, at 16:06, Aaron Falk wrote: >=20 > Yes, indeed. This is awesome.=20 >=20 > Brian, do you think you can create a last cal-able version of -arch by = the 1st week of December? That seems reasonable. There is one open PR and three open issues, all = assigned, which will result in two more smallish PRs. I've done an = editorial pass on the plane which will result in a tiny PR and one = hopefully-simple issue to discuss. Cheers, Brian >=20 > On Fri, Nov 22, 2019 at 4:04 PM Brian Trammell (IETF) = wrote: > Wow! The robot can write long messages, too. Good work, everyone! >=20 > Cheers, >=20 > Brian >=20 > > On 22 Nov 2019, at 16:00, TAPS WG status robot = wrote: > >=20 > > Friday November 22, 2019 > >=20 > > Issues > >=20 > > ietf-tapswg/api-drafts (+12/-25/=F0=9F=92=AC38) > > 12 issues created: > >=20 > > =E2=80=A2 #384 Experimental cost property: cost preference (by = mwelzl) API discuss > > =E2=80=A2 #382 Multicast impact on architecture? (by = abrunstrom) Architecture > > =E2=80=A2 #375 Multiple receives convenience feature (by = MaxF12)=20 > > =E2=80=A2 #374 Protocols in Figure 2 (by abrunstrom) = Architecture > > =E2=80=A2 #373 Transport Properties are not Connection Objects = (by abrunstrom)=20 > > =E2=80=A2 #371 Do we need an example for an HTTP/1, HTTP/2, = HTTP/3 agnostic connection? (by philsbln)=20 > > =E2=80=A2 #367 Implementation - PMTU text is broken (by = gorryfair) Implementation ready for text > > =E2=80=A2 #366 Some editorial (I hope) comments on = implementation (by gorryfair)=20 > > =E2=80=A2 #365 Architecture: Editorial comments (by theri)=20 > > =E2=80=A2 #364 Update wording where interface to security = protocol implies racing/abstraction (by squarooticus)=20 > > =E2=80=A2 #363 "Access to Specialized Features" example: = Security protocols (by theri) Architecture > > =E2=80=A2 #362 -impl should say more about use of ALPN (by = mirjak) Architecture > > 21 issues received 38 new comments: > >=20 > > =E2=80=A2 #375 Multiple receives convenience feature (6 by = britram, mwelzl, philsbln, tfpauly, MaxF12) API discuss > > =E2=80=A2 #384 Experimental cost property: cost preference (5 = by philsbln, mwelzl, gorryfair, tfpauly) API discuss > > =E2=80=A2 #362 -impl should say more about use of ALPN (3 by = philsbln, gorryfair, theri) Implementation > > =E2=80=A2 #363 "Access to Specialized Features" example: = Security protocols (3 by philsbln, abrunstrom, squarooticus) = Architecture > > =E2=80=A2 #382 Multicast impact on architecture? (3 by = tfpauly) Architecture > > =E2=80=A2 #305 Protocol stacks that are not equivalent (2 by = britram, theri) Architecture > > =E2=80=A2 #374 Protocols in Figure 2 (2 by mwelzl, tfpauly) = Architecture > > =E2=80=A2 #258 Do we need a terminology section in arch? (1 by = britram) Architecture discuss > > =E2=80=A2 #145 Draft should point at implementations somewhere = (1 by tfpauly) Implementation ready for text > > =E2=80=A2 #150 Add Unidirectional Streams for Multicast / = Source and Sink support (1 by MaxF12) API Implementation ready for text > > =E2=80=A2 #154 Structure of implementation draft (1 by = tfpauly) Implementation > > =E2=80=A2 #177 Privacy considerations section (1 by tfpauly) = API Implementation ready for text > > =E2=80=A2 #299 TAPS ARCH - Textual review to notes (1 by = tfpauly) Architecture > > =E2=80=A2 #45 Do we need to make state storage explicit in the = architecture and API? (1 by britram) API Architecture ready for text > > =E2=80=A2 #312 Detailed author review of Arch text for -03 to = prepare -04 (1 by tfpauly) Architecture ready for text > > =E2=80=A2 #324 Add explicit protocol selection. (1 by britram) = API ready for text > > =E2=80=A2 #334 Consider message send API that takes padding = policy as input (1 by britram) API future work > > =E2=80=A2 #357 Default values (1 by britram) API discuss ready = for text > > =E2=80=A2 #364 Update wording where interface to security = protocol implies racing/abstraction (1 by theri)=20 > > =E2=80=A2 #365 Architecture: Editorial comments (1 by britram) = Architecture > > =E2=80=A2 #249 API needs a way to handle "STARTTLS" (1 by = britram) API Architecture discuss > > 25 issues closed: > >=20 > > =E2=80=A2 #384 Experimental cost property: cost preference API = discuss > > =E2=80=A2 #150 Add Unidirectional Streams for Multicast / = Source and Sink support API Implementation ready for text > > =E2=80=A2 #154 Structure of implementation draft = Implementation > > =E2=80=A2 #145 Draft should point at implementations somewhere = Implementation ready for text > > =E2=80=A2 #382 Multicast impact on architecture? Architecture > > =E2=80=A2 #365 Architecture: Editorial comments Architecture = ready for text > > =E2=80=A2 #374 Protocols in Figure 2 Architecture > > =E2=80=A2 #324 Add explicit protocol selection. API ready for = text > > =E2=80=A2 #206 Define the server-side equivalent of racing API = Architecture ready for text > > =E2=80=A2 #309 Clarification on queued receives API ready for = text > > =E2=80=A2 #178 Architecture privacy and security = considerations Architecture ready for text > > =E2=80=A2 #347 "Events" versus "Callbacks" for = security-relevant asynchrony API Architecture ready for text > > =E2=80=A2 #300 Add property for address privacy API ready for = text > > =E2=80=A2 #303 More expressive multipath transport property = API ready for text > > =E2=80=A2 #334 Consider message send API that takes padding = policy as input API future work > > =E2=80=A2 #375 Multiple receives convenience feature API = discuss > > =E2=80=A2 #299 TAPS ARCH - Textual review to notes = Architecture > > =E2=80=A2 #45 Do we need to make state storage explicit in the = architecture and API? API Architecture ready for text > > =E2=80=A2 #282 Implementation should describe how to handle = proxies/TOR Implementation discuss help wanted > > =E2=80=A2 #357 Default values API discuss ready for text > > =E2=80=A2 #306 Failure of unsatisfiable configurations API > > =E2=80=A2 #270 Add re-initiate() call for voluntary connection = migration API future work > > =E2=80=A2 #258 Do we need a terminology section in arch? = Architecture discuss > > =E2=80=A2 #249 API needs a way to handle "STARTTLS" API = Architecture discuss > > =E2=80=A2 #312 Detailed author review of Arch text for -03 to = prepare -04 Architecture ready for text > > Pull requests > >=20 > > ietf-tapswg/api-drafts (+13/-11/=F0=9F=92=AC11) > > 13 pull requests submitted: > >=20 > > =E2=80=A2 #383 Editorial comments, fixes #365 (by theri)=20 > > =E2=80=A2 #381 Move Transport Properties text and close #373 = (by philsbln)=20 > > =E2=80=A2 #380 Add clarification on Multicast receive to API = (by MaxF12)=20 > > =E2=80=A2 #379 TAPS allows you to dynamically choose protocol = stacks, we should say so. (by britram)=20 > > =E2=80=A2 #378 closes #324 (by mwelzl)=20 > > =E2=80=A2 #377 Partial receives are not reordering = preferences; fix #309 (by britram)=20 > > =E2=80=A2 #376 Add text for server-side "racing" (by tfpauly)=20= > > =E2=80=A2 #372 Address privacy property, #300 (by tfpauly)=20 > > =E2=80=A2 #370 Add multipath property enumeration (by tfpauly)=20= > > =E2=80=A2 #369 add dates to references, and clean up spurious = ones (by britram)=20 > > =E2=80=A2 #368 be explicit and careful about callbacks vs = events; fix #347 (by britram)=20 > > =E2=80=A2 #361 fixes for a few nits (by GrumpyOldTroll)=20 > > =E2=80=A2 #360 udp multicast receive (#150) (by = GrumpyOldTroll)=20 > > 3 pull requests received 11 new comments: > >=20 > > =E2=80=A2 #360 udp multicast receive (#150) (9 by MaxF12, = philsbln, mwelzl, theri)=20 > > =E2=80=A2 #378 closes #324 (1 by britram)=20 > > =E2=80=A2 #380 Add clarification on Multicast receive to API = (1 by philsbln)=20 > > 11 pull requests merged: > >=20 > > =E2=80=A2 #380 Add clarification on Multicast receive to API > > =E2=80=A2 #383 Editorial comments, fixes #365 > > =E2=80=A2 #379 TAPS allows you to dynamically choose protocol = stacks, we should say so. > > =E2=80=A2 #376 Add text for server-side "racing" > > =E2=80=A2 #377 Partial receives are not reordering = preferences; fix #309 > > =E2=80=A2 #368 be explicit and careful about callbacks vs = events; fix #347 > > =E2=80=A2 #370 Add multipath property enumeration > > =E2=80=A2 #372 Address privacy property, #300 > > =E2=80=A2 #369 add dates to references, and clean up spurious = ones > > =E2=80=A2 #360 udp multicast receive (#150) > > =E2=80=A2 #361 fixes for a few nits > > Repositories tracked by this digest: > >=20 > > =E2=80=A2 https://github.com/ietf-tapswg/api-drafts > > _______________________________________________ > > Taps mailing list > > Taps@ietf.org > > https://www.ietf.org/mailman/listinfo/taps >=20 > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps From nobody Tue Nov 26 13:17:09 2019 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 9AEAC120ADC for ; Tue, 26 Nov 2019 13:17:07 -0800 (PST) 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_HELO_NONE=0.001, 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 kTVB6WhUerK0 for ; Tue, 26 Nov 2019 13:17:06 -0800 (PST) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 139B6120ADF for ; Tue, 26 Nov 2019 13:17:06 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id r20so22979904qtp.13 for ; Tue, 26 Nov 2019 13:17:06 -0800 (PST) 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=2W3SOSXtT8o1aQh32PiIIQZvEVa6RTVerlI4+zT2Zks=; b=h8TrgdM+3/Vf9hSp8k12il39Vl5yIZcAIaR+qU5lrrdyAYFCgeFO93HPat409nMiXO qdaDmSZlQ49Vr59rprBBkEQrTg5kpQTSQ4zPeskr4NpZo9LYfcP0mQzn8n2Yb/tVB8Ca REsmbqOSgOILlPntRtLbtDZ6A2DA4f9TemjfWtZtFypYx5bKGkBpxVW63JqDNVBVZFA8 zGgaxKR49pB8q0KpAAyCYtIly/nvPueiOoE9MBNLgFpL46yw2L3uH1W4yViwu3QS7AxB voikU3kOcRJ3zZrZ53LNJ91UkMoW2rpkcDkM7q0YDn1sHmCEF4V0pSmAwLqLxY5SWP+Y Uhgg== 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=2W3SOSXtT8o1aQh32PiIIQZvEVa6RTVerlI4+zT2Zks=; b=MimRELFcCrSmDfPgxxiWleb81aFC3h9RwnNrmIsQkKx2AAlua4qwyw/IlqcJ0xT71k EOjXPiTsFAeo6WD0dIfEfinwP6jWKBH4DIkw8lgYGv4vQBRp6TevTv1P3oHDac12GVxt y/V9YOHfgXn7swQYZvS5SGm1fAVri83MKcVo23X5mH+2cKl3vL1MhNT+LKxgOslrk6KH HW0qcrL0IWZf2c8euRqHezFOJVRWs6Ad3lez5LwWGyhaCM9zP4uXY/nZEme1FduFgxn4 HOvc8So0d5ayYiX2JzdQtCCptN2z2lrZgkU8wvcdtXx5lFphgb9ssXopS4U0Gy3fLOpg /QOw== X-Gm-Message-State: APjAAAXnJqsMHJkn24bna8qlksRwPEZGM4oVUOZzUna4lIghWQAxd3VL wEfq1pnGTHIK5bsr7WeRoaZKGEH7 X-Google-Smtp-Source: APXvYqwKdCKgVYH/JZ26GAaK3AxsErOZZyvAtu/N/LNdSCTB+7D9fV/LdzbU+w+qJRVipfRZstd+qA== X-Received: by 2002:ac8:73c6:: with SMTP id v6mr37568787qtp.137.1574803024828; Tue, 26 Nov 2019 13:17:04 -0800 (PST) Received: from [172.19.114.150] ([2001:4878:a048:3000:9127:5963:2c1b:efd3]) by smtp.gmail.com with ESMTPSA id a66sm5707581qkb.27.2019.11.26.13.17.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Nov 2019 13:17:04 -0800 (PST) From: "Aaron Falk" To: "taps WG" Cc: "Zaheduzzaman Sarker" , "Magnus Westerlund" Date: Tue, 26 Nov 2019 16:17:03 -0500 X-Mailer: MailMate (1.13r5655) Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_DAF5383B-7B83-4A6C-BF47-556CD119FEF8_=" Archived-At: Subject: [Taps] interim meeting dates 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, 26 Nov 2019 21:17:07 -0000 --=_MailMate_DAF5383B-7B83-4A6C-BF47-556CD119FEF8_= Content-Type: text/plain; format=flowed; markup=markdown Based on the Doodle results here are the meeting dates for the upcoming TAPS interims: Dec 20, FRI, 11:00 AM - 1:00 PM Jan 24, FRI, 11:00 AM - 1:00 PM Feb 21, FRI, 11:00 AM - 1:00 PM Please add them to your calendar. --aaron --=_MailMate_DAF5383B-7B83-4A6C-BF47-556CD119FEF8_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Based on the Doodle results here are the meeting dates for= the upcoming TAPS interims:

Dec 20, FRI, 11:00 AM - 1:00 PM
Jan 24, FRI, 11:00 AM - 1:00 PM
Feb 21, FRI, 11:00 AM - 1:00 PM

Please add them to your calendar.

--aaron

--=_MailMate_DAF5383B-7B83-4A6C-BF47-556CD119FEF8_=-- From nobody Tue Nov 26 13:19:06 2019 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 DB0DB120ADF for ; Tue, 26 Nov 2019 13:19:03 -0800 (PST) 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, SPF_HELO_NONE=0.001, 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 EGmjMU_keOTx for ; Tue, 26 Nov 2019 13:19:02 -0800 (PST) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 77723120ADC for ; Tue, 26 Nov 2019 13:19:02 -0800 (PST) Received: by mail-qv1-xf33.google.com with SMTP id i3so7963305qvv.7 for ; Tue, 26 Nov 2019 13:19:01 -0800 (PST) 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=V5nD9fNZ/QG2eFpxQg/k5rVy3p8z4XGTm+niJx2dIYA=; b=J7lzv1G7ucnGhctcI+uLgrKPaYEOkZmpYfWOwi4qwZ0/gDf3IcWn/5L4jE+vpGb+Uu OonMAnAkIqrzZnCb3gJaEfxEgYaM6KfbrGEM4sqzNr9GVRz6Jd3GZbl+B58gMNejKDcA ANq9860LnRbF2bs923SA4RI5q6aGGnNX/AOGqkzhA8hpCTnRaT6m2Knd3Gg7h0hN/EAE KUMdsC6/FObZIRTDpoAKHLeET89fXlI/mE2r4qzHh0ET+UculUR88EUq+/HQ/LmT1EZm L5X7kKR4XDExufn9S4m3srOyjFtWEMpU7rZUald6sP8F7witzUvNrIoysgn/j22xML05 8eCw== 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=V5nD9fNZ/QG2eFpxQg/k5rVy3p8z4XGTm+niJx2dIYA=; b=cO24moprIv7oh/GkuyhkbOVNz2TviPIjIOE9D4zEKLPpKYagm2z7Nu4sTVmiyuSNVR Nfs8luKscShd9M3T6yV2aSRlGrqW7VNHKdZh4wmTpJWl25DwQ6JWZSW/WlgxPfLGgPrW /Cr7/fMsblW0IcU/Az//AhywtEpzx/y9UR7XGOPa5NCu28JurRofB79fd2WfwF5y7u31 MJuaYr3qy0PcDRJ9st9XUnQNVmbVi9YbJq02ym/hrJS3So6uasHIl0u8gJpagSeZlNK7 2Kq2fykRfj7wLmYGCuy1DyodFjyrL3J3p/fpHiu+wIvxGd0+jl83F9TjAapXQmvoZddF 3UeA== X-Gm-Message-State: APjAAAUt7Qy73lvGW4kqbSstOPgE9Rggnz5uBs0srsUssW+a/yDMgKoL dUdUY0hlJuODBw9ShyliUno8vA7E X-Google-Smtp-Source: APXvYqx8+cq0culS0OAlgjTysTFWItX8YFSGRQ2g0eCkz1mhobWgVvV3Gx3p+elniCH5uWnCaFf0dg== X-Received: by 2002:a0c:f911:: with SMTP id v17mr949367qvn.94.1574803140578; Tue, 26 Nov 2019 13:19:00 -0800 (PST) Received: from [172.19.114.150] ([2001:4878:a048:3000:9127:5963:2c1b:efd3]) by smtp.gmail.com with ESMTPSA id y91sm6608763qtd.28.2019.11.26.13.18.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Nov 2019 13:19:00 -0800 (PST) From: "Aaron Falk" To: "taps WG" Cc: "Zaheduzzaman Sarker" , "Magnus Westerlund" Date: Tue, 26 Nov 2019 16:18:59 -0500 X-Mailer: MailMate (1.13r5655) Message-ID: <0DDC6D95-7952-46BA-93EA-83E0744117E4@gmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_1F0C92A9-7A5B-497C-BD67-B8232426A000_=" Archived-At: Subject: Re: [Taps] interim meeting dates 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, 26 Nov 2019 21:19:04 -0000 --=_MailMate_1F0C92A9-7A5B-497C-BD67-B8232426A000_= Content-Type: text/plain; format=flowed; markup=markdown All calls are 11am - 1pm EDT, 8am - 10am PDT, 4pm - 6pm UTC since we span EU & US west coast. Agendas will be refined as we get closer to the call. On 26 Nov 2019, at 16:17, Aaron Falk wrote: > Based on the Doodle results here are the meeting dates for the > upcoming TAPS interims: > > Dec 20, FRI, 11:00 AM - 1:00 PM > Jan 24, FRI, 11:00 AM - 1:00 PM > Feb 21, FRI, 11:00 AM - 1:00 PM > > Please add them to your calendar. > > --aaron --=_MailMate_1F0C92A9-7A5B-497C-BD67-B8232426A000_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">All calls are 11am - 1pm EDT, 8am - 10am PDT, 4pm - 6pm UT= C since we span EU & US west coast. Agendas will be refined as we get= closer to the call.

On 26 Nov 2019, at 16:17, Aaron Falk wrote:

Based on the Doodle results here ar= e the meeting dates for the upcoming TAPS interims:

Dec 20, FRI, 11:00 AM - 1:00 PM
Jan 24, FRI, 11:00 AM - 1:00 PM
Feb 21, FRI, 11:00 AM - 1:00 PM

Please add them to your calendar.

--aaron

--=_MailMate_1F0C92A9-7A5B-497C-BD67-B8232426A000_=-- From nobody Fri Nov 29 00:02:19 2019 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 5C5C71201DB for ; Fri, 29 Nov 2019 00:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 Vj9oSlsMhTOx for ; Fri, 29 Nov 2019 00:02:17 -0800 (PST) Received: from magpie.corvid.ch (magpie.corvid.ch [46.101.110.207]) (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 C8FBE1200DB for ; Fri, 29 Nov 2019 00:02:16 -0800 (PST) Received: from [127.0.0.1] (helo=magpie.corvid.ch) by magpie.corvid.ch with esmtp (Exim 4.92) (envelope-from ) id 1iabC8-00074E-PA for taps@ietf.org; Fri, 29 Nov 2019 08:00:04 +0000 Content-Type: multipart/alternative; boundary="===============6534040034926678258==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 29 Nov 2019 08:00:04 +0000 Archived-At: Subject: [Taps] Weekly github digest (TAPS GitHub Activity Digest) 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, 29 Nov 2019 08:02:18 -0000 --===============6534040034926678258== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * ietf-tapswg/api-drafts (+1/-0/=F0=9F=92=AC1) 1 issues created: - Clarify that more flexible resolution is an architectural feature (by b= ritram) https://github.com/ietf-tapswg/api-drafts/issues/385 [Architecture] = 1 issues received 1 new comments: - #371 Do we need an example for an HTTP/1, HTTP/2, HTTP/3 agnostic conne= ction? (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/371 [API] = Pull requests ------------- * ietf-tapswg/api-drafts (+2/-1/=F0=9F=92=AC8) 2 pull requests submitted: - Fix #385: Resolution is key to path and stack agility. Say so. (by brit= ram) https://github.com/ietf-tapswg/api-drafts/pull/387 = - Minor editorial tweaks to Architecture (by britram) https://github.com/ietf-tapswg/api-drafts/pull/386 = 2 pull requests received 8 new comments: - #381 Move Transport Properties text and close #373 (7 by philsbln, abru= nstrom, britram, tfpauly) https://github.com/ietf-tapswg/api-drafts/pull/381 = - #387 Fix #385: Resolution is key to path and stack agility. Say so. (1 = by britram) https://github.com/ietf-tapswg/api-drafts/pull/387 = 1 pull requests merged: - Minor editorial tweaks to Architecture https://github.com/ietf-tapswg/api-drafts/pull/386 = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============6534040034926678258== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday November 29, 2019

Issues

ietf-tapswg/api-drafts (+1/-0/=F0=9F=92=AC1)

1 issues created:

1 issues received 1 new comments:

Pull requests

ietf-tapswg/api-drafts (+2/-1/=F0=9F=92=AC8)

2 pull requests submitted:

2 pull requests received 8 new comments:

1 pull requests merged:

Repositories tracked by this digest:

--===============6534040034926678258==-- From nobody Sat Nov 30 16:42:53 2019 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 7073D120831 for ; Sat, 30 Nov 2019 16:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 9vawHGtN244a for ; Sat, 30 Nov 2019 16:42:47 -0800 (PST) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (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 F4018120830 for ; Sat, 30 Nov 2019 16:42:46 -0800 (PST) Received: by mail-lj1-x241.google.com with SMTP id e9so35766842ljp.13 for ; Sat, 30 Nov 2019 16:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=c+Ltz3GyzoHvfQ33aFNlEnWe1OsMVcHtBcGaC/qMPMM=; b=sPohdiM5CQF3dPjJSoxJ1I5LTIoyq1Drq4GaayR+N8Zgqb2mXRYcF5bFxKpJBV3WJF XompaLyon/ahwpHARFAi8AitGli2SMVkO3x6BOEPEBRrgZG6ocAiomSB0KJLJ66LvjME vASWM8FrHbFimEmLbL/ZUJJ1nI2CotL0JtZizULqFqlFgm1DAT4UGq36TRcw29v8YNcr 1aa/VPD1MUgz8chun+FK5vWQdcM12iC/G8u4oqfmkNsyb5oqIDaOuEGd1PqDyyujEBJo O8PIXOOubuaU/Pt4rlkb+tiNtdZKwceXUBy4BJqG9MNxUnWU9atyhbrRwx7eRMOUgIBP OtDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=c+Ltz3GyzoHvfQ33aFNlEnWe1OsMVcHtBcGaC/qMPMM=; b=r1lLhD1+1ZvhqUwcNuWDtsq8OrbdX6eaWW6FF1f2SnL7evSd9pUq2qnWtnEca7GuLR 8e2pHVLhWV1q6lmHBWInk/oUvAZEdy4+q05IXN81/hbwgiMCMvs/bSGy1nO6amGiHwU/ x2WQ2kvR/S5QECZDyryb3Pv3YhNk/vgXK59nV63HJcRIIAjuB+pC7OcmBnjmkhfCl8y+ VD+RltcIyYK2HKMW5FOtzt76YJ+qHFW4B79KempZ0HjilSj/kloScJHZjKbx4Jx5kL9/ Ui6yYD/UnCQhoPgrNxh89kXAIwdgvIUO4xWL5mDHJTcCyd+tOsHeKhh7gZECLhVBtkNE wiJw== X-Gm-Message-State: APjAAAVWNK8MIPG06ogJ8Hw7Zz6SffHuDuE/7lBOQQ6vKOrrIFLc2PjL xm7/VJeUaRg7LupBhICOpZbkeWsI9p8Nm3R3/Lfplxbymjg= X-Google-Smtp-Source: APXvYqyv8fXnT+qu3WGrjOyuupqXF+ulmkW+z/cwbUsGxrq7WfDMajKyDMlg63ImssyGQJq3sXlSWAfXrOkPRGJoJ4U= X-Received: by 2002:a2e:7013:: with SMTP id l19mr42149456ljc.201.1575160964644; Sat, 30 Nov 2019 16:42:44 -0800 (PST) MIME-Version: 1.0 From: Eric Rescorla Date: Sat, 30 Nov 2019 16:42:08 -0800 Message-ID: To: taps@ietf.org, draft-ietf-taps-transport-security.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000c31490059899bdca" Archived-At: Subject: [Taps] Review of draft-ietf-taps-transport-security-10 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: Sun, 01 Dec 2019 00:42:50 -0000 --000000000000c31490059899bdca Content-Type: text/plain; charset="UTF-8" Document: draft-ietf-taps-transport-security-10.txt This document is much improved. I appreciate you removing all the fine detail of each transport protocol. However, I think another pass is probably required. At a high level, I think your taxonomy is still problematic, especially when it comes to TLS/DTLS because they have been so widely used in coordination with other protocols (SRTP, SCTP, QUIC, EAP, etc.) So, it's simultaneously a full transport protocol (the original usage), an external key management protocol (OpenVPN), an embedded key management protocol (QUIC, and what's effectively a VPN protocol (SCTP over DTLS and AnyConnect VPN). Part of this can be fixed by just saying something like this and including DTLS in a few other places in the doc, but in general, the world is just complicated and so taxonomies are difficult. It would probably somewhat help to explain the common design for channel security protocols. Something like: In general, channel security protocols follow a common pattern: - A handshake protocol is responsible for negotiating parameters, authenticating the endpoints, and establishing shared keys. - A record protocol is used to encrypt traffic using keys and parameters provided by the handshake protocol. In some systems, such as IPsec, these protocols are separate: AH and ESP just assume some external source of keys and parameters; these are commonly supplied by IKEv2 but can also be supplied by some other protocol or manually configured. In other systems, these are tightly integrated, as in tcpcrypt. Some protocols can also be used in both configurations: the base TLS protocol as defined in [RFC8446] has an integrated handshake and record protocol, but TLS or DTLS can be used to negotiate keys for other protocols, as in DTLS-SRTP, or the handshake can be used alone with s separate record layer, as in QUIC. S 3.2.1. You're going to want to mention DTLS-SRTP here, partly for the reasons I mentioned above but partly to help understand the situation with ZRTP. I.e., SRTP, like IPsec, just assumes that it has some external keying mechanism and DTLS and ZRTP both fill this role. S 3.3.1. I would just call this IETF QUIC, because QUICv1 is defined to use TLS. S 3.3.5. CurveCP [CurveCP] is a UDP-based transport security protocol from Daniel J. Bernstein. Unlike other security protocols, it is based entirely upon highly efficient public key algorithms. This removes many pitfalls associated with nonce reuse and key synchronization. This text is going to be confusing to people. Not to say that CurveCP is bad, and the primitives it uses *are* fast, but they're not any faster than those used by TLS, QUIC, or tcpcrypt. I think the consensus here is that it's not currently practical to have a general purpose transport protocol that doesn't do key establishment and then use symmetric keys. (This is the same reason why we weren't able to use public key encryption for QUIC CID encryption). 3.4.3. OpenVPN OpenVPN [OpenVPN] is a commonly used protocol designed as an alternative to IPsec. A major goal of this protocol is to provide a VPN that is simple to configure and works over a variety of transports. OpenVPN encapsulates either IP packets or Ethernet frames within a secure tunnel and can run over UDP or TCP. It's probably worth noting that OpenVPN uses SSL/TLS for handshake, as it illustrates the pattern above. 4.1. Reliable Byte-Stream Transports The following protocols all depend upon running on a transport protocol that provides a reliable, in-order stream of bytes. This is typically TCP. Application Payload Security Protocols: o TLS Transport-Layer Security Protocols: o tcpcrypt This doesn't seem quite right, as tcpcrypt is run prior to the TCP reassembly algorithms. Packet Security Protocols: o OpenVPN Well, sort of. OpenVPN needs TCP for its key establishment phase but not its transport phase. That doesn't seem like that interesting a point to make here, as if TCP wasn't available, it could just cut over to DTLS. 5.1. Pre-Connection Interfaces Configuration interfaces are used to configure the security protocols before a handshake begins or the keys are negotiated. This presentation seems pretty hard to follow, in that it's a lot of work to figure out which in the long list of protocols doesn't have this property. Maybe a summary table would help? Also, I'm not sure you want to omit tcpcrypt here, in that it does have a way to do external authentication by exporting a session ID. Also ZRTP allows for some sort of fingerprint-based auth. tcpcrypt (and I believe ZRTP) both have session caches. o Authentication Delegation: The application provides access to a separate module that will provide authentication, using EAP for example. You don't list TLS, but what about EAP-TLS? I'm not following any of the text around import. This direct/explicit distinction seems arbitrary, and weird for QUIC, because QUIC doesn't really have explicit import so much as a dependency on a handshake protocol that must be integrated. S 5.2. IKE has source address validation, no? S 5.3. o Connection Termination: The security protocol may be instructed to tear down its connection and session information. This is needed by some protocols to prevent application data truncation attacks. This seems like kind of a confusing section, I think partly because it ignores layering. The way I think of this is that we have an existing family of insecure protocols that have their own termination mechanisms (e.g., TCP FIN/RST). A security protocol that is under such a protocol (e.g., IPsec) doesn't need a secure termination mechanism because (a) the existing termination mechanism become secure and (b) it can just stop transmitting. By contrast, a security protocol that is above (TLS) or at the level of such a protocol (QUIC, tcpcrypt) needs its own secure termination mechanism, lest it be at the mercy of the transport. o Mobility Events: The record protocol can be signaled that it is being migrated to another transport or interface due to connection mobility, which may reset address and state validation and induce state changes such as use of a new Connection Identifier (CID). How does this work in ESP, actually? DTLS sort of has this, in that it has a CID, but vague migration rules. --000000000000c31490059899bdca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Document: draft-ietf-taps-transport-security-10.txt
This document is much improved. I appreciate you removing all the fine
= detail of each transport protocol. However, I think another pass
is prob= ably required.

At a high level, I think your taxonomy is still probl= ematic,
especially when it comes to TLS/DTLS because they have been so w= idely
used in coordination with other protocols (SRTP, SCTP, QUIC, EAP,<= br>etc.) So, it's simultaneously a full transport protocol (the origina= l
usage), an external key management protocol (OpenVPN), an embedded key=
management protocol (QUIC, and what's effectively a VPN protocol (S= CTP
over DTLS and AnyConnect VPN). Part of this can be fixed by just
= saying something like this and including DTLS in a few other places
in t= he doc, but in general, the world is just complicated and so
taxonomies = are difficult.

It would probably somewhat help to explain the common= design for
channel security protocols. Something like:

=C2=A0 = =C2=A0 In general, channel security protocols follow a common pattern:
= =C2=A0 =C2=A0
=C2=A0 =C2=A0 - A handshake protocol is responsible for n= egotiating parameters,
=C2=A0 =C2=A0 =C2=A0 authenticating the endpoints= , and establishing shared keys.
=C2=A0 =C2=A0
=C2=A0 =C2=A0 - A reco= rd protocol is used to encrypt traffic using keys and
=C2=A0 =C2=A0 =C2= =A0 parameters provided by the handshake protocol.
=C2=A0 =C2=A0
=C2= =A0 =C2=A0 In some systems, such as IPsec, these protocols are separate:=C2=A0 =C2=A0 AH and ESP just assume some external source of keys and para= meters;
=C2=A0 =C2=A0 these are commonly supplied by IKEv2 but can also = be supplied
=C2=A0 =C2=A0 by some other protocol or manually configured.= In other systems,
=C2=A0 =C2=A0 these are tightly integrated, as in tcp= crypt. Some protocols can also be used in both
=C2=A0 =C2=A0 configurati= ons: the base TLS protocol as defined in [RFC8446] has
=C2=A0 =C2=A0 an = integrated handshake and record protocol, but TLS or DTLS can be
=C2=A0 = =C2=A0 used to negotiate keys for other protocols, as in DTLS-SRTP,
=C2= =A0 =C2=A0 or the handshake can be used alone with s separate record layer,=
=C2=A0 =C2=A0 as in QUIC.


S 3.2.1.
You're going to wa= nt to mention DTLS-SRTP here, partly for the reasons
I mentioned above b= ut partly to help understand the situation with
ZRTP. I.e., SRTP, like I= Psec, just assumes that it has some external
keying mechanism and DTLS a= nd ZRTP both fill this role.


S 3.3.1.
I would just call this = IETF QUIC, because QUICv1 is defined to use
TLS.


S 3.3.5.
= =C2=A0 =C2=A0CurveCP [CurveCP] is a UDP-based transport security protocol f= rom
=C2=A0 =C2=A0Daniel J.=C2=A0 Bernstein.=C2=A0 Unlike other security = protocols, it is based
=C2=A0 =C2=A0entirely upon highly efficient publi= c key algorithms.=C2=A0 This removes
=C2=A0 =C2=A0many pitfalls associat= ed with nonce reuse and key synchronization.

This text is going to b= e confusing to people.=C2=A0 Not to say that CurveCP
is bad, and the pri= mitives it uses *are* fast, but they're not any
faster than those us= ed by TLS, QUIC, or tcpcrypt. I think the
consensus here is that it'= s not currently practical to have a general
purpose transport protocol t= hat doesn't do key establishment and then
use symmetric keys. (This = is the same reason why we weren't able
to use public key encryption = for QUIC CID encryption).


3.4.3.=C2=A0 OpenVPN

=C2=A0 =C2= =A0OpenVPN [OpenVPN] is a commonly used protocol designed as an
=C2=A0 = =C2=A0alternative to IPsec.=C2=A0 A major goal of this protocol is to provi= de a
=C2=A0 =C2=A0VPN that is simple to configure and works over a varie= ty of
=C2=A0 =C2=A0transports.=C2=A0 OpenVPN encapsulates either IP pack= ets or Ethernet
=C2=A0 =C2=A0frames within a secure tunnel and can run o= ver UDP or TCP.

It's probably worth noting that OpenVPN uses SSL= /TLS for handshake,
as it illustrates the pattern above.


4.1.= =C2=A0 Reliable Byte-Stream Transports

=C2=A0 =C2=A0The following pr= otocols all depend upon running on a transport
=C2=A0 =C2=A0protocol tha= t provides a reliable, in-order stream of bytes.=C2=A0 This is
=C2=A0 = =C2=A0typically TCP.

=C2=A0 =C2=A0Application Payload Security Proto= cols:

=C2=A0 =C2=A0o =C2=A0TLS

=C2=A0 =C2=A0Transport-Layer S= ecurity Protocols:

=C2=A0 =C2=A0o =C2=A0tcpcrypt

This doesn&#= 39;t seem quite right, as tcpcrypt is run prior to the TCP
reassembly al= gorithms.


=C2=A0 =C2=A0Packet Security Protocols:

=C2=A0 = =C2=A0o =C2=A0OpenVPN

Well, sort of. OpenVPN needs TCP for its key e= stablishment phase but
not its transport phase. That doesn't seem li= ke that interesting
a point to make here, as if TCP wasn't available= , it could just
cut over to DTLS.


5.1.=C2=A0 Pre-Connection I= nterfaces

=C2=A0 =C2=A0Configuration interfaces are used to configur= e the security protocols
=C2=A0 =C2=A0before a handshake begins or the k= eys are negotiated.

This presentation seems pretty hard to follow, i= n that it's a lot of
work to figure out which in the long list of pr= otocols doesn't have
this property. Maybe a summary table would help= ?

Also, I'm not sure you want to omit tcpcrypt here, in that it = does
have a way to do external authentication by exporting a session ID.=
Also ZRTP allows for some sort of fingerprint-based auth.

tcpcry= pt (and I believe ZRTP) both have session caches.


=C2=A0 o =C2= =A0Authentication Delegation: The application provides access to a
=C2= =A0 =C2=A0 =C2=A0 separate module that will provide authentication, using E= AP for
=C2=A0 =C2=A0 =C2=A0 example.

You don't list TLS, but = what about EAP-TLS?


I'm not following any of the text around= import. This direct/explicit
distinction seems arbitrary, and weird for= QUIC, because QUIC doesn't
really have explicit import so much as a= dependency on a handshake
protocol that must be integrated.

S 5.= 2.
IKE has source address validation, no?


S 5.3.
=C2=A0 = =C2=A0o =C2=A0Connection Termination: The security protocol may be instruct= ed to
=C2=A0 =C2=A0 =C2=A0 tear down its connection and session informat= ion.=C2=A0 This is needed
=C2=A0 =C2=A0 =C2=A0 by some protocols to prev= ent application data truncation attacks.

This seems like kind of a c= onfusing section, I think partly because it
ignores layering.

The= way I think of this is that we have an existing family of insecure
prot= ocols that have their own termination mechanisms (e.g., TCP
FIN/RST). A = security protocol that is under such a protocol (e.g.,
IPsec) doesn'= t need a secure termination mechanism because (a) the
existing terminati= on mechanism become secure and (b) it can just stop
transmitting. By con= trast, a security protocol that is above (TLS) or
at the level of such a= protocol (QUIC, tcpcrypt) needs its own secure
termination mechanism, l= est it be at the mercy of the transport.


=C2=A0 =C2=A0o =C2=A0Mo= bility Events: The record protocol can be signaled that it is
=C2=A0 =C2= =A0 =C2=A0 being migrated to another transport or interface due to connecti= on
=C2=A0 =C2=A0 =C2=A0 mobility, which may reset address and state vali= dation and induce
=C2=A0 =C2=A0 =C2=A0 state changes such as use of a ne= w Connection Identifier (CID).

How does this work in ESP, actually?<= br>
DTLS sort of has this, in that it has a CID, but vague migration rul= es.
--000000000000c31490059899bdca--