Re: [Taps] Draft TAPS minutes from IETF-94

[Aaron Falk <[e-mail]>]

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 <[e-mail]> wrote:

> Hi,
>
> Two comments in line:
>
>
>
> > On 17 Nov 2015, at 00:21, Aaron Falk <[e-mail]> 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
>
>