Thanks, Michael. I've put fixes in the etherpad version. Feel free to review & revise at http://etherpad.tools.ietf.org:9000/p/notes-ietf-94-taps.
--aaron On Tue, Nov 17, 2015 at 3:26 AM, Michael Welzl <[email protected]> wrote: > Hi, > > Two comments in line: > > > > > On 17 Nov 2015, at 00:21, Aaron Falk <[email protected]> wrote: > > > > Kyle Rose has done a nice job with the minutes based on his and Dave > Lawrence's notes. Many thanks, guys! > > > > TAPS folk: please review these minutes and send comments to the list. > > > > Thanks, > > > > --aaron > > > > taps minutes > > IETF-94 Yokohama > > Reported by David Lawrence and Kyle Rose > > > > Note Well covered. > > > > 1. Agenda bashing > > 2. WG Status > > 3. draft-ietf-taps-transports > > 4. draft-welzl-taps-transports > > 5. A way forward for "document 2" > > 6. AOB > > > > Dec 2015 planned: Document 1, informational, to be sent to IESG defining > services provided by IETF transport protos and congestion control > mechanisms. > > > > > ------------------------------------------------------------------------------ > > Brian Trammell, speaking on draft-ietf-taps-transports (version 7) > > > > Charter and abstract basically unchanged since last meeting. Thinks the > document is ready for December publication. There are a few editor's notes > which can mostly be dropped, except for some text needed in 3.9.2 about the > RTP interface. Drop section 4.1 (Transport Matrix). Then push as -08 and > ready for WGLC. > > > > Poll of room: anyone see any issues to prevent it going to WGLC? > Silence. > > > > > ------------------------------------------------------------------------------ > > Naeem Khademi, speaking on draft-welzl-taps-transports-00 > > > > Scope of the draft: describe only existing IETF protos for two endpoint > comms. Covers only TCP and SCTP currently, but he intends to cover all the > protocols listed. > > > > Goal: use a generic approach to help designers/API devs to know how to > use the protocols. > > > > 3 pass approach: > > > > • 1. relevant parts of proto RFCs are summarized as to what they > provide and how they are used. Identify all defined forms of interaction > between the proto and its user. > > > > • 2. categorize into connection-related vs. data transmission, > such as identifying connect() in TCP as connection-related and sending and > receiving as about data transmission. > > > > • 3. present a superset of all services in all protos, turning it > upside down. For each service, list which protocols provide it. > > > > Karen: The document here needs to refer to latest RFCs on SCTP, like > 6458, not just 4960. > > Christian: We use protocols based on how they work and what costs are > involved, not solely based on the API that's available. Some cost resulting > from an implementation that does not appear anywhere in the API needs to be > taken into account. > > Aaron: Problem as he understood it is that there is a desire to be able > to use new protocols (starting with existing standards) where they would > work, and fall back to older protocols where they don't work. Goal wasn't > composition, but to use the best protocol you can that works end-to-end. > > Mirja: What's needed is a good interface for choosing the right protocol. > > Christian: Choose HTTP over TCP because they want to get through > firewalls, or need to limit overhead, etc. > > Brian: deconstructing and reconstructing each protocol has been a very > useful process. Would be interesting to see whether you get the same > result if you used SCTP's abstract API vs the newer SCTP socket api. > > > > Mic (?): Doesn't seem that your looked at differences in implementations > from RFC specifications. Really should cover that. > > Naeem: Hope to cover implementations as doc evolves. > > Having watched it on the mic, I can't remember the statement on the mic or > how it was phrased right now - but I do remember that Naeem's answer was > about covering other protocols than just SCTP and TCP. In the minutes here > it looks different. > > > > Gorry via Jabber: Just add the protos from mailing list discussion (UDP, > UDP-Lite, MPTCP, DTLS and TLS). And probably DCCP. (General agreement on > Cory's suggestion.) Will confirm on mailing list. > > > > Aaron: Who's read the document? Raise your hands. > > Not many people have read the document, but at least the people at the > microphone had. > > > > Aaron: Hum if we should adopt doc (as supplement to target 1). Some > humming. Not? Silence. > > > > Determined that a milestone should be added based on what the document > addresses, but this does not require a change to the WG scope, and > therefore no change required to the charter. (Aaron) It is also the case > that two documents can address one milestone. (Brian T.) > > > > Naeem will change his document to conform to the group's terminology > throughout. (Implication is that the other document will be changed as > well, if necessary.) > > > > > ------------------------------------------------------------------------------ > > Stein Gjessing on document 2, defining taps system between application > layer and transport layer. > > > > Thinks that draft-welzl-taps-transport should really be addressing the > needs of document 2, specifing a minimal taps interface to the transport > protos. > > This is wrong, it's not what was presented. Stein said that document 2 > should be **based upon** draft-welzl-taps-transport because this explains > the "how", not the "what" (which is addressed by > draft-ietf-taps-transports). > > Cheers, > Michael > >
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
