From nobody Tue Aug 4 15:26:49 2020 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 968EC3A1185 for ; Tue, 4 Aug 2020 15:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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 UTSvsY59grrt for ; Tue, 4 Aug 2020 15:26:46 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 82CF23A111E for ; Tue, 4 Aug 2020 15:26:46 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id j8so31564559ioe.9 for ; Tue, 04 Aug 2020 15:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=aUiS2TJKJXob9W1icrg7T4jxeD2bOmDyLRbGxC3mjVQ=; b=kvBTo13u9slg+wx4spZcfg2OFmgIpcgdEvZhOgouahRzk3HO5P+dDlPyEeqlywXAI2 DrH8Ol1/7lpgouJrX9b3Fvb+lPf7GWzWw4J0MpkKqG0HcquDdjBLjL2KU2qR4/VJOPLK FPM8ZPmHcgAUQuKfqwY7J35czFYraVdHqfimQuCmFAZeXmUJhpQ6vmyonF7LdATtQVPa fM/gX+jD/6oyN2Iq/GSdcjfDgBsQSu8W7+cablI0BWbiJ0nj95ltT53pMpxgq+wrEG+e AJrUHyO0zdzm2n1ZgG+YPh/0C0qXUgrgoNysT1Zv/o9VlFs9HPmtNIvgRneUbFjtVbfo mEMw== 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=aUiS2TJKJXob9W1icrg7T4jxeD2bOmDyLRbGxC3mjVQ=; b=ui33g198+x5R1VAOIJJKE/FyzZnESDGivXsi4hX2sHNd4P+Hylpn6ENchid6O9SOb6 opkUwIuzLwNXZQoZiUEv9j1qlpCdAOff0s6yBVRZHlKU33qquArNFT0HP5vBngZ3Lhk9 7YTLeTqQlo0o7p7Zl05Bmz7vCQAkN4lcBqeh46rWF2TH8/VlDc/VzNmYqbibWjRvu6bD FtnThyu0GsOZH88Py62H+fDCtmS4IBO/eKAIcu8CXx76d7ma2ysm6k64gpbTSpZJ4i4Y JkaB5pm5AhzI3vuDPaYq/zVFcn45GpeM/pmys1fKBHAONizH+yczplmg7YY+DKmqqK81 wz9A== X-Gm-Message-State: AOAM533bQ+OpBK6HKYEcYUL5ilgCwLakAC6D2t115LHLn0qN3iGdiv/r PNLvqFL6QY1HWAJ1APJwA7yqjRfaWAXU1tYSvtWnDcoZ X-Google-Smtp-Source: ABdhPJyVRkhDXwxZfe2wsGIaJHM2dwbCbWBU5Q14uI8kIMEZlE8cEGmqdxJGoCxIPG/IfmQcJtuUqis11JVkb3pRgoU= X-Received: by 2002:a6b:c504:: with SMTP id v4mr234358iof.20.1596580005591; Tue, 04 Aug 2020 15:26:45 -0700 (PDT) MIME-Version: 1.0 From: Martin Duke Date: Tue, 4 Aug 2020 15:26:35 -0700 Message-ID: To: taps WG Content-Type: multipart/alternative; boundary="00000000000016bfab05ac14c03a" Archived-At: Subject: [Taps] Draft-ietf-taps-arch-08 review 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, 04 Aug 2020 22:26:48 -0000 --00000000000016bfab05ac14c03a Content-Type: text/plain; charset="UTF-8" I have read this document and believe it is ready for publication. However, is it worthwhile to include something here about extensibility? If new transports introduce new concepts, should we any requirements of the api to have extension points for those concepts? --00000000000016bfab05ac14c03a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have read this document and believe it is ready for pub= lication.

However, is it= worthwhile to include something here about extensibility? If new transport= s introduce new concepts, should we any requirements of the api to have ext= ension points for those concepts?
--00000000000016bfab05ac14c03a-- From nobody Wed Aug 5 08:31:56 2020 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 BB2893A0B74 for ; Wed, 5 Aug 2020 08:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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 Bc7VbpLrDfKS for ; Wed, 5 Aug 2020 08:31:53 -0700 (PDT) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 AE20E3A0B53 for ; Wed, 5 Aug 2020 08:31:53 -0700 (PDT) Received: by mail-il1-x12c.google.com with SMTP id x1so17403453ilp.7 for ; Wed, 05 Aug 2020 08:31:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=nMsPDaK3Zvci62RQRbgvRDxYmJFTbbv8IroN67KhsU8=; b=j9bKt9QUdx1NDRCV5jX/4eUKZ3uz5rZQAsdVE2izeVKyHSqdIBaOfMBvHMoh94aifz M4BfFsjCOhC5P+fwlb0vYMcNRUeBIVsqVmwDYqs7vJouCBj42Ll2R03SzBRMVF9q4bub zS8vh05oZlys+GxftErNf4swWQPOOoeXwYepMn91c8qkJ4233MUWLP7I4xeLVmoUF6dN HHhT9hNK8ERES8HZnYE9mJI5pTsGVzb8d8rdLem1hpcTr+1CBJo+EfhacYQlUcqwwXlh //rnt4gGCM9jftuwseV4Wx5O1zXt1DZocJlga1PhH9O1PM/qL1SBLdxSI6DRbul4Rn/p rQ/g== 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; bh=nMsPDaK3Zvci62RQRbgvRDxYmJFTbbv8IroN67KhsU8=; b=RO6eMdz5uYzSGRoJBFxLXE8u5teF1XvJ743xAhokt07GQ8803ERTnmpk+HMhof2le/ iMIaqg7mFWmbK8S5PipkXF6XTnX4w3vRRY0XGAqmoCno24nRXVepVGi7oxX4DxrEzEBB sWySOdi6RfJBnydgqG3kNrYq/ML6kZjro+uui/M4tKXF4F/Z6qRegOk3dgHjXqiTiyM+ a80LugfPlkJ1SDdHs1o1/Yxo0JfxS/+CJnLJ+ZTErUAWpBAS+mfYh3dMV49BDWxmsPYz NUv1bFljd6g+xM1/0j6AlFn+8yn7e9L7mt9wlBjP/Hh9csDlIkFYxuAN1k/SxwG5KKBW iEXg== X-Gm-Message-State: AOAM5301IwUhfnp1QPqQSCVDuI0wWUmfSghU1XQ7HkeNpTZyVwKbxCaH Vef+9b0ShSlGrsUOL/xw+0z8w22gC8aHuTvv4vttbX4i X-Google-Smtp-Source: ABdhPJzvKqQy6sdbiRdBqNHEKu8CEBr0FcGnONVTwIQC0HT+lRDx/9YMTUUGBA57wQeP1cu2eyBbEv6z1Rf1E8DTtYw= X-Received: by 2002:a92:1f0f:: with SMTP id i15mr4723707ile.237.1596641512662; Wed, 05 Aug 2020 08:31:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Duke Date: Wed, 5 Aug 2020 08:31:41 -0700 Message-ID: To: taps WG Content-Type: multipart/alternative; boundary="000000000000322d1205ac2312fc" Archived-At: Subject: Re: [Taps] Draft-ietf-taps-arch-08 review 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, 05 Aug 2020 15:31:55 -0000 --000000000000322d1205ac2312fc Content-Type: text/plain; charset="UTF-8" Also the authors should nominate a handful of editors to limit the byline. On Tue, Aug 4, 2020 at 3:26 PM Martin Duke wrote: > I have read this document and believe it is ready for publication. > > However, is it worthwhile to include something here about extensibility? > If new transports introduce new concepts, should we any requirements of the > api to have extension points for those concepts? > --000000000000322d1205ac2312fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Also the authors should nominate a handful of editor= s to limit the byline.

On Tue, Aug 4, 2020 at 3:26 PM Martin Duke= <martin.h.duke@gmail.com= > wrote:
I hav= e read this document and believe it is ready for publication.

However, is it worthwhile to include = something here about extensibility? If new transports introduce new concept= s, should we any requirements of the api to have extension points for those= concepts?
--000000000000322d1205ac2312fc-- From nobody Wed Aug 5 08:48:17 2020 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 CB40F3A0A9F for ; Wed, 5 Aug 2020 08:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=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 dLlD75c18iWd for ; Wed, 5 Aug 2020 08:48:15 -0700 (PDT) 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 631853A0A06 for ; Wed, 5 Aug 2020 08:48:15 -0700 (PDT) Received: from pps.filterd (nwk-aaemail-lapp01.apple.com [127.0.0.1]) by nwk-aaemail-lapp01.apple.com (8.16.0.43/8.16.0.42) with SMTP id 075Fdp0G002992; Wed, 5 Aug 2020 08:48:13 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=iOXh02auXHVCU1+PneD2jOOfTq6OYh/vpBscjIvdtEA=; b=QAwpBYQzhsXDf81w4a4FgZ2EdwK9RNbHewJffDtS6iuFBGcPZuxzP6OBQB3iwrIGrw+5 ZwAglZyS5rd+jK1VcAA6eUSde0YQoz/0zAYoEBf/+E7Dhy5agf2u6Oh6MRp03oBV5jDr aQo3eFbXdz2mIBUFtka6aixvKUWd/QkmKLLtKRhezVFyqTRfM3Q4TJ8udQU8s00VJqkB 970iC9Nqii2YqBlBLMKFjNek3C+O7w7M0n171OpTnRbvUKY6CTS3EM/PdqxZx+nWXBDt AsRjBm/UqcfkFxOYNeVAKCq9rWxXXQAn0kV6Dml/lwyY/ohGaTgxf5oON9S4Kp5ajwHK MQ== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by nwk-aaemail-lapp01.apple.com with ESMTP id 32nvffj45h-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 05 Aug 2020 08:48:13 -0700 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPS id <0QEL011IZL8CXB10@rn-mailsvcp-mta-lapp03.rno.apple.com>; Wed, 05 Aug 2020 08:48:12 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) id <0QEL00500KUB5O00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Wed, 05 Aug 2020 08:48:09 -0700 (PDT) X-Va-A: X-Va-T-CD: 8d45deca0a60b8e84b634a23cb93b003 X-Va-E-CD: 29fe15a9f4936c336621990590fa901b X-Va-R-CD: d043d6b811de3387417919956bc30993 X-Va-CD: 0 X-Va-ID: 65597b1d-c74c-4202-a028-eff35d626faa X-V-A: X-V-T-CD: 8d45deca0a60b8e84b634a23cb93b003 X-V-E-CD: 29fe15a9f4936c336621990590fa901b X-V-R-CD: d043d6b811de3387417919956bc30993 X-V-CD: 0 X-V-ID: 1e990df2-af7c-465d-b960-1f521009c9eb X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-05_10:2020-08-03, 2020-08-05 signatures=0 Received: from [17.234.104.58] (unknown [17.234.104.58]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.6.20200729 64bit (built Jul 29 2020)) with ESMTPSA id <0QEL010JBL845H00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Wed, 05 Aug 2020 08:48:05 -0700 (PDT) From: Tommy Pauly Message-id: Content-type: multipart/alternative; boundary="Apple-Mail=_419BE93A-385E-48B3-A4A3-2F6AD95F4555" MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.80.7.2.3\)) Date: Wed, 05 Aug 2020 08:48:04 -0700 In-reply-to: Cc: taps WG To: Martin Duke References: X-Mailer: Apple Mail (2.3608.80.7.2.3) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-05_10:2020-08-03, 2020-08-05 signatures=0 Archived-At: Subject: Re: [Taps] Draft-ietf-taps-arch-08 review 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, 05 Aug 2020 15:48:17 -0000 --Apple-Mail=_419BE93A-385E-48B3-A4A3-2F6AD95F4555 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Martin, On the author/editor side, please note that Brian and myself are already = the editors for this document. The API and implementation documents also = have two editors each. For background see: https://github.com/ietf-tapswg/api-drafts/issues/184 = I have been arguing for just having the editors being on the byline, = with the rest of the authors in the document. It=E2=80=99s gotten to the = point where we need to do manual submission of metadata since the data = tracker doesn=E2=80=99t correctly parse dates when there are this many = authors. But I was unable to gain agreement on this issue previously. Regarding your comment about extensibility, I think we could add a = sentence or two to Sections 3.1 and 3.2. The main extensibility point = describe is in having transport-specific features that are = impementation-specific. If there are entirely new functionalities that = should become part of the standard/common API across implementations, = then I imagine that would need to be an extension/bis to TAPS.=20 Thanks, Tommy > On Aug 5, 2020, at 8:31 AM, Martin Duke = wrote: >=20 > Also the authors should nominate a handful of editors to limit the = byline. >=20 > On Tue, Aug 4, 2020 at 3:26 PM Martin Duke > wrote: > I have read this document and believe it is ready for publication. >=20 > However, is it worthwhile to include something here about = extensibility? If new transports introduce new concepts, should we any = requirements of the api to have extension points for those concepts? > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_419BE93A-385E-48B3-A4A3-2F6AD95F4555 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Martin,

On the = author/editor side, please note that Brian and myself are already the = editors for this document. The API and implementation documents also = have two editors each.

For background see: https://github.com/ietf-tapswg/api-drafts/issues/184
<= div class=3D"">
I have been arguing = for just having the editors being on the byline, with the rest of the = authors in the document. It=E2=80=99s gotten to the point where we need = to do manual submission of metadata since the data tracker doesn=E2=80=99t= correctly parse dates when there are this many authors. But I was = unable to gain agreement on this issue previously.

Regarding your comment = about extensibility, I think we could add a sentence or two to Sections = 3.1 and 3.2. The main extensibility point describe is in having = transport-specific features that are impementation-specific. If there = are entirely new functionalities that should become part of the = standard/common API across implementations, then I imagine that would = need to be an extension/bis to TAPS. 

Thanks,
Tommy

On Aug 5, 2020, at 8:31 AM, = Martin Duke <martin.h.duke@gmail.com> wrote:

Also the authors should nominate a handful of = editors to limit the byline.

On Tue, Aug 4, 2020 at 3:26 PM Martin Duke <martin.h.duke@gmail.com> wrote:
I have read this document and believe it is ready for = publication.

However, is it worthwhile to include something = here about extensibility? If new transports introduce new concepts, = should we any requirements of the api to have extension points for those = concepts?
_______________________________________________
Taps = mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Apple-Mail=_419BE93A-385E-48B3-A4A3-2F6AD95F4555-- From nobody Thu Aug 6 12:30:08 2020 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 158213A0E36 for ; Thu, 6 Aug 2020 12:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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 qmswLYaIuyUI for ; Thu, 6 Aug 2020 12:30:04 -0700 (PDT) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 139F33A0E31 for ; Thu, 6 Aug 2020 12:30:04 -0700 (PDT) Received: by mail-io1-xd2d.google.com with SMTP id l1so50792860ioh.5 for ; Thu, 06 Aug 2020 12:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=+1i3YG1wbVODUY3B9JlTxBISBWXruQO7zgSbFRtp8NM=; b=WR6grT64g6L1dDMrT0GDnHv5Q6RrZsr8Fh2WxSiYQyB3WNnZphnMNi+akoKiGmt7Ep eDrNJb3gQJWwhZwkNGco1jyGL5y4w8MmU/JjhEca3F+ErUwQW01mUO0hXVM8omb/qffp pie/Qssoqn1mkdxO2lbKOhH6wkGhzszTDJmvQVgjTODBWfXCXiDY5qqQc3x5EkW05qn6 SAvbM1LY98mg3pCKuAIqOjtLdw4HZwMS1510kD0CSD7Xo4ysfROOKQ7Ybkh9B9zlRJXU j4JgJeoyXY7oHacZ6Q9D5gr+o9re0NLQeVK4U4vY5rzWqca/cjKJXJi3cxbsR6Acvyhc ES6A== 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=+1i3YG1wbVODUY3B9JlTxBISBWXruQO7zgSbFRtp8NM=; b=oI4954cGghErmhWrWCieuBsHTJ+v/lcNsHgR/DWaMBUeJQqbrXyu1DygV+gYGvZTV4 16HRdgXkw/nwG+lkhbR9Sfb7yJXjkBH4iknKoszKePnsynlCPW1a24cxcrAOmYuCjJzA bb0kL7QXm9sY242We4sgi55Dl06R60Ln2XwLbNhudxqWPcI4FAROWcuQ/ptKZbBxU+dK vMkTWt6N7Vqv6Lp8KGrLK2AyFRM+sUiXJrJfiQAZHOWsJmgKPM0frsFetjPQKZmuUppu 4ljzDnLurbYxOyt9barG9gizbTtMQ9u/lrBkWej2b+67eS+LxtfV21/OlvYfw+TMUTlI ChMw== X-Gm-Message-State: AOAM530RZflzBVDgDEmOgHvNLPSBdUigZam0r+jWPLQj4vyCasBP+0xt PciVBeCqqnb0B7dSKDskmHixTtJtuOSJgzmHmt9uq5xB44E= X-Google-Smtp-Source: ABdhPJwZ3poEIYEtACwbNshf01sMkuRm521vb7Ld/QehGPMFJAZHLwrMUOQCqry2X8IZUYhgbNmE/YaQg/wVtdD6UhQ= X-Received: by 2002:a05:6638:2391:: with SMTP id q17mr534715jat.31.1596742202994; Thu, 06 Aug 2020 12:30:02 -0700 (PDT) MIME-Version: 1.0 From: Martin Duke Date: Thu, 6 Aug 2020 12:30:02 -0700 Message-ID: To: taps WG Content-Type: multipart/alternative; boundary="000000000000ceb46005ac3a839a" Archived-At: Subject: [Taps] Review of taps-interface X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2020 19:30:06 -0000 --000000000000ceb46005ac3a839a Content-Type: text/plain; charset="UTF-8" Here is my promised "no prior knowledge" review of taps-interface. I haven't filed issues for these yet, as I suspect some of these have already been well-litigated there. The only other draft I've read is taps-arch. *High level comments*: (1) I think this conceptually headed in the right direction. (2) I found the relationship between streams and connections to be extremely murky throughout the draft, and left it not really sure how I would control a streamed transport. Section 6.4 hints suggests that opening additional streams is an alternative implementation of Clone() for transports that can do so. Does this imply that if the peer stream limit does not allow new streams, the transport should open a connection instead? How does SetNewConnectionLimit() in Sec 6.2 relate to streamed transport -- are there two levels of listener: a stream listener and a connection listener? How would opening "stream listeners" relate to the maximum number of streams the peer could open (i.e. do I have to call listen() 8 times to allow the client to open 8 streams)? Or are there no stream listeners and these "connections" just sort of appear? Skimming the -impl draft, I can see there's some text here but it is not fitting together for me. There are at least three streamed transports and it would be helpful to explain how the API conceptualizes this, perhaps in a new section. The next two major points are related to streams, so if I've missed something important above they may be complete nonsequiturs. (3) I'm not sure the priority framework really fits together. Sec 6.4 says we 'should' do something that sounds like WFQ, but 7.1.5 allows the application to decide what happens. Meanwhile message priority suggests a strict priority-based scheduler. Meanwhile, in sec 8.1.3.2 "Note that this property is not a per-message override of the connection Priority - see Section 7.1.3. Both Priority properties may interact, but can be used independently and be realized by different mechanisms." At the risk of overindexing on a partly-baked draft in httpbis, how would I implement strict priority of HTTP/3 streams over a taps API that implements QUIC? Would I need to request strict priority in *both* connection priority and message priority? Or I guess connection priority would be sufficient? (4) I found myself continually asking how I would implement foo-over-http/x using this API, and very much stumbled over ambiguity regarding HTTP 1.1 pipelining. While it's certainly possible to order messages in the proper way using this API, if I was writing this agnostically to HTTP version, it appears it would gravitate to opening a pooled TCP connection for each request/response if we ended up on HTTP/1 [because each request/response would have a clone() call]. Maybe this is OK, but I found this conclusion to be jarring. *Specific comments*: sec 4.2.2 "implementations MUST provide a method for the application to determine the entire set of possible values for each property." Is this meant to be a requirement for a machine-readable API for learning the enum, or merely a requirement for documentation? i.e. is it satisfied if the values are in the man page or comments of the C header file? sec 5. I found it curious that there is no API here for registering callbacks, or mention that this is a precondition to connection. Surely event handlers are a prerequisite? sec 5.1 I found it odd that there didn't appear to be any sort of formal list of attributes of an endpoint, just some examples. sec 5.2.7 I am not sure what this sentence means: "Disabling this property may enable to control checksum coverage later." sec 5.2.9 It would be helpful to say "Applications that neither prohibit nor require congestion should query the result and disable their own congestion control if present in the transport" sec 5.2.12 Using temporary local addresses may break various mechanisms that prove address ownership (e.g QUIC resumption tokens) and therefore impair performance as the client has to re-verify its address. sec 6.2 "After Stop() is called, the Listener can be disposed of." I don't understand the difference between calling listener.stop() and simply disposing of the object. Does this imply that there is a listener.start() that allows a configured listener to resume? sec 7.1.4 It would be helpful to clarify the relevance of control vs application data in the idle timeout -- for various reasons, the connection could stay alive regardless of how active the connection is (in fact, perhaps "keepalive" is a generally useful notion that can be exposed in the API?) sec 7.1.8 This section is missing a reference to minSendRate and minRecvRate sec 7.1.9. We're going to need an event for MTU changes. These can't simply be Send errors because the Sent event might go first, or the transport might be sending a probe with padding that doesn't correspond to a message. sec 7.2 perhaps I'm not thinking of this correctly, but should there be a way to query the peer-offered user timeout? sec 8.3.2.1 Reading the Sent event, I was pretty sure that reliable transports would deliver the event until the ack arrived. But Sec 10 most definitely does not say that. I would think that the ack would be a more useful signal, but maybe I'm in the rough on this -- certainly many transport implementations will not do this well. -Martin --000000000000ceb46005ac3a839a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here is my promised "no prior knowledge" review = of taps-interface. I haven't filed issues for these yet, as I suspect s= ome of these have already been well-litigated there.

The= only other draft I've read is taps-arch.

Hig= h level comments:

(1) I think this conceptuall= y headed in the right direction.

(2) I found the r= elationship between streams and connections to be extremely murky throughou= t the draft, and left it not really sure how I would control a streamed tra= nsport.

Section 6.4 hints suggests that opening ad= ditional streams is an alternative implementation of Clone() for transports= that can do so. Does this imply that if the peer stream limit does not all= ow new streams, the transport should open a connection instead? How does Se= tNewConnectionLimit() in Sec 6.2 relate to streamed transport -- are there = two levels of listener: a stream listener and a connection listener? How wo= uld opening "stream listeners" relate to the maximum number of st= reams the peer could open (i.e. do I have to call listen() 8 times to allow= the client to open 8 streams)? Or are there no stream listeners and these = "connections" just sort of appear?

Skimm= ing the -impl draft, I can see there's some text here but it is not fit= ting together for me. There are at least three streamed transports and it w= ould be helpful to explain how the API conceptualizes this, perhaps in a ne= w section.

The next two major points are related t= o streams, so if I've missed something important above they may be comp= lete nonsequiturs.

(3) I'm not sure the priori= ty framework really fits together.

Sec 6.4 says we= 'should' do something that sounds like WFQ, but 7.1.5 allows the a= pplication to decide=C2=A0what happens. Meanwhile message priority suggests= a strict priority-based scheduler.

Meanwhile, in = sec 8.1.3.2 "Note that this property is not a per-message override of = the=C2=A0 connection Priority - see Section 7.1.3.=C2=A0 Both Priority prop= erties
=C2=A0 =C2=A0may interact, but can be used independently and be= realized by
=C2=A0 =C2=A0different mechanisms."=C2=A0
At the risk of overindexing on a partly-baked draft in httpbis= , how would I implement strict priority of HTTP/3 streams over a taps API t= hat implements QUIC? Would I need to request strict priority=C2=A0in *both*= connection priority and message priority? Or I guess connection priority w= ould be sufficient?

(4) I found myself continually= asking how I would implement foo-over-http/x using this API, and very much= stumbled over ambiguity regarding HTTP 1.1 pipelining. While it's cert= ainly possible to order messages in the proper way using this API, if I was= writing this agnostically to HTTP version, it appears it would gravitate t= o opening a pooled TCP connection for each request/response if we ended up = on HTTP/1 [because each request/response would have a clone() call]. Maybe = this is OK, but I found this conclusion to be jarring.

=
Specific comments:

sec 4.2.2
= "implementations MUST provide a
=C2=A0 =C2=A0 =C2=A0 method for the= application to determine the entire set of possible
=C2=A0 =C2=A0 =C2= =A0 values for each property."

Is this meant = to be a requirement for a machine-readable API for learning the enum, or me= rely a requirement for documentation? i.e. is it satisfied=C2=A0if the valu= es are in the man page or comments of the C header file?

sec 5.
I found it curious that there is no API here for re= gistering callbacks, or mention that this is a precondition to connection. = Surely event handlers are a prerequisite?

sec 5.1<= /div>
I found it odd that there didn't appear to be any sort of for= mal list of attributes of an endpoint, just some examples.

sec 5.2.7
I am not sure what this sentence means: &q= uot;Disabling this property may enable to control checksum coverage later.&= quot;

sec 5.2.9
It would be helpful to s= ay "Applications that neither prohibit nor require congestion should q= uery the result and disable their own congestion control if present in the = transport"

sec 5.2.12
Using tempora= ry local addresses may break various mechanisms that prove address ownershi= p (e.g QUIC resumption tokens) and therefore impair performance as the clie= nt has to re-verify its address.

sec 6.2=C2= =A0
"After Stop() is called, the Listener can be disposed of= ." I don't understand the difference between calling listener.stop= () and simply disposing of the object. Does this imply that there is a list= ener.start() that allows a configured listener to resume?
<= br>
sec 7.1.4
It would be helpful to clarif= y the relevance of control vs application data in the idle timeout -- for v= arious reasons, the connection could stay alive regardless of how active th= e connection is (in fact, perhaps "keepalive" is a generally usef= ul notion that can be exposed in the API?)

sec 7.1= .8
This section is missing a reference to minSendRate and minRecv= Rate

sec 7.1.9.
We're going to need = an event for MTU changes. These can't simply be Send errors because the= Sent event might go first, or the transport might be sending a probe with = padding that doesn't correspond to a message.

= sec 7.2
perhaps I'm not thinking of this correctly, but shoul= d there be a way to query the peer-offered user timeout?

sec 8.3.2.1
Reading the Sent event, I was pretty sure that= reliable transports would deliver the event until the ack arrived. But Sec= 10 most definitely does not say that. I would think that the ack would be = a more useful signal, but maybe I'm in the rough on this -- certainly m= any transport implementations will not do this well.

-Martin
--000000000000ceb46005ac3a839a-- From nobody Fri Aug 7 01:02:18 2020 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 8C3973A0D00 for ; Fri, 7 Aug 2020 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 kUXDIynS86YN for ; Fri, 7 Aug 2020 01:02:15 -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 246163A0CF8 for ; Fri, 7 Aug 2020 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 1k3xIJ-0002Ih-Ks for taps@ietf.org; Fri, 07 Aug 2020 08:00:03 +0000 Content-Type: multipart/alternative; boundary="===============3253979420106624831==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 07 Aug 2020 08:00:03 +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, 07 Aug 2020 08:02:17 -0000 --===============3253979420106624831== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Pull requests ------------- * ietf-tapswg/api-drafts (+5/-3/=F0=9F=92=AC0) 5 pull requests submitted: - More nits (by martinduke) https://github.com/ietf-tapswg/api-drafts/pull/617 = - Fix typo (by martinduke) https://github.com/ietf-tapswg/api-drafts/pull/616 = - Nits in 5.2 (by martinduke) https://github.com/ietf-tapswg/api-drafts/pull/615 = - Edits on Section on Handling Path Changes (by mirjak) https://github.com/ietf-tapswg/api-drafts/pull/614 = - Typo (by martinduke) https://github.com/ietf-tapswg/api-drafts/pull/613 = 3 pull requests merged: - Nits in 5.2 https://github.com/ietf-tapswg/api-drafts/pull/615 = - Fix typo https://github.com/ietf-tapswg/api-drafts/pull/616 = - Typo https://github.com/ietf-tapswg/api-drafts/pull/613 = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============3253979420106624831== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday August 07, 2020

Pull requests

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

5 pull requests submitted:

3 pull requests merged:

Repositories tracked by this digest:

--===============3253979420106624831==-- From nobody Fri Aug 7 01:21:44 2020 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 374F73A0D37 for ; Fri, 7 Aug 2020 01:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 rKdK2daYc_4v for ; Fri, 7 Aug 2020 01:21:39 -0700 (PDT) Received: from mail-out01.uio.no (mail-out01.uio.no [IPv6:2001:700:100:10::50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 526513A0D46 for ; Fri, 7 Aug 2020 01:21:39 -0700 (PDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out01.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1k3xdA-0002YI-99; Fri, 07 Aug 2020 10:21:36 +0200 Received: from ti0182q160-0624.bb.online.no ([109.189.132.119] helo=[192.168.1.5]) by mail-mx12.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from ) id 1k3xd8-000FZF-Br; Fri, 07 Aug 2020 10:21:36 +0200 From: Michael Welzl Message-Id: <90C068BA-3B20-48A1-94C2-6BF915BD35CB@ifi.uio.no> Content-Type: multipart/alternative; boundary="Apple-Mail=_98617D70-B006-4FF3-A51B-E791270FBCB4" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Fri, 7 Aug 2020 10:21:33 +0200 In-Reply-To: Cc: "taps@ietf.org" To: Martin Duke References: X-Mailer: Apple Mail (2.3445.104.14) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 109.189.132.119 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.132.119; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.5]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=-0.000, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 207C6F3C4D9B17172F8B792332A39F27F1554DB5 Archived-At: Subject: Re: [Taps] Review of taps-interface X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 08:21:42 -0000 --Apple-Mail=_98617D70-B006-4FF3-A51B-E791270FBCB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Martin, Thanks much for this detailed review! - and for the many interesting = questions you=E2=80=99re raising; you discovered a few important holes = there. E.g., I believe we just haven=E2=80=99t discussed stream limits; = I would have thought that that=E2=80=99s an implementation matter, but = the fact that you bring it up in a review of the interface draft is a = reminder that applications may want to be aware of this behavior. (as a quick answer to this particular item, in my opinion Clone() should = fail if the stream limit is exceeded - getting a mix of Connections and = streams, altogether grouped is surely not what anyone would want or = expect; e.g. priorities within the group won=E2=80=99t work out = anymore). Note that the idea is that an application can query for what = it got if it=E2=80=99s interested in that level of detail. Now, for addressing the comments, I think we should just split them up = by topic into issues for the repository, and then address them one by = one. Thanks again! Cheers, Michael > On Aug 6, 2020, at 9:30 PM, Martin Duke = wrote: >=20 > Here is my promised "no prior knowledge" review of taps-interface. I = haven't filed issues for these yet, as I suspect some of these have = already been well-litigated there. >=20 > The only other draft I've read is taps-arch. >=20 > High level comments: >=20 > (1) I think this conceptually headed in the right direction. >=20 > (2) I found the relationship between streams and connections to be = extremely murky throughout the draft, and left it not really sure how I = would control a streamed transport. >=20 > Section 6.4 hints suggests that opening additional streams is an = alternative implementation of Clone() for transports that can do so. = Does this imply that if the peer stream limit does not allow new = streams, the transport should open a connection instead? How does = SetNewConnectionLimit() in Sec 6.2 relate to streamed transport -- are = there two levels of listener: a stream listener and a connection = listener? How would opening "stream listeners" relate to the maximum = number of streams the peer could open (i.e. do I have to call listen() 8 = times to allow the client to open 8 streams)? Or are there no stream = listeners and these "connections" just sort of appear? >=20 > Skimming the -impl draft, I can see there's some text here but it is = not fitting together for me. There are at least three streamed = transports and it would be helpful to explain how the API conceptualizes = this, perhaps in a new section. >=20 > The next two major points are related to streams, so if I've missed = something important above they may be complete nonsequiturs. >=20 > (3) I'm not sure the priority framework really fits together. >=20 > Sec 6.4 says we 'should' do something that sounds like WFQ, but 7.1.5 = allows the application to decide what happens. Meanwhile message = priority suggests a strict priority-based scheduler. >=20 > Meanwhile, in sec 8.1.3.2 "Note that this property is not a = per-message override of the connection Priority - see Section 7.1.3. = Both Priority properties > may interact, but can be used independently and be realized by > different mechanisms."=20 >=20 > At the risk of overindexing on a partly-baked draft in httpbis, how = would I implement strict priority of HTTP/3 streams over a taps API that = implements QUIC? Would I need to request strict priority in *both* = connection priority and message priority? Or I guess connection priority = would be sufficient? >=20 > (4) I found myself continually asking how I would implement = foo-over-http/x using this API, and very much stumbled over ambiguity = regarding HTTP 1.1 pipelining. While it's certainly possible to order = messages in the proper way using this API, if I was writing this = agnostically to HTTP version, it appears it would gravitate to opening a = pooled TCP connection for each request/response if we ended up on HTTP/1 = [because each request/response would have a clone() call]. Maybe this is = OK, but I found this conclusion to be jarring. >=20 > Specific comments: >=20 > sec 4.2.2 > "implementations MUST provide a > method for the application to determine the entire set of = possible > values for each property." >=20 > Is this meant to be a requirement for a machine-readable API for = learning the enum, or merely a requirement for documentation? i.e. is it = satisfied if the values are in the man page or comments of the C header = file? >=20 > sec 5. > I found it curious that there is no API here for registering = callbacks, or mention that this is a precondition to connection. Surely = event handlers are a prerequisite? >=20 > sec 5.1 > I found it odd that there didn't appear to be any sort of formal list = of attributes of an endpoint, just some examples. >=20 > sec 5.2.7 > I am not sure what this sentence means: "Disabling this property may = enable to control checksum coverage later." >=20 > sec 5.2.9 > It would be helpful to say "Applications that neither prohibit nor = require congestion should query the result and disable their own = congestion control if present in the transport" >=20 > sec 5.2.12 > Using temporary local addresses may break various mechanisms that = prove address ownership (e.g QUIC resumption tokens) and therefore = impair performance as the client has to re-verify its address. >=20 > sec 6.2=20 > "After Stop() is called, the Listener can be disposed of.." I don't = understand the difference between calling listener.stop() and simply = disposing of the object. Does this imply that there is a = listener.start() that allows a configured listener to resume? >=20 > sec 7.1.4 > It would be helpful to clarify the relevance of control vs application = data in the idle timeout -- for various reasons, the connection could = stay alive regardless of how active the connection is (in fact, perhaps = "keepalive" is a generally useful notion that can be exposed in the = API?) >=20 > sec 7.1..8 > This section is missing a reference to minSendRate and minRecvRate >=20 > sec 7.1.9. > We're going to need an event for MTU changes. These can't simply be = Send errors because the Sent event might go first, or the transport = might be sending a probe with padding that doesn't correspond to a = message. >=20 > sec 7.2 > perhaps I'm not thinking of this correctly, but should there be a way = to query the peer-offered user timeout? >=20 > sec 8.3.2.1 > Reading the Sent event, I was pretty sure that reliable transports = would deliver the event until the ack arrived. But Sec 10 most = definitely does not say that. I would think that the ack would be a more = useful signal, but maybe I'm in the rough on this -- certainly many = transport implementations will not do this well. >=20 > -Martin > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_98617D70-B006-4FF3-A51B-E791270FBCB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Martin,

Thanks much = for this detailed review!   - and for the many interesting = questions you=E2=80=99re raising; you discovered a few important holes = there. E.g., I believe we just haven=E2=80=99t discussed stream limits; = I would have thought that that=E2=80=99s an implementation matter, but = the fact that you bring it up in a review of the interface draft is a = reminder that applications may want to be aware of this = behavior.
(as a quick answer to this particular = item, in my opinion Clone() should fail if the stream limit is exceeded = - getting a mix of Connections and streams, altogether grouped is surely = not what anyone would want or expect; e.g. priorities within the group = won=E2=80=99t work out anymore). Note that the idea is that an = application can query for what it got if it=E2=80=99s interested in that = level of detail.

Now, for addressing the comments, I think we should just = split them up by topic into issues for the repository, and then address = them one by one.

Thanks = again!

Cheers,
Michael


On Aug 6, 2020, at 9:30 PM, Martin Duke = <martin.h.duke@gmail.com> wrote:

Here is my promised "no prior knowledge" review of = taps-interface. I haven't filed issues for these yet, as I suspect some = of these have already been well-litigated there.

The only other draft I've read is = taps-arch.

High level comments:
(1) I think this conceptually headed = in the right direction.

(2) I found the relationship between streams and connections = to be extremely murky throughout the draft, and left it not really sure = how I would control a streamed transport.

Section 6.4 hints suggests that opening = additional streams is an alternative implementation of Clone() for = transports that can do so. Does this imply that if the peer stream limit = does not allow new streams, the transport should open a connection = instead? How does SetNewConnectionLimit() in Sec 6.2 relate to streamed = transport -- are there two levels of listener: a stream listener and a = connection listener? How would opening "stream listeners" relate to the = maximum number of streams the peer could open (i.e. do I have to call = listen() 8 times to allow the client to open 8 streams)? Or are there no = stream listeners and these "connections" just sort of appear?

Skimming the -impl = draft, I can see there's some text here but it is not fitting together = for me. There are at least three streamed transports and it would be = helpful to explain how the API conceptualizes this, perhaps in a new = section.

The = next two major points are related to streams, so if I've missed = something important above they may be complete nonsequiturs.

(3) I'm not sure the = priority framework really fits together.

Sec 6.4 says we 'should' do something = that sounds like WFQ, but 7.1.5 allows the application to = decide what happens. Meanwhile message priority suggests a strict = priority-based scheduler.

Meanwhile, in sec 8.1.3.2 "Note that this property is not a = per-message override of the  connection Priority - see Section = 7.1.3.  Both Priority properties
   may interact, = but can be used independently and be realized by
  =  different mechanisms." 

At the risk of overindexing on a = partly-baked draft in httpbis, how would I implement strict priority of = HTTP/3 streams over a taps API that implements QUIC? Would I need to = request strict priority in *both* connection priority and message = priority? Or I guess connection priority would be sufficient?

(4) I found myself = continually asking how I would implement foo-over-http/x using this API, = and very much stumbled over ambiguity regarding HTTP 1.1 pipelining. = While it's certainly possible to order messages in the proper way using = this API, if I was writing this agnostically to HTTP version, it appears = it would gravitate to opening a pooled TCP connection for each = request/response if we ended up on HTTP/1 [because each request/response = would have a clone() call]. Maybe this is OK, but I found this = conclusion to be jarring.

Specific comments:

sec 4.2.2
"implementations MUST provide a
    =   method for the application to determine the entire set of = possible
      values for each = property."

Is = this meant to be a requirement for a machine-readable API for learning = the enum, or merely a requirement for documentation? i.e. is it = satisfied if the values are in the man page or comments of the C = header file?

sec= 5.
I found it curious that there is no API here = for registering callbacks, or mention that this is a precondition to = connection. Surely event handlers are a prerequisite?

sec 5.1
I found it odd that there didn't appear to be any sort of = formal list of attributes of an endpoint, just some examples.

sec 5.2.7
I am not sure what this sentence means: = "Disabling this property may enable to control checksum coverage = later."

sec = 5.2.9
It would be helpful to say "Applications that = neither prohibit nor require congestion should query the result and = disable their own congestion control if present in the = transport"

sec = 5.2.12
Using temporary local addresses may break = various mechanisms that prove address ownership (e.g QUIC resumption = tokens) and therefore impair performance as the client has to re-verify = its address.

sec 6.2 
"After = Stop() is called, the Listener can be disposed of.." I don't understand = the difference between calling listener.stop() and simply disposing of = the object. Does this imply that there is a listener.start() that allows = a configured listener to resume?

sec 7.1.4
It would be helpful to clarify the relevance of control vs = application data in the idle timeout -- for various reasons, the = connection could stay alive regardless of how active the connection is = (in fact, perhaps "keepalive" is a generally useful notion that can be = exposed in the API?)

sec 7.1..8
This section is missing a = reference to minSendRate and minRecvRate

sec 7.1.9.
We're = going to need an event for MTU changes. These can't simply be Send = errors because the Sent event might go first, or the transport might be = sending a probe with padding that doesn't correspond to a = message.

sec = 7.2
perhaps I'm not thinking of this correctly, but = should there be a way to query the peer-offered user timeout?

sec 8.3.2.1
Reading the Sent event, I was pretty sure that reliable = transports would deliver the event until the ack arrived. But Sec 10 = most definitely does not say that. I would think that the ack would be a = more useful signal, but maybe I'm in the rough on this -- certainly many = transport implementations will not do this well.

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

= --Apple-Mail=_98617D70-B006-4FF3-A51B-E791270FBCB4-- From nobody Fri Aug 7 09:25:43 2020 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 ADDBD3A0AB0 for ; Fri, 7 Aug 2020 09:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 NJEXjHCpPds7 for ; Fri, 7 Aug 2020 09:25:39 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 3E45E3A0AA5 for ; Fri, 7 Aug 2020 09:25:11 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id l17so2460100iok.7 for ; Fri, 07 Aug 2020 09:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dXyxO121AEatAcLNxoFlCy++/bmlE4qCNSE4hAAnc3Y=; b=C6Cn1PNgIpu6cXoTMeLtiFHHhk6iXKrM+bHDQX0FKkDesZH9rsRja3aX8oG27yP3cq j6uQ68r7w0LQ1fPu4nibwvqtesaQgCjLfG+gdT50uBgq6cmG3Ff1sgoGzRmyzIp7rB/7 Uu/nagKINEA6E/qxriOaQa2FUM83tHWeNuhqVPJfk9FD/JcjJysqTcBu93CaWCrRhDm/ PIarTaxMwgjOke85/SYHnLnBEwuLlZfWHyOewh/9bZo0pp7Y++o/qfdkdQTwNIQYXcZY f0OuICXSnteC14Joy5F/FMsb9gxtX6BtLcVizEV//MS5NNBvgG+j6c2YbSr+S/Z6i/pa h5Og== 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=dXyxO121AEatAcLNxoFlCy++/bmlE4qCNSE4hAAnc3Y=; b=tX34zatWUnila1yTdgM1i+ZRf1aRsnOOlm7pCTYksiZMgRM7FqSYMJPdcgJJsGnz6U YlcDk8q5AaA+IemGnn+uFl7waVeRE9dFMlAhgE+JX8VtkMuigO7PaOBIdBJbQL96Ypx8 sCTnSbssSqIkvqa3Op7n4DMNnt4mkPO7VV6Hn69N25qCRRwUn4a8ZEyAtCi9+C44i8My HBht8LClDBjTavsa9ENpYA/36kvCInImtOUvz5GkNg2Ju/e0rEonv9lWWSGjJKjfhBj3 giw1jOiV5wcRtCYcwGX9rjfoSNCySOA5lMNMz4lqnU9LYE/E05RCvXYUeHuEI/xu0pZZ qJKQ== X-Gm-Message-State: AOAM530Pu/b1HolpLpUUB3IiAqukpY1XtxxpUSmDpoEB4CJ8c7TQByNS 46JGp+bDCf8iu2IhtgRbXaX9eVogYm88q0De0Bc= X-Google-Smtp-Source: ABdhPJyzoKaNevlf8bagkFUwzjmh4D7OgGbYNPBpRkMP5mCZ7DpjGw9pVWtCaPBKLRf1GU3g9RKMF53G/Wk1ilwkAkU= X-Received: by 2002:a5d:824f:: with SMTP id n15mr5004682ioo.95.1596817510571; Fri, 07 Aug 2020 09:25:10 -0700 (PDT) MIME-Version: 1.0 References: <90C068BA-3B20-48A1-94C2-6BF915BD35CB@ifi.uio.no> In-Reply-To: <90C068BA-3B20-48A1-94C2-6BF915BD35CB@ifi.uio.no> From: Martin Duke Date: Fri, 7 Aug 2020 09:25:11 -0700 Message-ID: To: Michael Welzl Cc: "taps@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007d241205ac4c0c9e" Archived-At: Subject: Re: [Taps] Review of taps-interface X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 16:25:42 -0000 --0000000000007d241205ac4c0c9e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OK, I'll file github issues On Fri, Aug 7, 2020 at 1:21 AM Michael Welzl wrote: > Hi Martin, > > Thanks much for this detailed review! - and for the many interesting > questions you=E2=80=99re raising; you discovered a few important holes th= ere. E.g., > I believe we just haven=E2=80=99t discussed stream limits; I would have t= hought > that that=E2=80=99s an implementation matter, but the fact that you bring= it up in > a review of the interface draft is a reminder that applications may want = to > be aware of this behavior. > (as a quick answer to this particular item, in my opinion Clone() should > fail if the stream limit is exceeded - getting a mix of Connections and > streams, altogether grouped is surely not what anyone would want or expec= t; > e.g. priorities within the group won=E2=80=99t work out anymore). Note th= at the > idea is that an application can query for what it got if it=E2=80=99s int= erested in > that level of detail. > > Now, for addressing the comments, I think we should just split them up by > topic into issues for the repository, and then address them one by one. > > Thanks again! > > Cheers, > Michael > > > On Aug 6, 2020, at 9:30 PM, Martin Duke wrote: > > Here is my promised "no prior knowledge" review of taps-interface. I > haven't filed issues for these yet, as I suspect some of these have alrea= dy > been well-litigated there. > > The only other draft I've read is taps-arch. > > *High level comments*: > > (1) I think this conceptually headed in the right direction. > > (2) I found the relationship between streams and connections to be > extremely murky throughout the draft, and left it not really sure how I > would control a streamed transport. > > Section 6.4 hints suggests that opening additional streams is an > alternative implementation of Clone() for transports that can do so. Does > this imply that if the peer stream limit does not allow new streams, the > transport should open a connection instead? How does > SetNewConnectionLimit() in Sec 6.2 relate to streamed transport -- are > there two levels of listener: a stream listener and a connection listener= ? > How would opening "stream listeners" relate to the maximum number of > streams the peer could open (i.e. do I have to call listen() 8 times to > allow the client to open 8 streams)? Or are there no stream listeners and > these "connections" just sort of appear? > > Skimming the -impl draft, I can see there's some text here but it is not > fitting together for me. There are at least three streamed transports and > it would be helpful to explain how the API conceptualizes this, perhaps i= n > a new section. > > The next two major points are related to streams, so if I've missed > something important above they may be complete nonsequiturs. > > (3) I'm not sure the priority framework really fits together. > > Sec 6.4 says we 'should' do something that sounds like WFQ, but 7.1.5 > allows the application to decide what happens. Meanwhile message priority > suggests a strict priority-based scheduler. > > Meanwhile, in sec 8.1.3.2 "Note that this property is not a per-message > override of the connection Priority - see Section 7.1.3. Both Priority > properties > may interact, but can be used independently and be realized by > different mechanisms." > > At the risk of overindexing on a partly-baked draft in httpbis, how would > I implement strict priority of HTTP/3 streams over a taps API that > implements QUIC? Would I need to request strict priority in *both* > connection priority and message priority? Or I guess connection priority > would be sufficient? > > (4) I found myself continually asking how I would implement > foo-over-http/x using this API, and very much stumbled over ambiguity > regarding HTTP 1.1 pipelining. While it's certainly possible to order > messages in the proper way using this API, if I was writing this > agnostically to HTTP version, it appears it would gravitate to opening a > pooled TCP connection for each request/response if we ended up on HTTP/1 > [because each request/response would have a clone() call]. Maybe this is > OK, but I found this conclusion to be jarring. > > *Specific comments*: > > sec 4.2.2 > "implementations MUST provide a > method for the application to determine the entire set of possible > values for each property." > > Is this meant to be a requirement for a machine-readable API for learning > the enum, or merely a requirement for documentation? i.e. is it > satisfied if the values are in the man page or comments of the C header > file? > > sec 5. > I found it curious that there is no API here for registering callbacks, o= r > mention that this is a precondition to connection. Surely event handlers > are a prerequisite? > > sec 5.1 > I found it odd that there didn't appear to be any sort of formal list of > attributes of an endpoint, just some examples. > > sec 5.2.7 > I am not sure what this sentence means: "Disabling this property may > enable to control checksum coverage later." > > sec 5.2.9 > It would be helpful to say "Applications that neither prohibit nor requir= e > congestion should query the result and disable their own congestion contr= ol > if present in the transport" > > sec 5.2.12 > Using temporary local addresses may break various mechanisms that prove > address ownership (e.g QUIC resumption tokens) and therefore impair > performance as the client has to re-verify its address. > > sec 6.2 > "After Stop() is called, the Listener can be disposed of.." I don't > understand the difference between calling listener.stop() and simply > disposing of the object. Does this imply that there is a listener.start() > that allows a configured listener to resume? > > sec 7.1.4 > It would be helpful to clarify the relevance of control vs application > data in the idle timeout -- for various reasons, the connection could sta= y > alive regardless of how active the connection is (in fact, perhaps > "keepalive" is a generally useful notion that can be exposed in the API?) > > sec 7.1..8 > This section is missing a reference to minSendRate and minRecvRate > > sec 7.1.9. > We're going to need an event for MTU changes. These can't simply be Send > errors because the Sent event might go first, or the transport might be > sending a probe with padding that doesn't correspond to a message. > > sec 7.2 > perhaps I'm not thinking of this correctly, but should there be a way to > query the peer-offered user timeout? > > sec 8.3.2.1 > Reading the Sent event, I was pretty sure that reliable transports would > deliver the event until the ack arrived. But Sec 10 most definitely does > not say that. I would think that the ack would be a more useful signal, b= ut > maybe I'm in the rough on this -- certainly many transport implementation= s > will not do this well. > > -Martin > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > > > --0000000000007d241205ac4c0c9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, I'll file github issues

On Fri, Aug 7, 2020 at 1:21= AM Michael Welzl <michawe@ifi.uio= .no> wrote:
Hi Martin,

= Thanks much for this detailed review! =C2=A0 - and for the many interesting= questions you=E2=80=99re raising; you discovered a few important holes the= re. E.g., I believe we just haven=E2=80=99t discussed stream limits; I woul= d have thought that that=E2=80=99s an implementation matter, but the fact t= hat you bring it up in a review of the interface draft is a reminder that a= pplications may want to be aware of this behavior.
(as a quick an= swer to this particular item, in my opinion Clone() should fail if the stre= am limit is exceeded - getting a mix of Connections and streams, altogether= grouped is surely not what anyone would want or expect; e.g. priorities wi= thin the group won=E2=80=99t work out anymore). Note that the idea is that = an application can query for what it got if it=E2=80=99s interested in that= level of detail.

Now, for addressing the comments= , I think we should just split them up by topic into issues for the reposit= ory, and then address them one by one.

Thanks again!

Cheers,
Michael

On Aug 6, 2020, at 9:30 PM, Martin Duke &l= t;martin.h.duk= e@gmail.com> wrote:

Here is my promis= ed "no prior knowledge" review of taps-interface. I haven't f= iled issues for these yet, as I suspect some of these have already been wel= l-litigated there.

The only other draft I've read is= taps-arch.

High level comments:
(1) I think this conceptually headed in the right direction.

(2) I found the relationship between streams and co= nnections to be extremely murky throughout the draft, and left it not reall= y sure how I would control a streamed transport.

S= ection 6.4 hints suggests that opening additional streams is an alternative= implementation of Clone() for transports that can do so. Does this imply t= hat if the peer stream limit does not allow new streams, the transport shou= ld open a connection instead? How does SetNewConnectionLimit() in Sec 6.2 r= elate to streamed transport -- are there two levels of listener: a stream l= istener and a connection listener? How would opening "stream listeners= " relate to the maximum number of streams the peer could open (i.e. do= I have to call listen() 8 times to allow the client to open 8 streams)? Or= are there no stream listeners and these "connections" just sort = of appear?

Skimming the -impl draft, I can see the= re's some text here but it is not fitting together for me. There are at= least three streamed transports and it would be helpful to explain how the= API conceptualizes this, perhaps in a new section.

The next two major points are related to streams, so if I've missed s= omething important above they may be complete nonsequiturs.

<= /div>
(3) I'm not sure the priority framework really fits together.=

Sec 6.4 says we 'should' do something tha= t sounds like WFQ, but 7.1.5 allows the application to decide=C2=A0what hap= pens. Meanwhile message priority suggests a strict priority-based scheduler= .

Meanwhile, in sec 8.1.3.2 "Note that this p= roperty is not a per-message override of the=C2=A0 connection Priority - se= e Section 7.1.3.=C2=A0 Both Priority properties
=C2=A0 =C2=A0may inter= act, but can be used independently and be realized by
=C2=A0 =C2=A0diffe= rent mechanisms."=C2=A0

At the risk of overin= dexing on a partly-baked draft in httpbis, how would I implement strict pri= ority of HTTP/3 streams over a taps API that implements QUIC? Would I need = to request strict priority=C2=A0in *both* connection priority and message p= riority? Or I guess connection priority would be sufficient?

=
(4) I found myself continually asking how I would implement foo-= over-http/x using this API, and very much stumbled over ambiguity regarding= HTTP 1.1 pipelining. While it's certainly possible to order messages i= n the proper way using this API, if I was writing this agnostically to HTTP= version, it appears it would gravitate to opening a pooled TCP connection = for each request/response if we ended up on HTTP/1 [because each request/re= sponse would have a clone() call]. Maybe this is OK, but I found this concl= usion to be jarring.

Specific comments:

sec 4.2.2
"implementations MUST provide= a
=C2=A0 =C2=A0 =C2=A0 method for the application to determine the enti= re set of possible
=C2=A0 =C2=A0 =C2=A0 values for each property."<= /div>

Is this meant to be a requirement for a machine-re= adable API for learning the enum, or merely a requirement for documentation= ? i.e. is it satisfied=C2=A0if the values are in the man page or comments o= f the C header file?

sec 5.
I found it c= urious that there is no API here for registering callbacks, or mention that= this is a precondition to connection. Surely event handlers are a prerequi= site?

sec 5.1
I found it odd that there = didn't appear to be any sort of formal list of attributes of an endpoin= t, just some examples.

sec 5.2.7
I a= m not sure what this sentence means: "Disabling this property may enab= le to control checksum coverage later."

sec 5= .2.9
It would be helpful to say "Applications that neither p= rohibit nor require congestion should query the result and disable their ow= n congestion control if present in the transport"

=
sec 5.2.12
Using temporary local addresses may break various= mechanisms that prove address ownership (e.g QUIC resumption tokens) and t= herefore impair performance as the client has to re-verify its address.

sec 6.2=C2=A0
"After Stop() is ca= lled, the Listener can be disposed of.." I don't understand the di= fference between calling listener.stop() and simply disposing of the object= . Does this imply that there is a listener.start() that allows a configured= listener to resume?

sec 7.1.4
It would be helpful to clarify the relevance of control vs applica= tion data in the idle timeout -- for various reasons, the connection could = stay alive regardless of how active the connection is (in fact, perhaps &qu= ot;keepalive" is a generally useful notion that can be exposed in the = API?)

sec 7.1..8
This section is missing= a reference to minSendRate and minRecvRate

sec 7.= 1.9.
We're going to need an event for MTU changes. These can&= #39;t simply be Send errors because the Sent event might go first, or the t= ransport might be sending a probe with padding that doesn't correspond = to a message.

sec 7.2
perhaps I'm no= t thinking of this correctly, but should there be a way to query the peer-o= ffered user timeout?

sec 8.3.2.1
Reading= the Sent event, I was pretty sure that reliable transports would deliver t= he event until the ack arrived. But Sec 10 most definitely does not say tha= t. I would think that the ack would be a more useful signal, but maybe I= 9;m in the rough on this -- certainly many transport implementations will n= ot do this well.

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

--0000000000007d241205ac4c0c9e-- From nobody Fri Aug 7 12:30:02 2020 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 7F4F53A0DF2 for ; Fri, 7 Aug 2020 12:30:01 -0700 (PDT) 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, MIME_QP_LONG_LINE=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 GT4055QDMqZr for ; Fri, 7 Aug 2020 12:29:58 -0700 (PDT) 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 03C863A0AD8 for ; Fri, 7 Aug 2020 12:29:57 -0700 (PDT) Received: from mail-mx06.uio.no ([129.240.10.40]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1k483u-0009do-R8; Fri, 07 Aug 2020 21:29:54 +0200 Received: from telia-2e0fc8-227.connect.netcom.no ([46.15.200.227] helo=[100.103.249.212]) by mail-mx06.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from ) id 1k483r-0008Pq-P6; Fri, 07 Aug 2020 21:29:54 +0200 Content-Type: multipart/alternative; boundary=Apple-Mail-BA87ACB6-EE6B-47E7-9B14-77E8876E2CAE Content-Transfer-Encoding: 7bit From: Michael Welzl Mime-Version: 1.0 (1.0) Date: Fri, 7 Aug 2020 21:29:50 +0200 Message-Id: <9EF70105-D21E-4B11-9A15-D3A22BCD52F1@ifi.uio.no> References: Cc: "taps@ietf.org" In-Reply-To: To: Martin Duke X-Mailer: iPhone Mail (17F80) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx06.uio.no: 46.15.200.227 is neither permitted nor denied by domain of ifi.uio.no) client-ip=46.15.200.227; envelope-from=michawe@ifi.uio.no; helo=[100.103.249.212]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: B8504C3581E67AD0100B252EE4FE7E05F6EA6671 Archived-At: Subject: Re: [Taps] Review of taps-interface X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2020 19:30:02 -0000 --Apple-Mail-BA87ACB6-EE6B-47E7-9B14-77E8876E2CAE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks so much for doing this! This was meant as a todo item for us, or me,= not you! Cheers, Michael Sent from my iPhone > On 7 Aug 2020, at 18:25, Martin Duke wrote: >=20 > =EF=BB=BF > OK, I'll file github issues >=20 >> On Fri, Aug 7, 2020 at 1:21 AM Michael Welzl wrote: >> Hi Martin, >>=20 >> Thanks much for this detailed review! - and for the many interesting qu= estions you=E2=80=99re raising; you discovered a few important holes there. E= .g., I believe we just haven=E2=80=99t discussed stream limits; I would have= thought that that=E2=80=99s an implementation matter, but the fact that you= bring it up in a review of the interface draft is a reminder that applicati= ons may want to be aware of this behavior. >> (as a quick answer to this particular item, in my opinion Clone() should f= ail if the stream limit is exceeded - getting a mix of Connections and strea= ms, altogether grouped is surely not what anyone would want or expect; e.g. p= riorities within the group won=E2=80=99t work out anymore). Note that the id= ea is that an application can query for what it got if it=E2=80=99s interest= ed in that level of detail. >>=20 >> Now, for addressing the comments, I think we should just split them up by= topic into issues for the repository, and then address them one by one. >>=20 >> Thanks again! >>=20 >> Cheers, >> Michael >>=20 >>=20 >>> On Aug 6, 2020, at 9:30 PM, Martin Duke wrote:= >>>=20 >>> Here is my promised "no prior knowledge" review of taps-interface. I hav= en't filed issues for these yet, as I suspect some of these have already bee= n well-litigated there. >>>=20 >>> The only other draft I've read is taps-arch. >>>=20 >>> High level comments: >>>=20 >>> (1) I think this conceptually headed in the right direction. >>>=20 >>> (2) I found the relationship between streams and connections to be extre= mely murky throughout the draft, and left it not really sure how I would con= trol a streamed transport. >>>=20 >>> Section 6.4 hints suggests that opening additional streams is an alterna= tive implementation of Clone() for transports that can do so. Does this impl= y that if the peer stream limit does not allow new streams, the transport sh= ould open a connection instead? How does SetNewConnectionLimit() in Sec 6.2 r= elate to streamed transport -- are there two levels of listener: a stream li= stener and a connection listener? How would opening "stream listeners" relat= e to the maximum number of streams the peer could open (i.e. do I have to ca= ll listen() 8 times to allow the client to open 8 streams)? Or are there no s= tream listeners and these "connections" just sort of appear? >>>=20 >>> Skimming the -impl draft, I can see there's some text here but it is not= fitting together for me. There are at least three streamed transports and i= t would be helpful to explain how the API conceptualizes this, perhaps in a n= ew section. >>>=20 >>> The next two major points are related to streams, so if I've missed some= thing important above they may be complete nonsequiturs. >>>=20 >>> (3) I'm not sure the priority framework really fits together. >>>=20 >>> Sec 6.4 says we 'should' do something that sounds like WFQ, but 7.1.5 al= lows the application to decide what happens. Meanwhile message priority sugg= ests a strict priority-based scheduler. >>>=20 >>> Meanwhile, in sec 8.1.3.2 "Note that this property is not a per-message o= verride of the connection Priority - see Section 7.1.3. Both Priority prop= erties >>> may interact, but can be used independently and be realized by >>> different mechanisms."=20 >>>=20 >>> At the risk of overindexing on a partly-baked draft in httpbis, how woul= d I implement strict priority of HTTP/3 streams over a taps API that impleme= nts QUIC? Would I need to request strict priority in *both* connection prior= ity and message priority? Or I guess connection priority would be sufficient= ? >>>=20 >>> (4) I found myself continually asking how I would implement foo-over-htt= p/x using this API, and very much stumbled over ambiguity regarding HTTP 1.1= pipelining. While it's certainly possible to order messages in the proper w= ay using this API, if I was writing this agnostically to HTTP version, it ap= pears it would gravitate to opening a pooled TCP connection for each request= /response if we ended up on HTTP/1 [because each request/response would have= a clone() call]. Maybe this is OK, but I found this conclusion to be jarrin= g. >>>=20 >>> Specific comments: >>>=20 >>> sec 4.2.2 >>> "implementations MUST provide a >>> method for the application to determine the entire set of possible= >>> values for each property." >>>=20 >>> Is this meant to be a requirement for a machine-readable API for learnin= g the enum, or merely a requirement for documentation? i.e. is it satisfied i= f the values are in the man page or comments of the C header file? >>>=20 >>> sec 5. >>> I found it curious that there is no API here for registering callbacks, o= r mention that this is a precondition to connection. Surely event handlers a= re a prerequisite? >>>=20 >>> sec 5.1 >>> I found it odd that there didn't appear to be any sort of formal list of= attributes of an endpoint, just some examples. >>>=20 >>> sec 5.2.7 >>> I am not sure what this sentence means: "Disabling this property may ena= ble to control checksum coverage later." >>>=20 >>> sec 5.2.9 >>> It would be helpful to say "Applications that neither prohibit nor requi= re congestion should query the result and disable their own congestion contr= ol if present in the transport" >>>=20 >>> sec 5.2.12 >>> Using temporary local addresses may break various mechanisms that prove a= ddress ownership (e.g QUIC resumption tokens) and therefore impair performan= ce as the client has to re-verify its address. >>>=20 >>> sec 6.2=20 >>> "After Stop() is called, the Listener can be disposed of.." I don't unde= rstand the difference between calling listener.stop() and simply disposing o= f the object. Does this imply that there is a listener.start() that allows a= configured listener to resume? >>>=20 >>> sec 7.1.4 >>> It would be helpful to clarify the relevance of control vs application d= ata in the idle timeout -- for various reasons, the connection could stay al= ive regardless of how active the connection is (in fact, perhaps "keepalive"= is a generally useful notion that can be exposed in the API?) >>>=20 >>> sec 7.1..8 >>> This section is missing a reference to minSendRate and minRecvRate >>>=20 >>> sec 7.1.9. >>> We're going to need an event for MTU changes. These can't simply be Send= errors because the Sent event might go first, or the transport might be sen= ding a probe with padding that doesn't correspond to a message. >>>=20 >>> sec 7.2 >>> perhaps I'm not thinking of this correctly, but should there be a way to= query the peer-offered user timeout? >>>=20 >>> sec 8.3.2.1 >>> Reading the Sent event, I was pretty sure that reliable transports would= deliver the event until the ack arrived. But Sec 10 most definitely does no= t say that. I would think that the ack would be a more useful signal, but ma= ybe I'm in the rough on this -- certainly many transport implementations wil= l not do this well. >>>=20 >>> -Martin >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >>=20 --Apple-Mail-BA87ACB6-EE6B-47E7-9B14-77E8876E2CAE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks so much for doing this!  This w= as meant as a todo item for us, or me, not you!

Cheers,
Michael

Sent from my iPhone

On 7 Aug 2020, at 18:25, Martin Duk= e <martin.h.duke@gmail.com> wrote:

=EF=BB=BF
OK, I'll file gi= thub issues

On Fri, Aug 7, 2020 at 1:21 AM Michael Welzl <michawe@ifi.uio.no> wrote:
On Aug 6, 2020, at 9:30 PM,= Martin Duke <martin.h.duke@gmail.com> wrote:

Here= is my promised "no prior knowledge" review of taps-interface. I haven't fil= ed issues for these yet, as I suspect some of these have already been well-l= itigated there.

The only other draft I've read is taps-ar= ch.

High level comments:

<= div>(1) I think this conceptually headed in the right direction.
<= br>
(2) I found the relationship between streams and connections t= o be extremely murky throughout the draft, and left it not really sure how I= would control a streamed transport.

Section 6.4 hi= nts suggests that opening additional streams is an alternative implementatio= n of Clone() for transports that can do so. Does this imply that if the peer= stream limit does not allow new streams, the transport should open a connec= tion instead? How does SetNewConnectionLimit() in Sec 6.2 relate to streamed= transport -- are there two levels of listener: a stream listener and a conn= ection listener? How would opening "stream listeners" relate to the maximum n= umber of streams the peer could open (i.e. do I have to call listen() 8 time= s to allow the client to open 8 streams)? Or are there no stream listeners a= nd these "connections" just sort of appear?

Skimmin= g the -impl draft, I can see there's some text here but it is not fitting to= gether for me. There are at least three streamed transports and it would be h= elpful to explain how the API conceptualizes this, perhaps in a new section.=

The next two major points are related to streams, s= o if I've missed something important above they may be complete nonsequiturs= .

(3) I'm not sure the priority framework really fi= ts together.

Sec 6.4 says we 'should' do something t= hat sounds like WFQ, but 7.1.5 allows the application to decide what ha= ppens. Meanwhile message priority suggests a strict priority-based scheduler= .

Meanwhile, in sec 8.1.3.2 "Note that this propert= y is not a per-message override of the  connection Priority - see Secti= on 7.1.3.  Both Priority properties
   may interact, but= can be used independently and be realized by
   different mech= anisms." 

At the risk of overindexing on a par= tly-baked draft in httpbis, how would I implement strict priority of HTTP/3 s= treams over a taps API that implements QUIC? Would I need to request strict p= riority in *both* connection priority and message priority? Or I guess c= onnection priority would be sufficient?

(4) I found= myself continually asking how I would implement foo-over-http/x using this A= PI, and very much stumbled over ambiguity regarding HTTP 1.1 pipelining. Whi= le it's certainly possible to order messages in the proper way using this AP= I, if I was writing this agnostically to HTTP version, it appears it would g= ravitate to opening a pooled TCP connection for each request/response if we e= nded up on HTTP/1 [because each request/response would have a clone() call].= Maybe this is OK, but I found this conclusion to be jarring.

=
Specific comments:

sec 4.2.2
=
"implementations MUST provide a
      method for the a= pplication to determine the entire set of possible
      v= alues for each property."

Is this meant to be a req= uirement for a machine-readable API for learning the enum, or merely a requi= rement for documentation? i.e. is it satisfied if the values are in the= man page or comments of the C header file?

sec 5.<= /div>
I found it curious that there is no API here for registering callb= acks, or mention that this is a precondition to connection. Surely event han= dlers are a prerequisite?

sec 5.1
I found= it odd that there didn't appear to be any sort of formal list of attributes= of an endpoint, just some examples.

sec 5.2.7
<= /div>
I am not sure what this sentence means: "Disabling this property m= ay enable to control checksum coverage later."

sec 5= .2.9
It would be helpful to say "Applications that neither prohibi= t nor require congestion should query the result and disable their own conge= stion control if present in the transport"

sec 5.2.= 12
Using temporary local addresses may break various mechanisms th= at prove address ownership (e.g QUIC resumption tokens) and therefore impair= performance as the client has to re-verify its address.

sec 6.2 
"After Stop() is called, the Listener can= be disposed of.." I don't understand the difference between calling listene= r.stop() and simply disposing of the object. Does this imply that there is a= listener.start() that allows a configured listener to resume?

sec 7.1.4
It would be helpful to cla= rify the relevance of control vs application data in the idle timeout -- for= various reasons, the connection could stay alive regardless of how active t= he connection is (in fact, perhaps "keepalive" is a generally useful notion t= hat can be exposed in the API?)

sec 7.1..8
This section is missing a reference to minSendRate and minRecvRate

sec 7.1.9.
We're going to need an event for MTU c= hanges. These can't simply be Send errors because the Sent event might go fi= rst, or the transport might be sending a probe with padding that doesn't cor= respond to a message.

sec 7.2
perhaps I'm= not thinking of this correctly, but should there be a way to query the peer= -offered user timeout?

sec 8.3.2.1
Readin= g the Sent event, I was pretty sure that reliable transports would deliver t= he event until the ack arrived. But Sec 10 most definitely does not say that= . I would think that the ack would be a more useful signal, but maybe I'm in= the rough on this -- certainly many transport implementations will not do t= his well.

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

= --Apple-Mail-BA87ACB6-EE6B-47E7-9B14-77E8876E2CAE-- From nobody Tue Aug 11 05:40:23 2020 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 EE6713A102C for ; Tue, 11 Aug 2020 05:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-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=ericsson.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 W2aItYbVANR2 for ; Tue, 11 Aug 2020 05:40:19 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2074.outbound.protection.outlook.com [40.107.20.74]) (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 4AF453A102A for ; Tue, 11 Aug 2020 05:40:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Wyr4hp+mmeeJpYThuzE8Ow+C1Ug0tyo5GHSYlHP9B40naPOEIYojy90FO4LKYjVldzdshnOa5ZOVcyEhEdnfKR7etNHSQgdK9kABcY5llKYShi8CKuXxELuDhRmY0hVeCM01WTLtItokuGqJjioYdMYBaJ3xZjYBKBo2DUIsuuYaqz8ppwOQVXIZmaV2XvggCeB64SjJsKRqXjc8d/hT8IDHbbd1Fa5Q3XuY+Sj/q5MCk4lN1RAJggkNNt990yftB66tjAi9u54I+ikay0fTwpWpK/J5ekvGhyIYyAl76VcbUnBxPuU81phTrUrvfr2/UWZSBvknKvISbFvUUI2/FQ== 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=8IhhILcTchGEW75xRUq9oLIW/9aB8rZizeuG2xZ0xDg=; b=GQ195x4be7hB5pt6tI7Kx6ss/wFqL7+9V/72GndEs2CuIX36nQYusul6wskXTK0kehjLRlro+zt+/uT46IEoouep3faUZVRjAMa+FM3Xf0ykFmfuDCEnzGQ3E3YcqxPxHd6vLaEgx9LIHj7pxKSISAP1h21q5MQHsSkcoOdv8y0AQoKXQo9MFIYHIk2wnjA1UTASlme3KLlmwcCbpF/t/6QdSz4r99scIsGPo6eh8yPsVfWO7ogUsTO5GC3ftPn9KBiSl8fAORwfLP98OPKZQ293PKKuCThp0BQl2B4fDPrVhSN0QTTRWaJTKrYbcGSi/d0YCvaHqR5jNttVvfGhlg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8IhhILcTchGEW75xRUq9oLIW/9aB8rZizeuG2xZ0xDg=; b=kKpyumWun+ef45xn/WKOYI+oiPsQL3Mr7GgQjQTCEHk91v+vUreLieZiIj0l49xbKblSsaM5ZCVVep+QRPXbT4N+hB+o9CQZYSmZ0AOBguSmfpl+e+dohN+giAwSeICH/SmY9WZONvsTnH3l/uTlUOgjdYE1UtVybhTFY+XJjOw= Received: from AM0PR0702MB3713.eurprd07.prod.outlook.com (2603:10a6:208:19::10) by AM0PR07MB4099.eurprd07.prod.outlook.com (2603:10a6:208:48::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.10; Tue, 11 Aug 2020 12:40:13 +0000 Received: from AM0PR0702MB3713.eurprd07.prod.outlook.com ([fe80::d1f1:397c:7240:92f1]) by AM0PR0702MB3713.eurprd07.prod.outlook.com ([fe80::d1f1:397c:7240:92f1%7]) with mapi id 15.20.3283.015; Tue, 11 Aug 2020 12:40:12 +0000 From: Mirja Kuehlewind To: "taps@ietf.org" Thread-Topic: QUIC API (was: Re: Small size of core QUIC library to replace TCP for embedded system) Thread-Index: AQHWX+/a2T/Iwkj2F0iLf4U2VrcEdKkryf4AgAYhaICAAS9dAA== Date: Tue, 11 Aug 2020 12:40:12 +0000 Message-ID: <18036465-15AF-4019-8BED-189900F90130@ericsson.com> References: <2499749.AO4zfZtjs8@linux-9daj> <3D493D2B-BC8D-4CE9-B189-48770C3FA06F@eggert.org> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2003:de:e711:af00:c59a:feb4:9a15:2d07] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b31d72e8-8dce-4f84-f585-08d83df3b101 x-ms-traffictypediagnostic: AM0PR07MB4099: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Qb1WNqKWurpcyFTizqDnw+fUaTlLpeAs3twTVahYYtF4PkAt2hZzFQQJfUr2YGgx/16hlmO+j4S8qc0uzcS0yvqjZbtj7XPLav8rA7C9xKxelRfVJ/eoba/7zZEy2Bcrls7ZCp9DXueHvHkIvWKocflglFaNnIsBfb4A0/fAQhUHkfIV7TzzMjYewWR1MdGZUT1oM1QXiosw4NEZQxB8Kauj31ktoIF5vAXYaZTblbQ02jEziyKaQz5wSeaJ5f/VVBL/EecCGDCoQlR3Z79jkJ6kuwEKmnPfpOMte0SqFXpkSQnYdDkzTvcrAEOmxzlJBtkAf104zlLERAwRQaGQ3gh1OP6qLJrrj5f1vnAh4i47WPGrrwOaFTyf28DHoUU7DWoV9wCBjHzlwqlYToFNcg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR0702MB3713.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(366004)(346002)(39860400002)(376002)(396003)(6486002)(33656002)(316002)(6506007)(53546011)(6512007)(186003)(86362001)(5660300002)(71200400001)(8936002)(2616005)(66476007)(66946007)(76116006)(36756003)(66556008)(8676002)(64756008)(66446008)(4744005)(44832011)(966005)(6916009)(2906002)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ITYmVN53KDj6BV+sf1oHmpiEjQJJmeFMS1lZnG2mriTlyyQEV6+HgFva3Cr2Ul2Ol7HiCvvxxmJpDSnviQ1x8d3pmz0GPlxURpuv3ddKA8AV56kjJxo/LwHoUGTcjn+bywHASI9IuKZ8xila5g0nW/Ndi+J/xxYC7FM9r5W8lwEVamF6I3cCiE4TIgGqLllY2eqtQnrImqZrxWzO3XDDiJmf+Msqtpg1f4TlqdHQCIGx5zTlJDBIDaSl5TDu1UzxO4MW9KijMPXD+ofF4fvskXWkipO+A+43zLUFKPJhoXrZJtNSIG2Ls5SBpfcIUcBdxyuUu8CPVmRtmNeJk5o/DQXyQL/PL2wfvZwai5cWFQHdhV1eq9iupORaF5x4WgprA8tynC+DmcQXjCo7X+zS0EQjD8zdvLkE/9p8eEhFfUoNwe344vXmHpboAFFBxPhzlGmGlRKJe0qiS8/ytrZ2dkdMhJVoZKxkOysIXDocrPjd4WyBPcvm6eKPaRbcfH6c1/cWdF+8QwI/8UaqPLT3mOs2weOEcaSoh75iOieUEYrD6uLqXrJRKHsuwnnSbfhr8VJYkfFHIYSYlAQcZwlMe7DI6XM6u9qPjyZjEY6yIfftFxaR+YIEn8yAPPeol4ckv+ruIQPdELaQTNcLaKcxOZausFRujoXQif41+q/ATIoI3peO00V9K1VGVmUyLxNgYvdZ6xPfHzqDe5W8ITOgQA== 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: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR0702MB3713.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b31d72e8-8dce-4f84-f585-08d83df3b101 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2020 12:40:12.5270 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +W1xJkK7sHCkyXqEhRxrh5J+oa7Ym/utkoxsSGZevnt6w7ESpW1ltmxlqXfMu4AOpImSGH2wTmD1mwST6F0Z1wx19+pctPwYte3yTycI0mo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4099 Archived-At: Subject: [Taps] FW: QUIC API (was: Re: Small size of core QUIC library to replace TCP for embedded system) 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, 11 Aug 2020 12:40:21 -0000 TWF5YmUgdGhpcyBpcyBhbHNvIGludGVyZXN0aW5nIGZvciB0YXBzIGFzIGEgcmVmZXJlbmNlLi4u DQoNCu+7v09uIDEwLjA4LjIwLCAyMjozNSwgIlFVSUMgb24gYmVoYWxmIG9mIERpcmtqYW4gT2No dG1hbiIgPHF1aWMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgZGlya2phbkBvY2h0bWFu Lm5sPiB3cm90ZToNCg0KICAgIE9uIEZyaSwgQXVnIDcsIDIwMjAgYXQgMTI6NTcgQU0gTWFydGlu IER1a2UgPG1hcnRpbi5oLmR1a2VAZ21haWwuY29tPiB3cm90ZToNCiAgICA+IE9uIHRoaXMgc3Vi amVjdCwgKHNwZWFraW5nIGFzIGluZGl2aWR1YWwpIEkgdGhpbmsgaXQgd291bGQgYmUgdXNlZnVs IHRvIGRlZmluZSBhIFFVSUMgYXBwbGljYXRpb24gQVBJLiBTQ1RQIGRpZCBvbmUgKGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzY0NTgvKSBhbmQgdGhlIGlkZWEgdGhhdCBhbiBh cHBsaWNhdGlvbiB3b3VsZCBoYXZlIHRvIGJlIHdyaXR0ZW4gc2VwYXJhdGVseSBmb3IgZWFjaCBx dWljIGltcGxlbWVudGF0aW9uIGlzIHNpbGx5Lg0KDQogICAgRm9yIHdoYXQgaXQncyB3b3J0aCwg Zm9yIHRoZSBoeXBlciBsaWJyYXJ5ICh0aGUgbW9zdCBwb3B1bGFyIEhUVFANCiAgICBsaWJyYXJ5 IGluIHRoZSBSdXN0IGVjb3N5c3RlbSkgd2UncmUgdHJ5aW5nIHRvIGRlZmluZSBhIHNldCBvZiBS dXN0DQogICAgdHJhaXRzIChhYnN0cmFjdCBpbnRlcmZhY2VzKSB0aGF0IGNvdmVyIHRoZSBiYXNp YyBRVUlDIEFQSSBpbnNvZmFyIGFzDQogICAgSDMgc3VwcG9ydCBuZWVkcyBpdC4NCg0KICAgIGh0 dHBzOi8vZ2l0aHViLmNvbS9oeXBlcml1bS9oMy9ibG9iL21hc3Rlci9kZXNpZ24vUFJPUE9TQUwu bWQjNC1wdWJsaWMtYXBpDQoNCiAgICBLaW5kIHJlZ2FyZHMsDQoNCiAgICBEaXJramFuDQoNCg0K From nobody Tue Aug 11 08:06:08 2020 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 8E76A3A10EB for ; Tue, 11 Aug 2020 08:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 NYM84NzFVoKk for ; Tue, 11 Aug 2020 08:06:05 -0700 (PDT) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (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 6F2553A1105 for ; Tue, 11 Aug 2020 08:06:04 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id y134so7221601yby.2 for ; Tue, 11 Aug 2020 08:06:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gIptf37o9N+8yKhq2hcfHRTVE/nWdH7Lsjiza7YKsxE=; b=A15SqISM5aHv683oLcZiE5S5dTMplQw7xroAhv37IMS6RxXZ7QvXiVLUR+oWyi/4H8 HbIpCfDycA0VAJ4bf0q4Dp2r2LYcm4rOg3VZ6n1S0yPwFdRWsCmx/m3CvVDNTUdQH+0I j2K3fWPzrJPMbDMbvlB2DKY8MnM99k2cCMEMjPs3rRXfb7bdzaDytQ6yR5Io0ChwSz8a kSpS9JMgqib1yzBVOMTr+zCAybpZXlsy6h9HRaDs0g2rlfBMIc1jSDPE4cAeKaNn0xN0 xG5SS0touchzyvVuWEhsWRel68U1vSRk9kcR+4TAxfAP2p0t0id+0WvpBOIcBO0BiaWO fXiA== 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=gIptf37o9N+8yKhq2hcfHRTVE/nWdH7Lsjiza7YKsxE=; b=YqV8ASZxyh5dLPHHMEPzSH7qubjLCGxlmOc+4Gc5YTYR4pHlta6/+YoZiutRgyzN7M wWXSGZhYxYeqcP/Qlvrp4DZY2Z0EUuOf1KJb/pYWi8MnYCTV2c3QIWTPWEVlYommTFWM hLGo2RDiLTWUH0Mu48PRwqLSynTE/j+51J6UPfrlUMbmXaf4xvTglt7aQ5AyrkrExB7B GrXQtvX7tzYZSdiQ3fEl+cr2pytPMz0H89UerQ/ADP2N7E2FaZgGJDobg43h8n9JeWfu D4Y3+SeGuPqJNjYBwhNjt01jV0SrqQS3t2r194b3VghM2tfJzTybBF9e/FANO3oE95Ca Qfmg== X-Gm-Message-State: AOAM533Juxez1PYm/j41xuZO5IOY9gvxdUCBftljb7hAf9gbkOdngmYN vsDK02YecKvtJlm/9PVyTSmE7oPUCAnm5jiak0mgZg== X-Google-Smtp-Source: ABdhPJwSSCAM2cELAYORgIlYzbsUm1q5TSNzp7rvMkJdookLDgC/HneUyNgRYIVMfZ9nDQyWitPvEWLvPbql+hOApWw= X-Received: by 2002:a25:cc50:: with SMTP id l77mr13559514ybf.84.1597158363437; Tue, 11 Aug 2020 08:06:03 -0700 (PDT) MIME-Version: 1.0 References: <2499749.AO4zfZtjs8@linux-9daj> <3D493D2B-BC8D-4CE9-B189-48770C3FA06F@eggert.org> <18036465-15AF-4019-8BED-189900F90130@ericsson.com> In-Reply-To: <18036465-15AF-4019-8BED-189900F90130@ericsson.com> From: Spencer Dawkins at IETF Date: Tue, 11 Aug 2020 10:05:37 -0500 Message-ID: To: Mirja Kuehlewind Cc: "taps@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e71eb805ac9b689e" Archived-At: Subject: Re: [Taps] FW: QUIC API (was: Re: Small size of core QUIC library to replace TCP for embedded system) 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, 11 Aug 2020 15:06:07 -0000 --000000000000e71eb805ac9b689e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 11, 2020 at 7:40 AM Mirja Kuehlewind wrote: > Maybe this is also interesting for taps as a reference... > I sure hope so! Best, Spencer > > =EF=BB=BFOn 10.08.20, 22:35, "QUIC on behalf of Dirkjan Ochtman" < > quic-bounces@ietf.org on behalf of dirkjan@ochtman.nl> wrote: > > On Fri, Aug 7, 2020 at 12:57 AM Martin Duke > wrote: > > On this subject, (speaking as individual) I think it would be usefu= l > to define a QUIC application API. SCTP did one ( > https://datatracker.ietf.org/doc/rfc6458/) and the idea that an > application would have to be written separately for each quic > implementation is silly. > > For what it's worth, for the hyper library (the most popular HTTP > library in the Rust ecosystem) we're trying to define a set of Rust > traits (abstract interfaces) that cover the basic QUIC API insofar as > H3 support needs it. > > > https://github.com/hyperium/h3/blob/master/design/PROPOSAL.md#4-public-ap= i > > Kind regards, > > Dirkjan > > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps > --000000000000e71eb805ac9b689e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Aug 11, 2020 at 7:40 AM Mirja= Kuehlewind <mirja.kuehlewind=3D40ericsson.com@dmarc.ietf.org> wrote:
Maybe this is also interesting for ta= ps as a reference...

I sure hope so!

Best,

Spencer
=C2= =A0

=EF=BB=BFOn 10.08.20, 22:35, "QUIC on behalf of Dirkjan Ochtman" = <quic-bounces= @ietf.org on behalf of dirkjan@ochtman.nl> wrote:

=C2=A0 =C2=A0 On Fri, Aug 7, 2020 at 12:57 AM Martin Duke <martin.h.duke@gmail.com= > wrote:
=C2=A0 =C2=A0 > On this subject, (speaking as individual) I think it wou= ld be useful to define a QUIC application API. SCTP did one (https://datatracker.ietf.org/doc/rfc6458/) and the idea that an appli= cation would have to be written separately for each quic implementation is = silly.

=C2=A0 =C2=A0 For what it's worth, for the hyper library (the most popu= lar HTTP
=C2=A0 =C2=A0 library in the Rust ecosystem) we're trying to define a s= et of Rust
=C2=A0 =C2=A0 traits (abstract interfaces) that cover the basic QUIC API in= sofar as
=C2=A0 =C2=A0 H3 support needs it.

=C2=A0 =C2=A0 https://gith= ub.com/hyperium/h3/blob/master/design/PROPOSAL.md#4-public-api

=C2=A0 =C2=A0 Kind regards,

=C2=A0 =C2=A0 Dirkjan


_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps
--000000000000e71eb805ac9b689e-- From nobody Fri Aug 14 01:02:21 2020 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 B35F63A0DD8 for ; Fri, 14 Aug 2020 01:02:19 -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 E6sAnORE6ySw for ; Fri, 14 Aug 2020 01:02:18 -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 EB6343A081B for ; Fri, 14 Aug 2020 01:02:17 -0700 (PDT) Received: from [127.0.0.1] (helo=magpie.corvid.ch) by magpie.corvid.ch with esmtp (Exim 4.92) (envelope-from ) id 1k6UdB-0003c8-00 for taps@ietf.org; Fri, 14 Aug 2020 08:00:05 +0000 Content-Type: multipart/alternative; boundary="===============1806125524694508419==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 14 Aug 2020 08:00:05 +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, 14 Aug 2020 08:02:20 -0000 --===============1806125524694508419== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * ietf-tapswg/api-drafts (+17/-1/=F0=9F=92=AC11) 17 issues created: - Figure Legends in Arch (by gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/635 [Architecture] [ed= itorial] = - In Arch.... this sentence reads like a paper, rather than an Arch spec.= (by gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/634 = - Sent<> event after ack (by martinduke) https://github.com/ietf-tapswg/api-drafts/issues/632 = - Peer user timeout (by martinduke) https://github.com/ietf-tapswg/api-drafts/issues/631 = - Event for PMTU changes (by martinduke) https://github.com/ietf-tapswg/api-drafts/issues/630 = - minSendRate, minRecvRate (by martinduke) https://github.com/ietf-tapswg/api-drafts/issues/629 = - Transport Control Data and Idle Timeout (by martinduke) https://github.com/ietf-tapswg/api-drafts/issues/628 = - Does stop() add value to the API? (by martinduke) https://github.com/ietf-tapswg/api-drafts/issues/627 = - Problems with temporary local addresses (by martinduke) https://github.com/ietf-tapswg/api-drafts/issues/626 = - Clarify Use of Application Congestion Control (by martinduke) https://github.com/ietf-tapswg/api-drafts/issues/625 = - Unclear Sentence (by martinduke) https://github.com/ietf-tapswg/api-drafts/issues/624 = - List of endpoint attributes (by martinduke) https://github.com/ietf-tapswg/api-drafts/issues/623 = - Callback Registration API (by martinduke) https://github.com/ietf-tapswg/api-drafts/issues/622 = - API for enum values? (by martinduke) https://github.com/ietf-tapswg/api-drafts/issues/621 = - HTTP/1 pipelining vs new connections (by martinduke) https://github.com/ietf-tapswg/api-drafts/issues/620 = - Priority Framework is confusing (by martinduke) https://github.com/ietf-tapswg/api-drafts/issues/619 = - Streams/Connections Relationship is unclear (by martinduke) https://github.com/ietf-tapswg/api-drafts/issues/618 = 8 issues received 11 new comments: - #626 Problems with temporary local addresses (2 by tfpauly, martinduke) https://github.com/ietf-tapswg/api-drafts/issues/626 = - #630 Event for PMTU changes (2 by gorryfair, martinduke) https://github.com/ietf-tapswg/api-drafts/issues/630 [API] [discuss] = - #632 Sent<> event after ack (2 by tfpauly, martinduke) https://github.com/ietf-tapswg/api-drafts/issues/632 = - #612 Allow setting multiple values for some Security Parameters (1 by t= heri) https://github.com/ietf-tapswg/api-drafts/issues/612 [API] [discuss] = - #621 API for enum values? (1 by gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/621 [API] = - #624 Unclear Sentence (1 by gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/624 = - #625 Clarify Use of Application Congestion Control (1 by gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/625 = - #635 Figure Legends in Arch (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/635 [API] [editorial] = 1 issues closed: - Sent<> event after ack https://github.com/ietf-tapswg/api-drafts/issues= /632 = Pull requests ------------- * ietf-tapswg/api-drafts (+1/-1/=F0=9F=92=AC4) 1 pull requests submitted: - Clarify that amount of 0-RTT data varies by protocol, closes #580 (by t= heri) https://github.com/ietf-tapswg/api-drafts/pull/633 = 3 pull requests received 4 new comments: - #605 Keep Minset protocol mappings, create template for new mappings (2= by abrunstrom, tfpauly) https://github.com/ietf-tapswg/api-drafts/pull/605 [Implementation] = - #614 Edits on Section on Handling Path Changes (1 by philsbln) https://github.com/ietf-tapswg/api-drafts/pull/614 = - #606 Clarify text on staggered racing, reference happy eyeballs and ICE= (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/pull/606 [Implementation] = 1 pull requests merged: - More nits https://github.com/ietf-tapswg/api-drafts/pull/617 = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============1806125524694508419== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday August 14, 2020

Issues

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

17 issues created:

8 issues received 11 new comments:

1 issues closed:

Pull requests

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

1 pull requests submitted:

3 pull requests received 4 new comments:

1 pull requests merged:

Repositories tracked by this digest:

--===============1806125524694508419==-- From nobody Fri Aug 14 07:40:06 2020 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 5797A3A11E1 for ; Fri, 14 Aug 2020 07:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 2zO1kZH7OT4E for ; Fri, 14 Aug 2020 07:40:03 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 E9D3A3A11DD for ; Fri, 14 Aug 2020 07:40:02 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id s23so7033858qtq.12 for ; Fri, 14 Aug 2020 07:40:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=kpBTQNi/UzPZJ4gB4maPsEgv4Wle5faxbCE5L4FCN0A=; b=Lm0759PIadIVHZIou3nY2Hl0M/NXeDYo3CX1T1tmrBFolgrqOr3O/8fXVW7QasWGef rBAKYSe58wnmI8cEUgqKHog3geBE9KtOSDW92fioxqCMC2A1ph4s29oijswWGTJssO+f DZQ9KG881q1SWjQaJVGTQ/ZdZsB8BrHX/IFTHmrfu8t+829Ofgn8qEUTTLhvwr7KDf0b VvAID5fvexBcCKn9yc61SLxVQWC9D3LPE2ECNRHjdbnvlojIQB7PamvM24/MQxqJ/aqv gL7mviZ1zlDWeYglHC6EEriHCiD+spqszsDaUxSvlIl8xJrw3gYNkN7zIVa2ooxskrUH RWQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=kpBTQNi/UzPZJ4gB4maPsEgv4Wle5faxbCE5L4FCN0A=; b=XE1rIw0KwmU7K73gYU1YL6mbCZ9JWH3IFsfOXmBdf017v3OK9C+AnElVZ4y4CdpypP ZlDib7hUGolpDBJhWQ3qpR+QGjzmPtDpYbiT2kFpVJ6jRBugJoXMSQ33SNl9F531f8xH eq+rhpJjGGhBQAdgcoE9POvcqBWERbbHDVsTnVkjtOU2w6nEiBmU3cnOWEHk9NwjZV5J Gjn6/MdRiP0epcILGEMHvSfCMxy6WOmRps4n9SJ5WTbrZVHbAFCmvR1CF1W5hSfS19MT +MAmWRa7G0ngWsg9qRsIoIJHoBOO76C1mJqisbeGzH75sMq8M/qozVpe8FuFds79tfBn m76g== X-Gm-Message-State: AOAM531w6ke73d2F1ZiWZph4/JtPzRImg4NeIA2chf0Q8bmxLlXZi4mh wF5AH5fLmZskoWEilstfVEzRYWJ5vm8= X-Google-Smtp-Source: ABdhPJzOxO0D7f5LpFf0uQWLbGiJv3UINr5vp5+Kt0xUuclZ8c+3S5UEgKKCTyhpEaoOptmWV62HGg== X-Received: by 2002:ac8:6052:: with SMTP id k18mr2271734qtm.60.1597416001485; Fri, 14 Aug 2020 07:40:01 -0700 (PDT) Received: from [169.254.180.225] ([2601:18f:702:c870:643d:6b58:8cf4:2c0c]) by smtp.gmail.com with ESMTPSA id q126sm8522927qkb.75.2020.08.14.07.40.00 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Aug 2020 07:40:00 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Fri, 14 Aug 2020 10:39:59 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_1B2B2B05-F45D-4298-BA6E-3CE9DB112221_=" Archived-At: Subject: [Taps] links for August interim 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, 14 Aug 2020 14:40:04 -0000 --=_MailMate_1B2B2B05-F45D-4298-BA6E-3CE9DB112221_= Content-Type: text/plain; markup=markdown See you in 20min! --aaron | what | where | | --- | --- | |Webex | https://ietf.webex.com/meet/taps | | Bluesheet / Notes | https://etherpad.ietf.org:9009/p/taps-interim-aug-2020 | | Github Issues | https://github.com/ietf-tapswg/api-drafts/issues | | Gitbub PRs | https://github.com/ietf-tapswg/api-drafts/pulls | --=_MailMate_1B2B2B05-F45D-4298-BA6E-3CE9DB112221_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable --=_MailMate_1B2B2B05-F45D-4298-BA6E-3CE9DB112221_=-- From nobody Fri Aug 14 10:04:24 2020 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 6C1143A0B31 for ; Fri, 14 Aug 2020 10:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=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 KScmFIToLgDw for ; Fri, 14 Aug 2020 10:04:20 -0700 (PDT) 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 AEB5A3A0E3F for ; Fri, 14 Aug 2020 10:04:20 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id t23so7444981qto.3 for ; Fri, 14 Aug 2020 10:04:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=BbVoah19+4Tb/TDRQVLpSU8F7qebeWbWx9Dz1JD1HaU=; b=EGPbY6qpTG/XvNoZ5VL8VNTOGpN2m0TIj2sURVMww9ERqWaORuEzDB8cVFxIdTyHBz ZfkHoNwX3VoNm3u+qUv/6S9zECZmiieRnxEJk3pSrq31EMdaWIf8JhPt0U2JAUfMrCN2 PQPCP5Sp2aeJya+LERZG7WAJIEbRDQTJcVQQ+bVwurWl4co5BivsYj+y8Hx42XninzLj JLClAaVEF4W+JRZIrS1v0Rs5/Ek6I4I0gT5WvpfUbraQ+MNSSgYg2NdecbCE/3asEJ2F Xe0voqAOSF7iobRvErlhJxfwiH3BOVCwNWSST7zvAh9uXmnnsgJlwSLlARw7mm0PU8Uy 1FAA== 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=BbVoah19+4Tb/TDRQVLpSU8F7qebeWbWx9Dz1JD1HaU=; b=bczcq/8JxqVmwOntKOUGyNjXWuEWlF2qMNe0rxer6POAuwF4rgBOo73rHDHVhSZj2u IntiLOPPXTJiKzDVcRL4qDsZFO39uBdlyj04TV276HNbS2L41WzJr5aAQPY5fj20IR0l of1f4VBZ7sOxr7mb+fS9S2Gt6kI+kXrLm3s9PThXmtzpaUATVAuURHpHpVTiT+qCMgpF wb8z4rBpelg5wzU6Ft/qG1SKpldw2GjGT5c1dXBlqPDmCpHapDzJn+7bukp1v81ub6li JaWbgcVJuxvDHMu+i+uqUsZGNqQ08tzCUnVovmB8QK+iwScCA3w6R3Kb/Fe45uR48KEn A2Pw== X-Gm-Message-State: AOAM5306GnMR4dEpPsjcgg1yrbAZ4kBSnpP9sIbq7itk6/FncrFrzEQ+ G4VOUxuKZQQU3mp82TpBv+Uz0QobNak= X-Google-Smtp-Source: ABdhPJzFTar+FH/EjzYj1aWDpn3qIv2wvps1UgEs/RhfK4GckdDpL8YjB1xRnyNsPuIbpEnpB2cAuw== X-Received: by 2002:aed:38e6:: with SMTP id k93mr2744475qte.90.1597424659326; Fri, 14 Aug 2020 10:04:19 -0700 (PDT) Received: from [169.254.180.225] ([2601:18f:702:c870:643d:6b58:8cf4:2c0c]) by smtp.gmail.com with ESMTPSA id d143sm8926267qkc.59.2020.08.14.10.04.18 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Aug 2020 10:04:18 -0700 (PDT) From: "Aaron Falk" To: "taps WG" Date: Fri, 14 Aug 2020 13:04:17 -0400 X-Mailer: MailMate (1.13.1r5671) Message-ID: <32A0C87D-39A4-449B-A9D2-CDD2BF3A3AF9@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_8E44617F-E34E-4307-A9D0-887CD328862B_=" Content-Transfer-Encoding: 8bit Archived-At: Subject: [Taps] notes from Aug interim 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, 14 Aug 2020 17:04:23 -0000 --=_MailMate_8E44617F-E34E-4307-A9D0-887CD328862B_= Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Etherpad w/attendance here: https://etherpad.ietf.org:9009/p/taps-interim-aug-2020 We reviewed all the PRs and open issues, many of which came from a deep review by Martin Duke (thanks!!). A number of clarifications & other revisions are planned, mostly on the API draft. An additional review is expected from Kyle before taking the doc to WGLC and it is suggested that Kyle review the issue list and use the editor’s draft for his review. Next interim scheduled for Sept 11, 1100-1300 EDT. --aaron --=_MailMate_8E44617F-E34E-4307-A9D0-887CD328862B_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Etherpad w/attendance here: https://ethe= rpad.ietf.org:9009/p/taps-interim-aug-2020

We reviewed all the PRs and open issues, many of which ca= me from a deep review by Martin Duke (thanks!!). A number of clarificat= ions & other revisions are planned, mostly on the API draft. An addi= tional review is expected from Kyle before taking the doc to WGLC and it = is suggested that Kyle review the issue list and use the editor=E2=80=99s= draft for his review.

Next interim scheduled for Sept 11, 1100-1300 EDT.

--aaron

--=_MailMate_8E44617F-E34E-4307-A9D0-887CD328862B_=-- From nobody Fri Aug 14 10:16:50 2020 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 B36363A1044; Fri, 14 Aug 2020 10:16:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: taps@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159742540857.2847.9484068483182382245@ietfa.amsl.com> Date: Fri, 14 Aug 2020 10:16:48 -0700 Archived-At: Subject: [Taps] Transport Services (taps) WG Virtual Meeting: 2020-09-11 X-BeenThere: taps@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF Transport Services \(TAPS\) Working Group" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2020 17:16:49 -0000 The Transport Services (taps) WG will hold a virtual interim meeting on 2020-09-11 from 11:00 to 13:00 America/New_York (15:00 to 17:00 UTC). Agenda: Review of open items in https://github.com/ietf-tapswg/api-drafts/issues and https://github.com/ietf-tapswg/api-drafts/pulls Information about remote participation: https://ietf.webex.com/meet/taps From nobody Fri Aug 21 01:02:22 2020 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 CF6FF3A081C for ; Fri, 21 Aug 2020 01:02:20 -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 pj4wln15G--b for ; Fri, 21 Aug 2020 01:02:19 -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 DFC813A081B for ; Fri, 21 Aug 2020 01:02:18 -0700 (PDT) Received: from [127.0.0.1] (helo=magpie.corvid.ch) by magpie.corvid.ch with esmtp (Exim 4.92) (envelope-from ) id 1k91y2-0004bS-Gx for taps@ietf.org; Fri, 21 Aug 2020 08:00:06 +0000 Content-Type: multipart/alternative; boundary="===============5991266187201075304==" MIME-Version: 1.0 From: TAPS WG status robot To: taps@ietf.org Message-Id: Date: Fri, 21 Aug 2020 08:00:06 +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, 21 Aug 2020 08:02:21 -0000 --===============5991266187201075304== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * ietf-tapswg/api-drafts (+1/-4/=F0=9F=92=AC26) 1 issues created: - Rendezvous() example in =C2=A74.1.3 is simplistic (by csperkins) https://github.com/ietf-tapswg/api-drafts/issues/636 [API] = 15 issues received 26 new comments: - #618 Streams/Connections Relationship is unclear (5 by mwelzl, tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/618 [API] [ready for t= ext] = - #624 Partial Coverage: Unclear Sentence (4 by mwelzl, gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/624 [API] [ready for t= ext] = - #630 Event for PMTU changes (3 by gorryfair, tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/630 [API] [ready for t= ext] = - #619 Priority Framework is confusing (2 by gorryfair, tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/619 [API] [editorial] = - #626 Problems with temporary local addresses (2 by gorryfair, tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/626 [API] = - #612 Allow setting multiple values for some Security Parameters (1 by t= fpauly) https://github.com/ietf-tapswg/api-drafts/issues/612 [API] [discuss] = - #620 HTTP/1 pipelining vs new connections (1 by mwelzl) https://github.com/ietf-tapswg/api-drafts/issues/620 [API] = - #621 API for enum values? (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/621 [API] [editorial] = - #622 Callback Registration API (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/622 [API] [Architectur= e] = - #623 List of endpoint attributes (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/623 [API] = - #625 Clarify Use of Application Congestion Control (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/625 [API] [editorial] = [ready for text] = - #627 Does stop() add value to the API? (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/627 [API] = - #628 Transport Control Data and Idle Timeout (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/628 [API] [discuss] = - #631 Peer user timeout (1 by tfpauly) https://github.com/ietf-tapswg/api-drafts/issues/631 [mappings] = - #634 In Arch.... this sentence reads like a paper, rather than an Arch = spec. (1 by gorryfair) https://github.com/ietf-tapswg/api-drafts/issues/634 [Architecture] [ed= itorial] [ready for text] = 4 issues closed: - Callback Registration API https://github.com/ietf-tapswg/api-drafts/iss= ues/622 [API] [Architecture] = - Slim down per-protocol behavior, move other mappings out https://github= .com/ietf-tapswg/api-drafts/issues/398 [Implementation] [mappings] [ready f= or text] = - Recommendations for Delayed Racing https://github.com/ietf-tapswg/api-d= rafts/issues/537 [Implementation] [ready for text] = - 5.3 Is "Fast Open" just one "packet"? https://github.com/ietf-tapswg/a= pi-drafts/issues/580 [Implementation] [ready for text] = Pull requests ------------- * ietf-tapswg/api-drafts (+7/-4/=F0=9F=92=AC0) 7 pull requests submitted: - Add new sections on keep alives (by gorryfair) https://github.com/ietf-tapswg/api-drafts/pull/643 [API] = - Set of updates to API (by gorryfair) https://github.com/ietf-tapswg/api-drafts/pull/642 = - Update draft-ietf-taps-arch.md (by gorryfair) https://github.com/ietf-tapswg/api-drafts/pull/641 = - caveats on temporary local addresses (by britram) https://github.com/ietf-tapswg/api-drafts/pull/640 = - Clarify priority framework (by britram) https://github.com/ietf-tapswg/api-drafts/pull/639 = - remove requirement for enumeration of enumerations (by britram) https://github.com/ietf-tapswg/api-drafts/pull/638 = - Clarify behaviour of Rendezvous() (by csperkins) https://github.com/ietf-tapswg/api-drafts/pull/637 = 4 pull requests merged: - Editorial draft-ietf-taps-arch.md https://github.com/ietf-tapswg/api-drafts/pull/641 = - Keep Minset protocol mappings, create template for new mappings https://github.com/ietf-tapswg/api-drafts/pull/605 [Implementation] = - Clarify text on staggered racing, reference happy eyeballs and ICE https://github.com/ietf-tapswg/api-drafts/pull/606 [Implementation] = - Clarify that amount of 0-RTT data varies by protocol, closes #580 https://github.com/ietf-tapswg/api-drafts/pull/633 [Implementation] = Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-tapswg/api-drafts --===============5991266187201075304== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TAPS GitHub Activity Digest)

Friday August 21, 2020

Issues

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

1 issues created:

15 issues received 26 new comments:

4 issues closed:

Pull requests

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

7 pull requests submitted:

4 pull requests merged:

Repositories tracked by this digest:

--===============5991266187201075304==-- From nobody Mon Aug 31 09:58:16 2020 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 A4F833A178C for ; Mon, 31 Aug 2020 09:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.602 X-Spam-Level: X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-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 arcBGIuyWN9O for ; Mon, 31 Aug 2020 09:58:12 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 38B873A17A2 for ; Mon, 31 Aug 2020 09:58:12 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id h10so6720369ioq.6 for ; Mon, 31 Aug 2020 09:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=u2zSXbh29KRRQjjMoBG+BsNM66ycO+W+eE0Roea43Rs=; b=BlT2DiJH7NNoDVhREHYlgrATEGVTYSv7LEvSxlMbwD9btO6xLyNGK4bKcDM9DfM/c6 wV3fiIWO+nF2759huN4tuIoJfRNUzklVqm/amDlCj0ZwxIFH1bPmnBYH7N24xE0kGTfN CsX3mjhPD1pw7edCGfxitn6xdXE7I6JtZs8OrApXsmkxHH/Gpo4bTk8BJuVL9+c18HeL 2M0nYtl/2emG6qoleY++lZ1YKw5owxKK8Hcd+VKUZRihqHNZCavZ1Kr8DqlN1ONEcEQ+ 1aPayBiEvQn+09BObPRkNejDbGnn+Yay4xWJXAFQm90mMDeSecwgGjoHmGbFi+WdKKeM CNZQ== 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=u2zSXbh29KRRQjjMoBG+BsNM66ycO+W+eE0Roea43Rs=; b=tWJ1eDHQnaBbHe+y81aYHd4uiNc4jr6r/9ir/YU+jnF5BvY9ww7CeYhDDaLGHYHC8M koHc2qJT93t/RujwmJCCU3pz2+YOq7TF4NLsMNIfGm7WOzhoetiOt/WCer3VBu0TOkXd xJSxT6gb/kOO7wxN4qUqk9y/WicSUcb4Kzbydv8Aqgyi71BtNTjEdl6a3TYK653bygEc Ti2C7bzvz4XOmUUZijRTZZsB/S/HQimfHsDN3V6c6STYUYBkShpOgbUH6sk/y77pOX7G iB/3AUHb3KMq8M4qLlx8tnxUAZ6gD4Q4FSG4+V/+tVlovv7mm3wvrLjRsR0MwM1uHHbl 3mgA== X-Gm-Message-State: AOAM533letg6bjyepwcc/mPs/JxVjGrEfu+x8VyQVi8mRGdrkJe6C4vY KPicva2Tp1YEp76Lz/heS6Qzz5JSKf50kstJ4zJpYiX9Ya0= X-Google-Smtp-Source: ABdhPJxd4tkpZr98/+9E1R6M0WI6zEd51sTGf4S2O0xpLAOswYiMcIQ0y8vIHNHeOJMsJzY6WeegHtMRbTVOjglmoHY= X-Received: by 2002:a05:6638:2391:: with SMTP id q17mr2063522jat.31.1598893091039; Mon, 31 Aug 2020 09:58:11 -0700 (PDT) MIME-Version: 1.0 From: Martin Duke Date: Mon, 31 Aug 2020 09:58:00 -0700 Message-ID: To: taps WG Content-Type: multipart/alternative; boundary="000000000000b9ae9305ae2f4ee3" Archived-At: Subject: [Taps] Open source activities? 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, 31 Aug 2020 16:58:15 -0000 --000000000000b9ae9305ae2f4ee3 Content-Type: text/plain; charset="UTF-8" Can someone point me to any open source taps code out there? I would like to get involved in this work. --000000000000b9ae9305ae2f4ee3 Content-Type: text/html; charset="UTF-8"
Can someone point me to any open source taps code out there? I would like to get involved in this work.
--000000000000b9ae9305ae2f4ee3-- From nobody Mon Aug 31 13:19:53 2020 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 365513A193E for ; Mon, 31 Aug 2020 13:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=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 4wjUNNI9LUBK for ; Mon, 31 Aug 2020 13:19:50 -0700 (PDT) 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 00B8A3A0DD9 for ; Mon, 31 Aug 2020 13:19:42 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 07VK7Nqu002456; Mon, 31 Aug 2020 21:19:42 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=7/sTBeyCRHTBIXWNOab4++1rcsnzyhM5lapOLAKcH9w=; b=nVBqIDw4XnrUuAnQKaCdSjuZwHNEkIwZ+259Ce6pvu6fF6GAUGyjlGmTPVQh48Fixg1u XiY6aaGfcAHmBm5e85cy+cFnZ6fCU1fKygdFKQvHeezJsWY+LSuTQ1tmkmyhZDN3KfiS Zxqnq72rWevSupsttXENUOOw5idDCsEloBWJfxOYnccpJhzoRypzbC0S6zyF42LuXoqT 76IB6UN+Vv8uli/witeXNPN0/DCgfhbX/Ddz3FEDaXRZKYIhPD5nNTL5I7y9D5cGVYga qofU2kEF/Ob3zniYLO5uNPeMuG4PXnwJWE/cAArRjjCqLK0v4aHgr/maeEcTnZrbTId5 Zg== Received: from prod-mail-ppoint7 (a72-247-45-33.deploy.static.akamaitechnologies.com [72.247.45.33] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 337hjjb5be-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 31 Aug 2020 21:19:41 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 07VKJUUJ009609; Mon, 31 Aug 2020 16:19:41 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.114]) by prod-mail-ppoint7.akamai.com with ESMTP id 337jbxv3mn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 31 Aug 2020 16:19:41 -0400 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.165.122) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.165.123) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 31 Aug 2020 15:19:40 -0500 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.1497.006; Mon, 31 Aug 2020 15:19:40 -0500 From: "Holland, Jake" To: Martin Duke , taps WG Thread-Topic: [Taps] Open source activities? Thread-Index: AQHWf7fu+R2dM3zHq0SuarAanYKoT6lShyIA Date: Mon, 31 Aug 2020 20:19:39 +0000 Message-ID: <0453C855-F117-4997-BDEA-98449D5D545C@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.94.199] Content-Type: multipart/alternative; boundary="_000_0453C855F1174997BDEA98449D5D545Cakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-31_09:2020-08-31, 2020-08-31 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 phishscore=0 adultscore=0 mlxscore=0 bulkscore=0 spamscore=0 mlxlogscore=999 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008310119 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-31_09:2020-08-31, 2020-08-31 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1011 mlxscore=0 bulkscore=0 adultscore=0 phishscore=0 impostorscore=0 priorityscore=1501 spamscore=0 malwarescore=0 lowpriorityscore=0 mlxlogscore=999 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008310119 Archived-At: Subject: Re: [Taps] Open source activities? 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, 31 Aug 2020 20:19:52 -0000 --_000_0453C855F1174997BDEA98449D5D545Cakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFydGluLA0KDQpIZXJl4oCZcyB0aGUgb25lIHRoYXQgTWF4IGFuZCBUaGVyZXNhIGhhdmUg YmVlbiByZXBvcnRpbmcgb24gaW4gdGhlIHdnLCB0cnlpbmcgdG8gZG8gYSBmYWl0aGZ1bCBpbXBs ZW1lbnRhdGlvbiBvZiB0aGUgc3BlYzoNCmh0dHBzOi8vZ2l0aHViLmNvbS9mZy1pbmV0L3B5dGhv bi1hc3luY2lvLXRhcHMNCg0KVG8gbWUgaXTigJlzIGJlZW4gYSByZWFsbHkgZ29vZCBwbGFjZSB0 byB0aW5rZXIgYW5kIGdhaW4gZ29vZCBpbnNpZ2h0cy4NCg0KSW4gYWRkaXRpb24gdG8gdGhlIGV4 YW1wbGVzIGFuZCB0ZXN0IGFwcHMgaW4gdGhhdCBwcm9qZWN0LCB3ZSB1c2VkIHRoZSBsaWJyYXJ5 IGFzIHRoZSB0cmFuc3BvcnQgbGlicmFyeSBmb3IgYW5vdGhlciBleHBlcmltZW50YWwgcHJvamVj dCwgd2hpY2ggSSBkb27igJl0IHRoaW5rIHdlIHRvdWNoZWQgYWdhaW4geWV0IHNpbmNlIHRoZSBo YWNrYXRob24gd2hlbiB3ZSB3b3JrZWQgb24gaXQ6DQpodHRwczovL2dpdGh1Yi5jb20vR3J1bXB5 T2xkVHJvbGwvYW1iaQ0KDQpJ4oCZbSBub3Qgc3VyZSBpZiB5b3Ugd2VyZSBsb29raW5nIG9ubHkg Zm9yIG9wZW4tc291cmNlIGltcGxlbWVudGF0aW9ucyBvZiBhIHRhcHMtcmVsYXRlZCBsaWJyYXJ5 ICh3aGljaCBJ4oCZdmUgc28gZmFyIG9ubHkgdXNlZCBweXRob24tYXN5bmNpby10YXBzLCBhYm92 ZSksIG9yIHdoZXRoZXIgeW914oCZcmUgYWxzbyBsb29raW5nIGZvciBvcGVuLXNvdXJjZSByZXNv dXJjZXMgYWJvdXQgdXNpbmcgdGFwcy1saWtlIGxpYnJhcmllcyB0byBidWlsZCBvdGhlciB0aGlu Z3MuICBGb3IgaW5zdGFuY2UsIEnigJl2ZSBzZWVuIGEgZmV3IHJlc291cmNlcyB0aGF0IGRpZyBp bnRvIHVzaW5nIEFwcGxl4oCZcyBOZXR3b3JrIGZyYW1ld29yazoNCmh0dHBzOi8vcmRlcmlrLmNv bS9ibG9nL2J1aWxkaW5nLWEtc2VydmVyLWNsaWVudC1hcGxpY2F0aW9uLXVzaW5nLWFwcGxlLXMt bmV0d29yay1mcmFtZXdvcmsvDQpodHRwczovL2dpdGh1Yi5jb20vYXBwbGUvc3dpZnQtbmlvLXRy YW5zcG9ydC1zZXJ2aWNlcw0KDQpIVEguDQoNCkJlc3QsDQpKYWtlDQoNCg0KRnJvbTogTWFydGlu IER1a2UgPG1hcnRpbi5oLmR1a2VAZ21haWwuY29tPg0KRGF0ZTogTW9uZGF5LCBBdWd1c3QgMzEs IDIwMjAgYXQgOTo1OCBBTQ0KVG86IHRhcHMgV0cgPHRhcHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBb VGFwc10gT3BlbiBzb3VyY2UgYWN0aXZpdGllcz8NCg0KQ2FuIHNvbWVvbmUgcG9pbnQgbWUgdG8g YW55IG9wZW4gc291cmNlIHRhcHMgY29kZSBvdXQgdGhlcmU/IEkgd291bGQgbGlrZSB0byBnZXQg aW52b2x2ZWQgaW4gdGhpcyB3b3JrLg0K --_000_0453C855F1174997BDEA98449D5D545Cakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <1240E8A93EC1844B89CF9BA098A86B50@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjND MTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3 MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkg TWFydGluLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZXJl4oCZcyB0aGUgb25lIHRoYXQgTWF4 IGFuZCBUaGVyZXNhIGhhdmUgYmVlbiByZXBvcnRpbmcgb24gaW4gdGhlIHdnLCB0cnlpbmcgdG8g ZG8gYSBmYWl0aGZ1bCBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgc3BlYzo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9mZy1pbmV0 L3B5dGhvbi1hc3luY2lvLXRhcHMiPmh0dHBzOi8vZ2l0aHViLmNvbS9mZy1pbmV0L3B5dGhvbi1h c3luY2lvLXRhcHM8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvIG1lIGl04oCZcyBiZWVu IGEgcmVhbGx5IGdvb2QgcGxhY2UgdG8gdGlua2VyIGFuZCBnYWluIGdvb2QgaW5zaWdodHMuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGFkZGl0aW9uIHRvIHRoZSBleGFtcGxlcyBhbmQgdGVz dCBhcHBzIGluIHRoYXQgcHJvamVjdCwgd2UgdXNlZCB0aGUgbGlicmFyeSBhcyB0aGUgdHJhbnNw b3J0IGxpYnJhcnkgZm9yIGFub3RoZXIgZXhwZXJpbWVudGFsIHByb2plY3QsIHdoaWNoIEkgZG9u 4oCZdCB0aGluayB3ZSB0b3VjaGVkIGFnYWluIHlldCBzaW5jZSB0aGUgaGFja2F0aG9uIHdoZW4g d2Ugd29ya2VkIG9uIGl0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg aHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL0dydW1weU9sZFRyb2xsL2FtYmkiPmh0dHBzOi8vZ2l0 aHViLmNvbS9HcnVtcHlPbGRUcm9sbC9hbWJpPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J 4oCZbSBub3Qgc3VyZSBpZiB5b3Ugd2VyZSBsb29raW5nIG9ubHkgZm9yIG9wZW4tc291cmNlIGlt cGxlbWVudGF0aW9ucyBvZiBhIHRhcHMtcmVsYXRlZCBsaWJyYXJ5ICh3aGljaCBJ4oCZdmUgc28g ZmFyIG9ubHkgdXNlZCBweXRob24tYXN5bmNpby10YXBzLCBhYm92ZSksIG9yIHdoZXRoZXIgeW91 4oCZcmUgYWxzbyBsb29raW5nIGZvciBvcGVuLXNvdXJjZSByZXNvdXJjZXMgYWJvdXQgdXNpbmcg dGFwcy1saWtlIGxpYnJhcmllcw0KIHRvIGJ1aWxkIG90aGVyIHRoaW5ncy4mbmJzcDsgRm9yIGlu c3RhbmNlLCBJ4oCZdmUgc2VlbiBhIGZldyByZXNvdXJjZXMgdGhhdCBkaWcgaW50byB1c2luZyBB cHBsZeKAmXMgTmV0d29yayBmcmFtZXdvcms6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YSBocmVmPSJodHRwczovL3JkZXJpay5jb20vYmxvZy9idWlsZGluZy1hLXNlcnZl ci1jbGllbnQtYXBsaWNhdGlvbi11c2luZy1hcHBsZS1zLW5ldHdvcmstZnJhbWV3b3JrLyI+aHR0 cHM6Ly9yZGVyaWsuY29tL2Jsb2cvYnVpbGRpbmctYS1zZXJ2ZXItY2xpZW50LWFwbGljYXRpb24t dXNpbmctYXBwbGUtcy1uZXR3b3JrLWZyYW1ld29yay88L2E+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vYXBwbGUvc3dpZnQt bmlvLXRyYW5zcG9ydC1zZXJ2aWNlcyI+aHR0cHM6Ly9naXRodWIuY29tL2FwcGxlL3N3aWZ0LW5p by10cmFuc3BvcnQtc2VydmljZXM8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhUSC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkpha2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+TWFydGluIER1a2UgJmx0 O21hcnRpbi5oLmR1a2VAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIEF1 Z3VzdCAzMSwgMjAyMCBhdCA5OjU4IEFNPGJyPg0KPGI+VG86IDwvYj50YXBzIFdHICZsdDt0YXBz QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bVGFwc10gT3BlbiBzb3VyY2UgYWN0 aXZpdGllcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkNhbiBzb21lb25lIHBvaW50IG1lIHRvIGFueSBvcGVuIHNvdXJjZSB0YXBz IGNvZGUgb3V0IHRoZXJlPyBJIHdvdWxkIGxpa2UgdG8gZ2V0IGludm9sdmVkIGluIHRoaXMgd29y ay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0453C855F1174997BDEA98449D5D545Cakamaicom_-- From nobody Mon Aug 31 13:47:11 2020 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 1F5283A0486; Mon, 31 Aug 2020 13:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 4g8M94wVb1ZG; Mon, 31 Aug 2020 13:47:06 -0700 (PDT) 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 3005E3A046E; Mon, 31 Aug 2020 13:47:02 -0700 (PDT) Received: from mail-mx12.uio.no ([129.240.10.84]) by mail-out02.uio.no with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93.0.4) (envelope-from ) id 1kCqhg-0000r3-Et; Mon, 31 Aug 2020 22:47:00 +0200 Received: from ti0182q160-0624.bb.online.no ([109.189.132.119] helo=[192.168.1.12]) by mail-mx12.uio.no with esmtpsa (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) user michawe (Exim 4.93.0.4) (envelope-from ) id 1kCqhf-000CqU-0y; Mon, 31 Aug 2020 22:47:00 +0200 From: Michael Welzl Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3BFBDF01-97EA-4DE0-BE9B-17F25A8A2B49" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Date: Mon, 31 Aug 2020 22:46:58 +0200 In-Reply-To: <0453C855-F117-4997-BDEA-98449D5D545C@akamai.com> Cc: Martin Duke , "taps@ietf.org" To: "Holland, Jake" References: <0453C855-F117-4997-BDEA-98449D5D545C@akamai.com> X-Mailer: Apple Mail (2.3445.104.15) X-UiO-SPF-Received: Received-SPF: neutral (mail-mx12.uio.no: 109.189.132.119 is neither permitted nor denied by domain of ifi.uio.no) client-ip=109.189.132.119; envelope-from=michawe@ifi.uio.no; helo=[192.168.1.12]; X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, AWL=0.001, HTML_MESSAGE=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: AB6EFD6A0D5CB5A355FC3B5650C708DA2F8A2AE0 Archived-At: Subject: Re: [Taps] Open source activities? 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, 31 Aug 2020 20:47:09 -0000 --Apple-Mail=_3BFBDF01-97EA-4DE0-BE9B-17F25A8A2B49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 =E2=80=A6 and then there=E2=80=99s NEAT. NEAT was a European project, active until 2018, which started almost = exactly in sync with TAPS, and went along, building code. The NEAT project page is here: https://www.neat-project.org and the code is here: https://github.com/NEAT-project/neat It=E2=80=99s a TAPS type of system offering access to SCTP, among many = other things - I think it=E2=80=99s best classified as feature-rich, but = with holes and bugs=E2=80=A6 also, TAPS has changed after NEAT ended, = and so I advised a master thesis to build some kind of a shim layer, to = map a really up-to-date TAPS API in Python down to the functionality of = NEAT. That=E2=80=99s brand new, and here: https://github.com/theagilepadawan/NEATPy We always dreamt of adding QUIC to this code, but QUIC was still very = much a moving target when NEAT had long ended. Cheers, Michael > On Aug 31, 2020, at 10:19 PM, Holland, Jake = wrote: >=20 > Hi Martin, > =20 > Here=E2=80=99s the one that Max and Theresa have been reporting on in = the wg, trying to do a faithful implementation of the spec: > https://github.com/fg-inet/python-asyncio-taps = > =20 > To me it=E2=80=99s been a really good place to tinker and gain good = insights. > =20 > In addition to the examples and test apps in that project, we used the = library as the transport library for another experimental project, which = I don=E2=80=99t think we touched again yet since the hackathon when we = worked on it: > https://github.com/GrumpyOldTroll/ambi = > =20 > I=E2=80=99m not sure if you were looking only for open-source = implementations of a taps-related library (which I=E2=80=99ve so far = only used python-asyncio-taps, above), or whether you=E2=80=99re also = looking for open-source resources about using taps-like libraries to = build other things. For instance, I=E2=80=99ve seen a few resources = that dig into using Apple=E2=80=99s Network framework: > = https://rderik.com/blog/building-a-server-client-aplication-using-apple-s-= network-framework/ = > https://github.com/apple/swift-nio-transport-services = > =20 > HTH. > =20 > Best, > Jake > =20 > =20 > From: Martin Duke > Date: Monday, August 31, 2020 at 9:58 AM > To: taps WG > Subject: [Taps] Open source activities? > =20 > Can someone point me to any open source taps code out there? I would = like to get involved in this work. > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps --Apple-Mail=_3BFBDF01-97EA-4DE0-BE9B-17F25A8A2B49 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 =E2=80= =A6 and then there=E2=80=99s NEAT.

NEAT was a European project, active until 2018, which started = almost exactly in sync with TAPS, and went along, building = code.
The NEAT project page is here: https://www.neat-project.org
and the = code is here: https://github.com/NEAT-project/neat

It=E2=80=99s a TAPS type = of system offering access to SCTP, among many other things - I think = it=E2=80=99s best classified as feature-rich, but with holes and bugs=E2=80= =A6  also, TAPS has changed after NEAT ended, and so I advised a = master thesis to build some kind of a shim layer, to map a really = up-to-date TAPS API in Python down to the functionality of NEAT. = That=E2=80=99s brand new, and here:
https://github.com/theagilepadawan/NEATPy

We always dreamt of = adding QUIC to this code, but QUIC was still very much a moving target = when NEAT had long ended.

Cheers,
Michael


On Aug 31, 2020, at 10:19 PM, = Holland, Jake <jholland=3D40akamai.com@dmarc.ietf.org> = wrote:

Hi Martin,
 
Here=E2=80=99s the one = that Max and Theresa have been reporting on in the wg, trying to do a = faithful implementation of the spec:
https://github.com/fg-inet/python-asyncio-taps
 
To me it=E2=80=99s been a = really good place to tinker and gain good insights.
 
In addition to the = examples and test apps in that project, we used the library as the = transport library for another experimental project, which I don=E2=80=99t = think we touched again yet since the hackathon when we worked on it:
https://github.com/GrumpyOldTroll/ambi
 
I=E2=80=99m not sure if = you were looking only for open-source implementations of a taps-related = library (which I=E2=80=99ve so far only used python-asyncio-taps, = above), or whether you=E2=80=99re also looking for open-source resources = about using taps-like libraries to build other things.  For = instance, I=E2=80=99ve seen a few resources that dig into using = Apple=E2=80=99s Network framework:
https://rderik.com/blog/building-a-server-client-aplication-usi= ng-apple-s-network-framework/
https://github.com/apple/swift-nio-transport-services
 
HTH.
 
Best,
Jake
 
 
From: Martin Duke <martin.h.duke@gmail.com>
Date: Monday, August 31, 2020 = at 9:58 AM
To: taps WG <taps@ietf.org>
Subject: [Taps] Open source = activities?
 
Can someone point me to any open source = taps code out there? I would like to get involved in this work.
_______________________________________________
Taps mailing list
Taps@ietf.org
https://www.ietf.org/mailman/listinfo/taps

= --Apple-Mail=_3BFBDF01-97EA-4DE0-BE9B-17F25A8A2B49--