Subject: [Taps] TAPS interim meeting notes

From: Chris Wood <[email-masked]>
Date: Thu, 17 May 2018 09:23:22 -0700

Hi everyone,

Here are notes from yesterday’s call. 

Best,
Chris

——

# TAPS Interim (5/16/2018)

## Participants
Aaron Falk / TAPS Working Group Chair 
Spencer Dawkins / Transport Area Director 
Philipp S. Tiesel 
Gorry Fairhurst / UoA 
Theresa 
Michael Welzl 
Brian Trammell 
Colin Perkins 
Jonathan Lennox 
Anna Brunstrom / KAU 
Tommy Pauly 
Chris Wood
Marie-José Montpetit 
Kyle Rose 
Marie-José 
Mirja Kuehlewind

## https://github.com/taps-api/
- https://github.com/taps-api/drafts/issues/35
    - Several options:
        - Specify a registry for enumerated path types and services. In IANA? Elsewhere?
        - Alternatively, make registry implementation specific (and punt the issue)
        - Both: use "local" registry, and point to IANA one for guidelines and recommendations.
            - bitram: against pointing to IANA registry mess
        - Perhaps consider specifying special PVDs too
- https://github.com/taps-api/drafts/issues/37
    - Pass
- https://github.com/taps-api/drafts/issues/53
    - Marking Final on messages allows multiple messages per connection to be sent, and also maps to TCP FIN nicely
    - Receivers can check the Final property to see if the connection is complete
    - Whether or not setting Final on a Send is reflected on the recevier is a property of the transport. (TCP handles this nicely, UDP not so much.)
- https://github.com/taps-api/drafts/issues/59
    - (Unrelated to #60)
    - Goal is to have more abstract Intents enforced (?) by the policy engine
    - Should survey applications and extract concrete use cases for this feature
        - Choosing the right level of abstraction will be challenging
- https://github.com/taps-api/drafts/issues/60
    - Which parameters should be standardized? Still unclear. Half may be duped to #59.
    - Propose moving discussion to #59 and closing.
- https://github.com/taps-api/drafts/issues/102
    - Cannot depend on DPRIVE or correctness of name resolution.
    - Application should control when resolution occurs, probably before connections start (during preconnection).
    - Why do applications want to know about the time of resolution?
        - Applications might want specific behavior during pre-connect and connect stages, e.g., to permit resolution across one interface over another
        - Want to balance latency and privacy considerations
    - Should make privacy-respecting resolution strategies the default, and allow applications to opt in to aggressive (privacy unfriendly) strategies
    - Earliest time for resolution is during system setup, e.g., if system has a cache of domains previously queried in the past
    - Side bar: missing a Privacy Considerations section in all three drafts: https://github.com/taps-api/drafts/issues/177
        - Should these be scattered or colocated? Not all documents are reviewed at the same time.
- https://github.com/taps-api/drafts/issues/112
    - Deferred to in-person discussion
    - Issue: how does one offer early data support in the API
    - (See issue for proposals)
        - Apple: Send/enqueue as much idempotent data before calling Start(), and let the protocol configuration(s) and implementation(s) figure out if it can be sent as early data or not
    - What about receiver side distinguishing between early data and not?
        - https://github.com/taps-api/drafts/issues/179
- https://github.com/taps-api/drafts/issues/147
    - No response from Mark Handley yet
    - Will decompose the issue into specific API points to consider
- https://github.com/taps-api/drafts/issues/153
    - Ready for text
- https://github.com/taps-api/drafts/issues/160
    - Per-context threads are needed for servers supporting many simultaneous connections
    - Applications should be able to tune the number of contexts, and number of threads per context (perhaps bound to number of available cores)
        - One thread per socket is probably best practice
    - Teardown events should be generated locally, not from remote events (RST)
    - Need implementation text (from Tom) before closing
- https://github.com/taps-api/drafts/issues/170
    - Do we have a solid use case for this?
    - Could bring back Source and Sink for multicast, or allow RO or WO properties for connections

## https://github.com/mami-project/draft-pauly-transport-security
- Changes from 00
    - Rewrite section 4 to better articular mandatory vs optional features, and their transport and application dependencies (PR #27)
    - Add text to protocol descriptions 
    - Started security review, still awaiting feedback
- Outstanding issues:
    - Protocol descriptions need more text (WIP)
    - Selection rationale: https://github.com/mami-project/draft-pauly-transport-security/issues/29
        - ... "we chose <foo> because it represents the superset of all interesting security features the TAPS API needs to express" ...

## WG issues
- minset is in WGLC -- please read and provide comments
    - Will push out one week to allow for more reviews