IETF Logo Mail Archive

Re: [Taps] IETF planning

Brian Trammell <ietf@trammell.ch> Thu, 22 October 2015 20:23 UTC

Return-Path: <ietf@trammell.ch>
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 AC2D91B40A9 for <taps@ietfa.amsl.com>; Thu, 22 Oct 2015 13:23:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level:
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, 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 tyrg4wVBU6Go for <taps@ietfa.amsl.com>; Thu, 22 Oct 2015 13:23:34 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id B4A5E1B40A7 for <taps@ietf.org>; Thu, 22 Oct 2015 13:23:34 -0700 (PDT)
Received: from [IPv6:2001:470:26:9c2:8c88:436c:e6dd:5a22] (unknown [IPv6:2001:470:26:9c2:8c88:436c:e6dd:5a22]) by trammell.ch (Postfix) with ESMTPSA id 8A7D21A0023; Thu, 22 Oct 2015 22:23:33 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <AF2FC069-ED58-49AC-B0F9-D543E4C2647B@ifi.uio.no>
Date: Thu, 22 Oct 2015 22:23:32 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <D51861E2-8667-46D8-9082-C7290F92563A@trammell.ch>
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>
To: Michael Welzl <michawe@ifi.uio.no>
X-Mailer: Apple Mail (2.2104)
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/VemSBavpHCIfQlyVpfTwVnlrYZ4>
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: Thu, 22 Oct 2015 20:23:36 -0000

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.

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?

Cheers,

Brian

> Thoughts?
> 
> Cheers,
> Michael
> 
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps

v2.23.0 | Report a Bug | By Email