IETF Logo Mail Archive

Re: [Taps] IETF planning

Michael Welzl <michawe@ifi.uio.no> Tue, 27 October 2015 14:30 UTC

Return-Path: <michawe@ifi.uio.no>
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 8CE861A8A75 for <taps@ietfa.amsl.com>; Tue, 27 Oct 2015 07:30:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 epDCExFRgCKU for <taps@ietfa.amsl.com>; Tue, 27 Oct 2015 07:30:53 -0700 (PDT)
Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597601A8A71 for <taps@ietf.org>; Tue, 27 Oct 2015 07:30:53 -0700 (PDT)
Received: from mail-mx1.uio.no ([129.240.10.29]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from <michawe@ifi.uio.no>) id 1Zr5H0-0007g3-Mx; Tue, 27 Oct 2015 15:30:50 +0100
Received: from 173.179.249.62.customer.cdi.no ([62.249.179.173] helo=[192.168.0.101]) by mail-mx1.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from <michawe@ifi.uio.no>) id 1Zr5H0-0005I2-4s; Tue, 27 Oct 2015 15:30:50 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Welzl <michawe@ifi.uio.no>
In-Reply-To: <9C828361-EA04-4FB2-89D6-49678B60245C@mjmontpetit.com>
Date: Tue, 27 Oct 2015 15:30:48 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8032F291-F984-40D0-A599-0BA7AE8DE5E0@ifi.uio.no>
References: <64271754-EED2-4322-BB0E-51CB66365682@gmail.com> <B36B9E5E-0EB5-418A-A6A1-E103C8ECF500@ifi.uio.no> <CCC80AEF-66CD-4497-A374-2ED89DF4FA17@trammell.ch> <CAD62q9XQMSyuG_=HYjXKe12iE=-F3HasXqrmJs+RAQeBZbddCQ@mail.gmail.com> <562DF846.7090901@erg.abdn.ac.uk> <CAD62q9XjebXmRHUebJLrd35=PnrLPGCZFv4LBO5omYBh2J+72Q@mail.gmail.com> <564DD3D7-446B-4ABC-9A40-26E79DADD50E@ifi.uio.no> <CAD62q9WAaHZ_OrueAa5u0rMuZGssC0mR+3gVWEBQ7DmDMm0cAQ@mail.gmail.com> <27697ADF-7AE6-4E99-8288-FF19A68F1411@ifi.uio.no> <6F9FB87C-D0FF-46B3-A634-8A2E1234F9B7@tik.ee.ethz.ch> <9C828361-EA04-4FB2-89D6-49678B60245C@mjmontpetit.com>
To: Marie-Jose Montpetit <marie@mjmontpetit.com>
X-Mailer: Apple Mail (2.2104)
X-UiO-SPF-Received:
X-UiO-Ratelimit-Test: rcpts/h 17 msgs/h 4 sum rcpts/h 23 sum msgs/h 5 total rcpts 34410 max rcpts/h 54 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, TVD_RCVD_IP=0.001, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: BCA84EFA8A8A1991893C2E31D483E3DE50CF08EA
X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 99990 minaction 1 bait 0 mail/h: 4 total 1975 max/h 14 blacklist 0 greylist 0 ratelimit 0
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/vo5ORsImTPUyG1b9zks7uhGOtEE>
Cc: Aaron Falk <aaron.falk@gmail.com>, "<gorry@erg.abdn.ac.uk> Fairhurst" <gorry@erg.abdn.ac.uk>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Brian Trammell <ietf@trammell.ch>, "taps@ietf.org" <taps@ietf.org>, Stein Gjessing <steing@ifi.uio.no>
Subject: Re: [Taps] IETF planning
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, 27 Oct 2015 14:30:54 -0000

> On 27. okt. 2015, at 15.08, Marie-Jose Montpetit <marie@mjmontpetit.com> wrote:
> 
> I agree with Mirja. We have done a lot of “background” work up to now and I don’t mind long documents as long as they are useful references which I think the current document is. I am ok with keeping the work on draft-welzl-taps-transports. But I would also want to move to the next steps - not that I want a science experiment but my interest from the beginning was to define how applications can use transports more efficiently both for existing transports and potential future ones - APIs, discovery etc. I don’t think we need detailed lists of features as all these transports are documented elsewhere but better means to advertise them and use them.

How are you going to do this when you don’t know what applies to connection opening, connection maintenance, data transfer? What kinds of error messages are available?
I think it’s a much more obvious step from draft-welzl-taps-transports to a generic TAPS API than from draft-ietf-taps-transports, and that’s the whole point. draft-ietf-taps-transports is a nice survey but it doesn’t really help you much for creating an API, I think.

Cheers,
Michael

v2.23.0 | Report a Bug | By Email