hi Aaron, > On 22 Nov 2019, at 16:06, Aaron Falk <[email protected]> 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) <[email protected]> > 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 <[email protected]> > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
