Re: [Taps] Draft TAPS minutes

[Michael Welzl <[e-mail]>]

Hi,

Two fixes inline:


> On Dec 21, 2017, at 7:10 PM, Aaron Falk <[e-mail]> wrote:
> 
> We’re overdue for filing the minutes from our Singapore meeting. Please give the (very good) notes by Kyle & Tale a look and send comments.
> 
> —aaron
> 
> TAPS
> IETF-100 Singapore
> Tuesday, November 14, 2017
> Room: Olivia
> 
> Minute takers:
> Kyle Rose
> tale
> 
> Chairs update - 10 min
> 
> Charter bashng
> Chris, Aaron, Kyle agreed we need more precise charter language for the WG's transport security function.
> draft-ietf-taps-minset-00 - Michael Wizel, University of Oslo -15 min
> 
s/Wizel/Welzl  pretty please  :-)


> Brian Trammell
> Is this an API certification? <laugh>
> There's an implicit assumption of ordering in protocols based on number of features
> From standpoint of feature set that you need to meet, that's the right way to think about it
> Thinks doc is close to done
> Tommy Pauly
> Need to explicitly declare required features for a transport up-front
> Remove all references to "fallback" because it implies a particular set of preferences/priorities that imply a total order
> Instead, just catalog protocols by features provided and leave ordering to another doc
> Spencer Dawkins (responsible AD)
> Agrees with Tommy
> Completeness
> Aaron: What is required for document to be complete?
> Michael: Tommy to proofread
> Gabriel: Is CoAP supported?
> Michael: Minset analysis based on a survey of important existing transport protocols
> Aaron: Goal of minset is to identify minimum set of functions that a TAPS API should support to cover the basic set of functionality required by IETF protocols. If there's something missing from CoAP, maybe there's stuff in minset that shouldn't be there; alternatively, it may be that CoAP is not expressive enough to be usable through the TAPS API
> Bob Moskovitz: Purpose of TAPS should be to disconnect the application from the details of the transport, whether or not a constrained transport <---this probably needs clarification
> Tommy: (missed)
> Mirja: How to map this to post-sockets? Anything that isn't related to connection establishment or data transfer should be separated out
> Michael: "Maintenance" covers the configuration aspects of protocols
> Tommy: Pieces of functionality that are core transport functionality, and then protocol-specific (or model-specific) things that need to be separated out
> Michael: Need to distinguish between what needs to be said up-front, but I don't like the idea of separating out core functionality from non-core
> Mirja: There is a box called "configuration" in post-sockets. We need to know what goes in there.
> Brian: There are things you need to do during connection setup that can't be changed without tearing down connection state: not maintenance. Is this an API specification? It's a specification for APIs that implement TAPS. Would be useful if the knobs available here were organized in a better way. May just need to add another layer to express additional configuration.
> draft-trammell-taps-post-sockets-03, Brian Trammell, ETH Zurich - 20 min
> 
> Brian Trammel
> Hard requirement that the protocol stack configuration work without a requirement that a bunch of config be provided.
> "Configuration" box is what you use to constrain the magic protocol configuration state maintained for a path in the association.
> Obviate the need for dicking around with sockopts because the defaults are saner.
> Tommy Pauly
> IF you use TCP, set this option; IF you choose SCTP, do this. Extra knobs if you need something very specific.
> Noted another change in the draft is around messages; we like the message abstraction but need to understand how that relates to streams and chunking
> Praveen from Microsoft
> How do you reconcile system configuration with app configuration(? not sure I got that right)
> Brian: the jokey answers is that it sort of looks like cascading style sheets, using predictable overrides to get a final instance configuration. hope to do better than CSS
> Kyle Rose
> Re predictability and "too much magic" making things hard to figure out with regard to performance targets etc
> Brian: Yes really, let's talk about this offline because it'll be like a half hour discussion
> Accessability of specific aspects of different transport protocol features (maybe non-obvious requirements, like degrading perf on purpose for testing purposes)
> Brian: the intention is to make it all available through the API if you know which one you're working with
> Brian
> Open issues:
> a protocol-independent carrier state machine
> how to represent certain transport-specific interactions
> Bring this into the wg now?
> critical mass of Abstract interface proposals now
> ready to take the creative leap to design the API
> Aaron: actually this does sound like a charter change for architecture
> name?: In a way this is looking at "maxset" rather than "minset"
> Michael Wetzl: the reason the charter is so conservative was because people couldn't really agree so had to be pared down. Agree that it is good to have a higher layer, but concerned about the implementability
> Aaron: moving into the territory of a charter revision, which we're not going to talk about right now. mic closed.
> draft-tiesel-taps-socketintents-01, Philipp S. Tiesel, TU Berlin - 20 min
> 
> Automated Transport Option Selection (see slides)
> Desire to use same set of (essential) keywords no matter what programming language is being used
> Main questions: is this easy enough and useful enough to devs? sufficient to express the usual set of intents? what's missing?
> Michael Wetzl:
> could be missing out some things that might not be obvious from looking at current protocols
s/Wetzl/Welzl  pretty please  :-)
and: my statement here, in this context, sounds as if I said that the socketintents draft "could be missing out some things …”. I believe I said the opposite: that this could be useful because it shows us things that we might otherwise miss. Suggested re-phrasing:
***
this could show us some things that we might be missing out, as they might not be obvious from looking at current protocols
***

That’s it from my side. Thanks, cheers
Michael