[Taps] Draft TAPS minutes from IETF-94

Aaron Falk <aaron.falk@gmail.com> Mon, 16 November 2015 23:21 UTC

Return-Path: <aaron.falk@gmail.com>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 5091B1A8AA5 for <taps@ietfa.amsl.com>; Mon, 16 Nov 2015 15:21:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 04b5MNNh3yxX for <taps@ietfa.amsl.com>; Mon, 16 Nov 2015 15:21:11 -0800 (PST)
Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D17E1A8AAC for <taps@ietf.org>; Mon, 16 Nov 2015 15:21:09 -0800 (PST)
Received: by ykdr82 with SMTP id r82so266642413ykd.3 for <taps@ietf.org>; Mon, 16 Nov 2015 15:21:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=+fj4+656CE4KbwXV7PAoN3GUu+p2+JP3+rzcgE0OPXY=; b=G83bEFN/jbqPXJfRio8Bd/MJHoLgH9lExqEvGRt80xgHhFo0V/D8nzoMJnCY/IPW21 +x6tdvJJje3waWYSooS4uQ5rAhoDbUDK5af5fgPQt1ZfhZVhJNjDoaACfWo3Bx8pGiXN gbUzgD4mi5GjgU9zL7oC5PITtInxmRcC8RlMk+zhPa7sKSCDfcxbaWxwxsA7nKyY+40D KZcgchlqZy/lA+sSHXGxKYrSl3e1j+aarFdNB8IH3KxtObQfYC5B9vXZMLJmUNwXSbXn 4joOBq5QjLayrY8NFwmy3pf+1QyDzjnOdTaMtQomp1MJoL5f+cbrU/MVwO58oNADyDYa hRHQ==
MIME-Version: 1.0
X-Received: by with SMTP id w4mr37927781ywe.110.1447716068437; Mon, 16 Nov 2015 15:21:08 -0800 (PST)
Received: by with HTTP; Mon, 16 Nov 2015 15:21:08 -0800 (PST)
Date: Mon, 16 Nov 2015 18:21:08 -0500
Message-ID: <CAD62q9WD8=KgWQkuJwfKMwMCAc7BLBcbWNknEQv160+h9YZQOQ@mail.gmail.com>
From: Aaron Falk <aaron.falk@gmail.com>
To: "taps@ietf.org" <taps@ietf.org>
Content-Type: multipart/alternative; boundary=94eb2c08813afebbdb0524b0a9a1
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/YlZjXXF467UgU9LsU-uhrMXMQoE>
Cc: David C Lawrence <tale@akamai.com>, Kyle Rose <Krose@krose.org>
Subject: [Taps] Draft TAPS minutes from IETF-94
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Nov 2015 23:21:14 -0000

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.



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

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.

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

A document 3 is needed to describe an abstract interface between taps and

Aaron: Looking for volunteers to do close review of
draft-ietf-taps-tranports-08.  (Silence, unfortunately.)

AOB: ... none.