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

Aaron Falk <aaron.falk@gmail.com> Fri, 22 November 2019 08:07 UTC

Return-Path: <aaron.falk@gmail.com>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50AF412004A for <taps@ietfa.amsl.com>; Fri, 22 Nov 2019 00:07:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAQbKoGZJ8qo for <taps@ietfa.amsl.com>; Fri, 22 Nov 2019 00:07:10 -0800 (PST)
Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AE1E12003E for <taps@ietf.org>; Fri, 22 Nov 2019 00:07:10 -0800 (PST)
Received: by mail-pl1-x635.google.com with SMTP id ay6so2819605plb.0 for <taps@ietf.org>; Fri, 22 Nov 2019 00:07:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Re4q3UrYr+c5vUV+B+WwpMObT0nCC73Xh/zz8PthXWg=; b=IUCXviwmso6J0HF8RpMo0kVp7rQE4BPhh8SAxmHQS5Ou8AB9nob0ni53QmLhnBPiQK +e0sHwYCM9oHR+/sKBoVXuN+eTKQKAwJO4omu/jqM5t4dH3NMX2Yy+1UEW2cCm0o3uer VjVTCahSO+sFFpTJDkFN5hYt2rbc2Qc3ivbpfvpGbnbwCZvQM0zguSgGqOnZhKgaazao QGTdRc7gPhvuZ4wWf+PmzLutl2bOLSMd2VrWht5dlKC8m7j5Pc71q1KzUR35TOds8GqI erLs0YewKBzaS1BvXf083ayaETRqahmcpnMQ4zDMslZvDsoW90k/rq756VfGmSYkl0Ad o9pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Re4q3UrYr+c5vUV+B+WwpMObT0nCC73Xh/zz8PthXWg=; b=Zo4qHqpUYmhUqWwFNBFImaArhPCBMtXO7YfFe+8dwL0IUOcmu8FqpCJAdHPyk4bSOf 4/YIaTMbKUI8NqhHv8zg+dgzuoIVBKo0TZD05mZIRZuDn6xZeZHYG7F1wFt/WEDU7f8j tvp8TvtYxdgtU4cqbSRhaltikdoZr25lVuMz+pVdjrmETrko1SpDDBY82bF1EgB30hIm mrFDAzPbFqJb0MPmuYVjXg3NTZ2dSNFEv0a02lQLUKbAEw1AI8O0/PyEe2iEjqSSWx56 XlrX+GHj4t7NE1EjZ+F3nMB6E+bcixg+p3c0hsNbGIbwxdvGChfiae/7CqO4HAPBXRZL MhNQ==
X-Gm-Message-State: APjAAAURr3oyWfxsxt/JS2J9HBm3jAqw/f63RzyGbXGu5hUNPpHn+ipT ijF3fdhPzgeJAhmEC5Qtsm9rqrM4FbsoLWTJzMkj74oW
X-Google-Smtp-Source: APXvYqwh6634/cFdwUJZxKdSj6BoixRLu9oEkVTrE2elQoliibse7WQK4J1tlD0Ac0JXhVJoBIASGXMTeq5upOp9T3U=
X-Received: by 2002:a17:90a:a45:: with SMTP id o63mr17208131pjo.45.1574410028953; Fri, 22 Nov 2019 00:07:08 -0800 (PST)
MIME-Version: 1.0
References: <E1iY3rN-00056B-VM@magpie.corvid.ch> <FF1C9AD2-5A25-44B0-A6B5-A516B79A64C8@trammell.ch>
In-Reply-To: <FF1C9AD2-5A25-44B0-A6B5-A516B79A64C8@trammell.ch>
From: Aaron Falk <aaron.falk@gmail.com>
Date: Fri, 22 Nov 2019 16:06:57 +0800
Message-ID: <CAD62q9VV4Qt8U3yirjm4h0x2EX-qhJT_3F7wFrJr+EYY1yhJCA@mail.gmail.com>
To: "Brian Trammell (IETF)" <ietf@trammell.ch>
Cc: taps WG <taps@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000081b7f00597eae6cd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/9kOLS2KhasMqtp0km3t19QhoN3U>
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: Fri, 22 Nov 2019 08:07:12 -0000

Yes, indeed. This is awesome.

Brian, do you think you can create a last cal-able version of -arch by the
1st week of December?

On Fri, Nov 22, 2019 at 4:04 PM Brian Trammell (IETF) <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
>