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 >
- [Taps] Weekly github digest (TAPS GitHub Activity… TAPS WG status robot
- Re: [Taps] Weekly github digest (TAPS GitHub Acti… Brian Trammell (IETF)
- Re: [Taps] Weekly github digest (TAPS GitHub Acti… Aaron Falk
- Re: [Taps] Weekly github digest (TAPS GitHub Acti… Brian Trammell (IETF)