IETF Logo Mail Archive

Re: [Taps] Weekly github digest (TAPS GitHub Activity Digest)

"Brian Trammell (IETF)" <ietf@trammell.ch> Sun, 24 November 2019 05:03 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5B812008F for <taps@ietfa.amsl.com>; Sat, 23 Nov 2019 21:03:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kddOVbqQubTD for <taps@ietfa.amsl.com>; Sat, 23 Nov 2019 21:03:49 -0800 (PST)
Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA35120071 for <taps@ietf.org>; Sat, 23 Nov 2019 21:03:49 -0800 (PST)
Received: from smtp-3-0001.mail.infomaniak.ch ([10.4.36.108]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id xAO53jq0004916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 24 Nov 2019 06:03:45 +0100
Received: from [10.11.33.88] (unknown [145.14.214.39]) by smtp-3-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 73257100764F3; Sun, 24 Nov 2019 06:03:45 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: "Brian Trammell (IETF)" <ietf@trammell.ch>
In-Reply-To: <CAD62q9VV4Qt8U3yirjm4h0x2EX-qhJT_3F7wFrJr+EYY1yhJCA@mail.gmail.com>
Date: Sun, 24 Nov 2019 06:03:45 +0100
Cc: taps WG <taps@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7A167010-F87D-47D5-90D7-CAB5B45E0E56@trammell.ch>
References: <E1iY3rN-00056B-VM@magpie.corvid.ch> <FF1C9AD2-5A25-44B0-A6B5-A516B79A64C8@trammell.ch> <CAD62q9VV4Qt8U3yirjm4h0x2EX-qhJT_3F7wFrJr+EYY1yhJCA@mail.gmail.com>
To: Aaron Falk <aaron.falk@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8
X-Antivirus-Code: 0x100000
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/w9dnExKZ5l4XUCac7LfV5NsgleQ>
Subject: Re: [Taps] Weekly github digest (TAPS GitHub Activity Digest)
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Nov 2019 05:03:53 -0000

hi Aaron,

> On 22 Nov 2019, at 16:06, Aaron Falk <aaron.falk@gmail.com> wrote:
> 
> Yes, indeed. This is awesome. 
> 
> Brian, do you think you can create a last cal-able version of -arch by the 1st week of December?

That seems reasonable. There is one open PR and three open issues, all assigned, which will result in two more smallish PRs. I've done an editorial pass on the plane which will result in a tiny PR and one hopefully-simple issue to discuss.

Cheers,

Brian


> 
> On Fri, Nov 22, 2019 at 4:04 PM Brian Trammell (IETF) <ietf@trammell.ch> wrote:
> Wow! The robot can write long messages, too. Good work, everyone!
> 
> Cheers,
> 
> Brian
> 
> > On 22 Nov 2019, at 16:00, TAPS WG status robot <tapsbot@magpie.corvid.ch> wrote:
> > 
> > Friday November 22, 2019
> > 
> > Issues
> > 
> > ietf-tapswg/api-drafts (+12/-25/💬38)
> > 12 issues created:
> > 
> >       • #384 Experimental cost property: cost preference (by mwelzl) API discuss
> >       • #382 Multicast impact on architecture? (by abrunstrom) Architecture
> >       • #375 Multiple receives convenience feature (by MaxF12) 
> >       • #374 Protocols in Figure 2 (by abrunstrom) Architecture
> >       • #373 Transport Properties are not Connection Objects (by abrunstrom) 
> >       • #371 Do we need an example for an HTTP/1, HTTP/2, HTTP/3 agnostic connection? (by philsbln) 
> >       • #367 Implementation - PMTU text is broken (by gorryfair) Implementation ready for text
> >       • #366 Some editorial (I hope) comments on implementation (by gorryfair) 
> >       • #365 Architecture: Editorial comments (by theri) 
> >       • #364 Update wording where interface to security protocol implies racing/abstraction (by squarooticus) 
> >       • #363 "Access to Specialized Features" example: Security protocols (by theri) Architecture
> >       • #362 -impl should say more about use of ALPN (by mirjak) Architecture
> > 21 issues received 38 new comments:
> > 
> >       • #375 Multiple receives convenience feature (6 by britram, mwelzl, philsbln, tfpauly, MaxF12) API discuss
> >       • #384 Experimental cost property: cost preference (5 by philsbln, mwelzl, gorryfair, tfpauly) API discuss
> >       • #362 -impl should say more about use of ALPN (3 by philsbln, gorryfair, theri) Implementation
> >       • #363 "Access to Specialized Features" example: Security protocols (3 by philsbln, abrunstrom, squarooticus) Architecture
> >       • #382 Multicast impact on architecture? (3 by tfpauly) Architecture
> >       • #305 Protocol stacks that are not equivalent (2 by britram, theri) Architecture
> >       • #374 Protocols in Figure 2 (2 by mwelzl, tfpauly) Architecture
> >       • #258 Do we need a terminology section in arch? (1 by britram) Architecture discuss
> >       • #145 Draft should point at implementations somewhere (1 by tfpauly) Implementation ready for text
> >       • #150 Add Unidirectional Streams for Multicast / Source and Sink support (1 by MaxF12) API Implementation ready for text
> >       • #154 Structure of implementation draft (1 by tfpauly) Implementation
> >       • #177 Privacy considerations section (1 by tfpauly) API Implementation ready for text
> >       • #299 TAPS ARCH - Textual review to notes (1 by tfpauly) Architecture
> >       • #45 Do we need to make state storage explicit in the architecture and API? (1 by britram) API Architecture ready for text
> >       • #312 Detailed author review of Arch text for -03 to prepare -04 (1 by tfpauly) Architecture ready for text
> >       • #324 Add explicit protocol selection. (1 by britram) API ready for text
> >       • #334 Consider message send API that takes padding policy as input (1 by britram) API future work
> >       • #357 Default values (1 by britram) API discuss ready for text
> >       • #364 Update wording where interface to security protocol implies racing/abstraction (1 by theri) 
> >       • #365 Architecture: Editorial comments (1 by britram) Architecture
> >       • #249 API needs a way to handle "STARTTLS" (1 by britram) API Architecture discuss
> > 25 issues closed:
> > 
> >       • #384 Experimental cost property: cost preference API discuss
> >       • #150 Add Unidirectional Streams for Multicast / Source and Sink support API Implementation ready for text
> >       • #154 Structure of implementation draft Implementation
> >       • #145 Draft should point at implementations somewhere Implementation ready for text
> >       • #382 Multicast impact on architecture? Architecture
> >       • #365 Architecture: Editorial comments Architecture ready for text
> >       • #374 Protocols in Figure 2 Architecture
> >       • #324 Add explicit protocol selection. API ready for text
> >       • #206 Define the server-side equivalent of racing API Architecture ready for text
> >       • #309 Clarification on queued receives API ready for text
> >       • #178 Architecture privacy and security considerations Architecture ready for text
> >       • #347 "Events" versus "Callbacks" for security-relevant asynchrony API Architecture ready for text
> >       • #300 Add property for address privacy API ready for text
> >       • #303 More expressive multipath transport property API ready for text
> >       • #334 Consider message send API that takes padding policy as input API future work
> >       • #375 Multiple receives convenience feature API discuss
> >       • #299 TAPS ARCH - Textual review to notes Architecture
> >       • #45 Do we need to make state storage explicit in the architecture and API? API Architecture ready for text
> >       • #282 Implementation should describe how to handle proxies/TOR Implementation discuss help wanted
> >       • #357 Default values API discuss ready for text
> >       • #306 Failure of unsatisfiable configurations API
> >       • #270 Add re-initiate() call for voluntary connection migration API future work
> >       • #258 Do we need a terminology section in arch? Architecture discuss
> >       • #249 API needs a way to handle "STARTTLS" API Architecture discuss
> >       • #312 Detailed author review of Arch text for -03 to prepare -04 Architecture ready for text
> > Pull requests
> > 
> > ietf-tapswg/api-drafts (+13/-11/💬11)
> > 13 pull requests submitted:
> > 
> >       • #383 Editorial comments, fixes #365 (by theri) 
> >       • #381 Move Transport Properties text and close #373 (by philsbln) 
> >       • #380 Add clarification on Multicast receive to API (by MaxF12) 
> >       • #379 TAPS allows you to dynamically choose protocol stacks, we should say so. (by britram) 
> >       • #378 closes #324 (by mwelzl) 
> >       • #377 Partial receives are not reordering preferences; fix #309 (by britram) 
> >       • #376 Add text for server-side "racing" (by tfpauly) 
> >       • #372 Address privacy property, #300 (by tfpauly) 
> >       • #370 Add multipath property enumeration (by tfpauly) 
> >       • #369 add dates to references, and clean up spurious ones (by britram) 
> >       • #368 be explicit and careful about callbacks vs events; fix #347 (by britram) 
> >       • #361 fixes for a few nits (by GrumpyOldTroll) 
> >       • #360 udp multicast receive (#150) (by GrumpyOldTroll) 
> > 3 pull requests received 11 new comments:
> > 
> >       • #360 udp multicast receive (#150) (9 by MaxF12, philsbln, mwelzl, theri) 
> >       • #378 closes #324 (1 by britram) 
> >       • #380 Add clarification on Multicast receive to API (1 by philsbln) 
> > 11 pull requests merged:
> > 
> >       • #380 Add clarification on Multicast receive to API
> >       • #383 Editorial comments, fixes #365
> >       • #379 TAPS allows you to dynamically choose protocol stacks, we should say so.
> >       • #376 Add text for server-side "racing"
> >       • #377 Partial receives are not reordering preferences; fix #309
> >       • #368 be explicit and careful about callbacks vs events; fix #347
> >       • #370 Add multipath property enumeration
> >       • #372 Address privacy property, #300
> >       • #369 add dates to references, and clean up spurious ones
> >       • #360 udp multicast receive (#150)
> >       • #361 fixes for a few nits
> > Repositories tracked by this digest:
> > 
> >       • https://github.com/ietf-tapswg/api-drafts
> > _______________________________________________
> > Taps mailing list
> > Taps@ietf.org
> > https://www.ietf.org/mailman/listinfo/taps
> 
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps

v2.23.0 | Report a Bug | By Email