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 _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
