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

From: TAPS WG status robot <[email-masked]>
Date: Fri, 22 Nov 2019 08:00:09 +0000

Issues
------
* ietf-tapswg/api-drafts (+12/-25/💬38)
  12 issues created:
  - Experimental cost property: cost preference (by mwelzl)
    https://github.com/ietf-tapswg/api-drafts/issues/384 [API] [discuss] 
  - Multicast impact on architecture? (by abrunstrom)
    https://github.com/ietf-tapswg/api-drafts/issues/382 [Architecture] 
  - Multiple receives convenience feature (by MaxF12)
    https://github.com/ietf-tapswg/api-drafts/issues/375 
  - Protocols in Figure 2 (by abrunstrom)
    https://github.com/ietf-tapswg/api-drafts/issues/374 [Architecture] 
  - Transport Properties are not Connection Objects (by abrunstrom)
    https://github.com/ietf-tapswg/api-drafts/issues/373 
  - Do we need an example for an HTTP/1, HTTP/2, HTTP/3 agnostic connection? (by philsbln)
    https://github.com/ietf-tapswg/api-drafts/issues/371 
  - Implementation - PMTU text is broken (by gorryfair)
    https://github.com/ietf-tapswg/api-drafts/issues/367 [Implementation] [ready for text] 
  - Some editorial (I hope) comments on implementation (by gorryfair)
    https://github.com/ietf-tapswg/api-drafts/issues/366 
  - Architecture: Editorial comments (by theri)
    https://github.com/ietf-tapswg/api-drafts/issues/365 
  - Update wording where interface to security protocol implies racing/abstraction (by squarooticus)
    https://github.com/ietf-tapswg/api-drafts/issues/364 
  - "Access to Specialized Features" example: Security protocols (by theri)
    https://github.com/ietf-tapswg/api-drafts/issues/363 [Architecture] 
  - -impl should say more about use of ALPN (by mirjak)
    https://github.com/ietf-tapswg/api-drafts/issues/362 [Architecture] 

  21 issues received 38 new comments:
  - #375 Multiple receives convenience feature (6 by britram, mwelzl, philsbln, tfpauly, MaxF12)
    https://github.com/ietf-tapswg/api-drafts/issues/375 [API] [discuss] 
  - #384 Experimental cost property: cost preference (5 by philsbln, mwelzl, gorryfair, tfpauly)
    https://github.com/ietf-tapswg/api-drafts/issues/384 [API] [discuss] 
  - #362 -impl should say more about use of ALPN (3 by philsbln, gorryfair, theri)
    https://github.com/ietf-tapswg/api-drafts/issues/362 [Implementation] 
  - #363 "Access to Specialized Features" example: Security protocols (3 by philsbln, abrunstrom, squarooticus)
    https://github.com/ietf-tapswg/api-drafts/issues/363 [Architecture] 
  - #382 Multicast impact on architecture? (3 by tfpauly)
    https://github.com/ietf-tapswg/api-drafts/issues/382 [Architecture] 
  - #305 Protocol stacks that are not equivalent (2 by britram, theri)
    https://github.com/ietf-tapswg/api-drafts/issues/305 [Architecture] 
  - #374 Protocols in Figure 2 (2 by mwelzl, tfpauly)
    https://github.com/ietf-tapswg/api-drafts/issues/374 [Architecture] 
  - #258 Do we need a terminology section in arch? (1 by britram)
    https://github.com/ietf-tapswg/api-drafts/issues/258 [Architecture] [discuss] 
  - #145 Draft should point at implementations somewhere (1 by tfpauly)
    https://github.com/ietf-tapswg/api-drafts/issues/145 [Implementation] [ready for text] 
  - #150 Add Unidirectional Streams for Multicast / Source and Sink support  (1 by MaxF12)
    https://github.com/ietf-tapswg/api-drafts/issues/150 [API] [Implementation] [ready for text] 
  - #154 Structure of implementation draft (1 by tfpauly)
    https://github.com/ietf-tapswg/api-drafts/issues/154 [Implementation] 
  - #177 Privacy considerations section (1 by tfpauly)
    https://github.com/ietf-tapswg/api-drafts/issues/177 [API] [Implementation] [ready for text] 
  - #299 TAPS ARCH - Textual review to notes (1 by tfpauly)
    https://github.com/ietf-tapswg/api-drafts/issues/299 [Architecture] 
  - #45 Do we need to make state storage explicit in the architecture and API? (1 by britram)
    https://github.com/ietf-tapswg/api-drafts/issues/45 [API] [Architecture] [ready for text] 
  - #312 Detailed author review of Arch text for -03 to prepare -04 (1 by tfpauly)
    https://github.com/ietf-tapswg/api-drafts/issues/312 [Architecture] [ready for text] 
  - #324 Add explicit protocol selection. (1 by britram)
    https://github.com/ietf-tapswg/api-drafts/issues/324 [API] [ready for text] 
  - #334 Consider message send API that takes padding policy as input (1 by britram)
    https://github.com/ietf-tapswg/api-drafts/issues/334 [API] [future work] 
  - #357 Default values (1 by britram)
    https://github.com/ietf-tapswg/api-drafts/issues/357 [API] [discuss] [ready for text] 
  - #364 Update wording where interface to security protocol implies racing/abstraction (1 by theri)
    https://github.com/ietf-tapswg/api-drafts/issues/364 
  - #365 Architecture: Editorial comments (1 by britram)
    https://github.com/ietf-tapswg/api-drafts/issues/365 [Architecture] 
  - #249 API needs a way to handle "STARTTLS" (1 by britram)
    https://github.com/ietf-tapswg/api-drafts/issues/249 [API] [Architecture] [discuss] 

  25 issues closed:
  - Experimental cost property: cost preference https://github.com/ietf-tapswg/api-drafts/issues/384 [API] [discuss] 
  - Add Unidirectional Streams for Multicast / Source and Sink support  https://github.com/ietf-tapswg/api-drafts/issues/150 [API] [Implementation] [ready for text] 
  - Structure of implementation draft https://github.com/ietf-tapswg/api-drafts/issues/154 [Implementation] 
  - Draft should point at implementations somewhere https://github.com/ietf-tapswg/api-drafts/issues/145 [Implementation] [ready for text] 
  - Multicast impact on architecture? https://github.com/ietf-tapswg/api-drafts/issues/382 [Architecture] 
  - Architecture: Editorial comments https://github.com/ietf-tapswg/api-drafts/issues/365 [Architecture] [ready for text] 
  - Protocols in Figure 2 https://github.com/ietf-tapswg/api-drafts/issues/374 [Architecture] 
  - Add explicit protocol selection. https://github.com/ietf-tapswg/api-drafts/issues/324 [API] [ready for text] 
  - Define the server-side equivalent of racing https://github.com/ietf-tapswg/api-drafts/issues/206 [API] [Architecture] [ready for text] 
  - Clarification on queued receives https://github.com/ietf-tapswg/api-drafts/issues/309 [API] [ready for text] 
  - Architecture privacy and security considerations https://github.com/ietf-tapswg/api-drafts/issues/178 [Architecture] [ready for text] 
  - "Events" versus "Callbacks" for security-relevant asynchrony https://github.com/ietf-tapswg/api-drafts/issues/347 [API] [Architecture] [ready for text] 
  - Add property for address privacy https://github.com/ietf-tapswg/api-drafts/issues/300 [API] [ready for text] 
  - More expressive multipath transport property https://github.com/ietf-tapswg/api-drafts/issues/303 [API] [ready for text] 
  - Consider message send API that takes padding policy as input https://github.com/ietf-tapswg/api-drafts/issues/334 [API] [future work] 
  - Multiple receives convenience feature https://github.com/ietf-tapswg/api-drafts/issues/375 [API] [discuss] 
  - TAPS ARCH - Textual review to notes https://github.com/ietf-tapswg/api-drafts/issues/299 [Architecture] 
  - Do we need to make state storage explicit in the architecture and API? https://github.com/ietf-tapswg/api-drafts/issues/45 [API] [Architecture] [ready for text] 
  - Implementation should describe how to handle proxies/TOR https://github.com/ietf-tapswg/api-drafts/issues/282 [Implementation] [discuss] [help wanted] 
  - Default values https://github.com/ietf-tapswg/api-drafts/issues/357 [API] [discuss] [ready for text] 
  - Failure of unsatisfiable configurations https://github.com/ietf-tapswg/api-drafts/issues/306 [API] 
  - Add re-initiate() call for voluntary connection migration  https://github.com/ietf-tapswg/api-drafts/issues/270 [API] [future work] 
  - Do we need a terminology section in arch? https://github.com/ietf-tapswg/api-drafts/issues/258 [Architecture] [discuss] 
  - API needs a way to handle "STARTTLS" https://github.com/ietf-tapswg/api-drafts/issues/249 [API] [Architecture] [discuss] 
  - Detailed author review of Arch text for -03 to prepare -04 https://github.com/ietf-tapswg/api-drafts/issues/312 [Architecture] [ready for text] 

Pull requests
-------------
* ietf-tapswg/api-drafts (+13/-11/💬11)
  13 pull requests submitted:
  - Editorial comments, fixes #365 (by theri)
    https://github.com/ietf-tapswg/api-drafts/pull/383 
  - Move Transport Properties text and close #373 (by philsbln)
    https://github.com/ietf-tapswg/api-drafts/pull/381 
  - Add clarification on Multicast receive to API (by MaxF12)
    https://github.com/ietf-tapswg/api-drafts/pull/380 
  - TAPS allows you to dynamically choose protocol stacks, we should say so. (by britram)
    https://github.com/ietf-tapswg/api-drafts/pull/379 
  - closes #324 (by mwelzl)
    https://github.com/ietf-tapswg/api-drafts/pull/378 
  - Partial receives are not reordering preferences; fix #309 (by britram)
    https://github.com/ietf-tapswg/api-drafts/pull/377 
  - Add text for server-side "racing" (by tfpauly)
    https://github.com/ietf-tapswg/api-drafts/pull/376 
  - Address privacy property, #300 (by tfpauly)
    https://github.com/ietf-tapswg/api-drafts/pull/372 
  - Add multipath property enumeration (by tfpauly)
    https://github.com/ietf-tapswg/api-drafts/pull/370 
  - add dates to references, and clean up spurious ones (by britram)
    https://github.com/ietf-tapswg/api-drafts/pull/369 
  - be explicit and careful about callbacks vs events; fix #347 (by britram)
    https://github.com/ietf-tapswg/api-drafts/pull/368 
  - fixes for a few nits (by GrumpyOldTroll)
    https://github.com/ietf-tapswg/api-drafts/pull/361 
  - udp multicast receive (#150) (by GrumpyOldTroll)
    https://github.com/ietf-tapswg/api-drafts/pull/360 

  3 pull requests received 11 new comments:
  - #360 udp multicast receive (#150) (9 by MaxF12, philsbln, mwelzl, theri)
    https://github.com/ietf-tapswg/api-drafts/pull/360 
  - #378 closes #324 (1 by britram)
    https://github.com/ietf-tapswg/api-drafts/pull/378 
  - #380 Add clarification on Multicast receive to API (1 by philsbln)
    https://github.com/ietf-tapswg/api-drafts/pull/380 

  11 pull requests merged:
  - Add clarification on Multicast receive to API
    https://github.com/ietf-tapswg/api-drafts/pull/380 
  - Editorial comments, fixes #365
    https://github.com/ietf-tapswg/api-drafts/pull/383 
  - TAPS allows you to dynamically choose protocol stacks, we should say so.
    https://github.com/ietf-tapswg/api-drafts/pull/379 
  - Add text for server-side "racing"
    https://github.com/ietf-tapswg/api-drafts/pull/376 
  - Partial receives are not reordering preferences; fix #309
    https://github.com/ietf-tapswg/api-drafts/pull/377 
  - be explicit and careful about callbacks vs events; fix #347
    https://github.com/ietf-tapswg/api-drafts/pull/368 
  - Add multipath property enumeration
    https://github.com/ietf-tapswg/api-drafts/pull/370 
  - Address privacy property, #300
    https://github.com/ietf-tapswg/api-drafts/pull/372 
  - add dates to references, and clean up spurious ones
    https://github.com/ietf-tapswg/api-drafts/pull/369 
  - udp multicast receive (#150)
    https://github.com/ietf-tapswg/api-drafts/pull/360 
  - fixes for a few nits
    https://github.com/ietf-tapswg/api-drafts/pull/361 

Repositories tracked by this digest:
-----------------------------------
* https://github.com/ietf-tapswg/api-drafts

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Fri, 22 Nov 2019 16:04:33 +0800

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-masked]> 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
> 	• #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)
> 	• #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) 
> 	• #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
> 	• https://github.com/ietf-tapswg/api-drafts
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Aaron Falk <[email-masked]>
Date: Fri, 22 Nov 2019 16:06:57 +0800

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-masked]>
wrote:

> >       • #375 Multiple receives convenience feature (6 by britram,
> mwelzl, philsbln, tfpauly, MaxF12) API discuss
> >       • #363 "Access to Specialized Features" example: Security
> protocols (3 by philsbln, abrunstrom, squarooticus) Architecture
> >       • #150 Add Unidirectional Streams for Multicast / Source and Sink
> support (1 by MaxF12) API Implementation ready for text
> >       • #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
> >       • #150 Add Unidirectional Streams for Multicast / Source and Sink
> support API Implementation ready for text
> >       • #347 "Events" versus "Callbacks" for security-relevant
> asynchrony API Architecture ready for text
> >       • #45 Do we need to make state storage explicit in the
> architecture and API? API Architecture ready for text
> (by britram)
> (by britram)

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Sun, 24 Nov 2019 06:03:45 +0100

hi Aaron,

> On 22 Nov 2019, at 16:06, Aaron Falk <[email-masked]> wrote:
> 
> 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-masked]> wrote: