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

Michael Welzl <> Tue, 17 November 2015 08:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5D7C81B2C7B for <>; Tue, 17 Nov 2015 00:26:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oIHMLS1rDIr5 for <>; Tue, 17 Nov 2015 00:26:18 -0800 (PST)
Received: from ( [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7E7CE1B2C7A for <>; Tue, 17 Nov 2015 00:26:18 -0800 (PST)
Received: from ([]) by with esmtp (Exim 4.80.1) (envelope-from <>) id 1Zybai-0001PB-8r; Tue, 17 Nov 2015 09:26:16 +0100
Received: from ([]) by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from <>) id 1Zybah-000100-Lr; Tue, 17 Nov 2015 09:26:16 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Welzl <>
In-Reply-To: <>
Date: Tue, 17 Nov 2015 09:26:14 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Aaron Falk <>
X-Mailer: Apple Mail (2.2104)
X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 3 sum rcpts/h 6 sum msgs/h 3 total rcpts 35281 max rcpts/h 54 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-6.1, required=5.0, autolearn=disabled, RP_MATCHES_RCVD=-1.051, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: EA9C445D2F090123ED37D97BC7F68F01F7A7BACF
X-UiO-SPAM-Test: remote_host: spam_score: -60 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 8423 max/h 17 blacklist 0 greylist 0 ratelimit 0
Archived-At: <>
Cc: David C Lawrence <>, Kyle Rose <>, "" <>
Subject: Re: [Taps] Draft TAPS minutes from IETF-94
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Nov 2015 08:26:21 -0000


Two comments in line:

> On 17 Nov 2015, at 00:21, Aaron Falk <> 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).