IETF Logo Mail Archive

Re: [Taps] IETF planning

Michael Welzl <michawe@ifi.uio.no> Fri, 23 October 2015 07:13 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 4FE881ACCDF for <taps@ietfa.amsl.com>; Fri, 23 Oct 2015 00:13:22 -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 AoyYi-H9XQMn for <taps@ietfa.amsl.com>; Fri, 23 Oct 2015 00:13:20 -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 196511B2E03 for <taps@ietf.org>; Fri, 23 Oct 2015 00:13:19 -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 1ZpWXM-0004SP-MO; Fri, 23 Oct 2015 09:13:16 +0200
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 1ZpWXL-0000t2-Ty; Fri, 23 Oct 2015 09:13:16 +0200
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: <D51861E2-8667-46D8-9082-C7290F92563A@trammell.ch>
Date: Fri, 23 Oct 2015 09:13:15 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <FA298C98-9B97-41B5-B2F7-399CB13BE683@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> <AF2FC069-ED58-49AC-B0F9-D543E4C2647B@ifi.uio.no> <D51861E2-8667-46D8-9082-C7290F92563A@trammell.ch>
To: Brian Trammell <ietf@trammell.ch>
X-Mailer: Apple Mail (2.2104)
X-UiO-SPF-Received:
X-UiO-Ratelimit-Test: rcpts/h 4 msgs/h 1 sum rcpts/h 9 sum msgs/h 4 total rcpts 34254 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: 43FABF687368A835B1EFEED408CF96C691304297
X-UiO-SPAM-Test: remote_host: 62.249.179.173 spam_score: -49 maxlevel 99990 minaction 1 bait 0 mail/h: 1 total 1910 max/h 14 blacklist 0 greylist 0 ratelimit 0
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/5yCG1Ya9WX2k6vLRvLCWWn6kvrc>
Cc: Aaron Falk <aaron.falk@gmail.com>, Stein Gjessing <steing@ifi.uio.no>, "taps@ietf.org" <taps@ietf.org>
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: Fri, 23 Oct 2015 07:13:22 -0000

> On 22. okt. 2015, at 22.23, Brian Trammell <ietf@trammell.ch> wrote:
> 
> hi Michael,
> 
>> On 22 Oct 2015, at 18:19, Michael Welzl <michawe@ifi.uio.no> wrote:
>> 
>> 
>>> On 22. okt. 2015, at 16.14, Aaron Falk <aaron.falk@gmail.com> wrote:
>>> 
>>> 
>>>> draft-welzl-taps-transports currently only covers TCP and SCTP. But then: how many other protocols?
>>>> It seems people agree that the protocols covered in draft-welzl-taps-transports should be a subset of the protocols covered in draft-ietf-taps-transports. My question is, then: how to choose the subset?
>>>> 
>>>> It seems obvious to include protocols that are seeing some deployment, i.e. of course UDP, maybe UDP-Lite (?), but also MPTCP…
>>>> However: if that is the only decision ground, we probably wouldn’t include DCCP. Are we then making a significant mistake, missing a lesson to be learned?
>>>> 
>>>> That, to me, is a discussion I’d like to have in Yokohama.
>>> 
>>> +1, and FWIW that's exactly the same starting point I got to on my own.
>>> 
>>> 
>>> Any volunteers to kick off the lead the discussion?
>> 
>> Let me try to roll this some more on the list, because I gave it some thought:
>> 
>> The goal is to have something buildable. So if we allow protocols that are hardly deployed into draft-welzl-taps-transports, then this gives us a list that may include services that one can never implement unless hardly-deployed protocol X is used, or other protocols are extended to all of a sudden provide this functionality.
>> 
>> Thus, boring as it may seem, “widely deployed protocols” can be the only reasonable criterion to allow adding protocols in draft-welzl-taps-transports
> 
> s/widely deployed/widely implemented/g, but yes.

Agreed


> Another thought: draft-gjessing (as it currently is) looks at the minimal set of services. If there are services we believe are useful to support that are not presently widely implemented or deployed, we can certainly add them as optional, no? The only services that could not be handled in such a way would be those that have an impact on the API other than just adding knobs and meters, no?

Sorry, you lose me here - in particular I don’t get the part about “have an impact on the API…”. Could you maybe give a toy example?

Cheers,
Michael

v2.30.2 | Report a Bug | By Email | System Status