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

Aaron Falk <aaron.falk@gmail.com> Tue, 17 November 2015 15:08 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B409E1A900B for <taps@ietfa.amsl.com>; Tue, 17 Nov 2015 07:08:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, WEIRD_PORT=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGuAY_G-CKsb for <taps@ietfa.amsl.com>; Tue, 17 Nov 2015 07:08:46 -0800 (PST)
Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (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 2FC461A8F3E for <taps@ietf.org>; Tue, 17 Nov 2015 07:08:46 -0800 (PST)
Received: by ykdv3 with SMTP id v3so12275689ykd.0 for <taps@ietf.org>; Tue, 17 Nov 2015 07:08:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FH0F2+9Gvmx+gWCIeyKxMBoW3WqECI48p4pcBZ3esn8=; b=ZsYApZIsdtpoS1yWrGvJk7KztH/9pNJORCVjM1BUBSkDJLoBzsNZKLbvz0uHD/Mn+o 7Kq5pX2xn/Kg4sZWSZrMP6eHlvq7/ugRXQlahiI7HpuSjWjjr69gLmzWLf1kORzl48tH 1PGNMymOtpqsncfTnH9ctUSxmIHzmb1/xftJshjMHdS0kIju3I/H7AOwkY+VkcRv8NCh Hv818djWxvEIysnJktp9vH6ESanwslhIXcPz2+WFoIqZGC5f2ZenIvs69B9YJLvxNvWz Ho/L1MBxKT93J+NYKB619Fc4jNiWC8F66E94cLmYIGUZtGgI3CPcs6g0zlz3BkFMo6HE /jyQ==
MIME-Version: 1.0
X-Received: by 10.13.240.66 with SMTP id z63mr40783689ywe.261.1447772925368; Tue, 17 Nov 2015 07:08:45 -0800 (PST)
Received: by 10.37.95.2 with HTTP; Tue, 17 Nov 2015 07:08:45 -0800 (PST)
In-Reply-To: <834552EA-50F3-4F67-A1D4-5FAF8BFD2561@ifi.uio.no>
References: <CAD62q9WD8=KgWQkuJwfKMwMCAc7BLBcbWNknEQv160+h9YZQOQ@mail.gmail.com> <834552EA-50F3-4F67-A1D4-5FAF8BFD2561@ifi.uio.no>
Date: Tue, 17 Nov 2015 10:08:45 -0500
Message-ID: <CAD62q9V+NStHg6Zjb4twqGGsT=3-Kxt10qV+6f__vsTXVNNLwg@mail.gmail.com>
From: Aaron Falk <aaron.falk@gmail.com>
To: Michael Welzl <michawe@ifi.uio.no>
Content-Type: multipart/alternative; boundary=94eb2c035ec8eea2230524bde699
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/B9fTAo9XmQr05o_YH-04MUTTT14>
Cc: David C Lawrence <tale@akamai.com>, Kyle Rose <Krose@krose.org>, "taps@ietf.org" <taps@ietf.org>
Subject: Re: [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: Tue, 17 Nov 2015 15:08:49 -0000

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 <michawe@ifi.uio.no> wrote:

> Hi,
>
> Two comments in line:
>
>
>
> > On 17 Nov 2015, at 00:21, Aaron Falk <aaron.falk@gmail.com> 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
>
>