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) <[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
