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
