Hi, Two fixes inline:
> On Dec 21, 2017, at 7:10 PM, Aaron Falk <[email protected]> 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
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
