Re: [Taps] IETF planning

Aaron Falk <aaron.falk@gmail.com> Mon, 26 October 2015 16:35 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 7FE981B4F40 for <taps@ietfa.amsl.com>; Mon, 26 Oct 2015 09:35:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] 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 vZ0Cfl_VxCAH for <taps@ietfa.amsl.com>; Mon, 26 Oct 2015 09:35:55 -0700 (PDT)
Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (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 CA46E1B4F3F for <taps@ietf.org>; Mon, 26 Oct 2015 09:35:54 -0700 (PDT)
Received: by ykft191 with SMTP id t191so7135069ykf.0 for <taps@ietf.org>; Mon, 26 Oct 2015 09:35:54 -0700 (PDT)
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=CXOvJz/F4XpIPN+UpJE3wwzkE1N+XiMwsubtQ3k3CiM=; b=otX3xj/zBxE7wz/nXAs0JDeIBwd8Lmh7uoMfMzQGeZBodEy3G+XwpwUW39crSFT2Oy aAxlY/QwxcVPvWKVgf7CGkU+A9BKOdvUIDOVtAmTfqzqZ0rsVBtRa5B8e0pjgmFgowik KDVk/RSRf6HfQPWDTecsckgS80tkksiC1g1a+HuFxjWmV8xikD6h5AkXv6ONfcNobQE8 LS/E1FRXodBa4hRXBL3pQnwvw/pZscD51yFsJW6rDXikWiAUgZlunW6LIjCb1snv4P+l 8zZIueB7tqdjttTDYAm1KK8LlaxuyKo+fGGkVoRmw2V4qnalI2fSPa1ULNIzcU1asvTB DXEA==
MIME-Version: 1.0
X-Received: by 10.13.240.66 with SMTP id z63mr26149629ywe.261.1445877354055; Mon, 26 Oct 2015 09:35:54 -0700 (PDT)
Received: by 10.37.95.2 with HTTP; Mon, 26 Oct 2015 09:35:53 -0700 (PDT)
In-Reply-To: <564DD3D7-446B-4ABC-9A40-26E79DADD50E@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>
Date: Mon, 26 Oct 2015 12:35:53 -0400
Message-ID: <CAD62q9WAaHZ_OrueAa5u0rMuZGssC0mR+3gVWEBQ7DmDMm0cAQ@mail.gmail.com>
From: Aaron Falk <aaron.falk@gmail.com>
To: Michael Welzl <michawe@ifi.uio.no>
Content-Type: multipart/alternative; boundary=94eb2c035ec813d0b30523048e7a
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/OEEi2BIZ9CQe3uavGhTz5G9mRLA>
Cc: "<gorry@erg.abdn.ac.uk> Fairhurst" <gorry@erg.abdn.ac.uk>, 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: Mon, 26 Oct 2015 16:35:56 -0000

On Mon, Oct 26, 2015 at 9:46 AM, Michael Welzl <michawe@ifi.uio.no> wrote:

>
> Working towards a realistic end-goal of a deployable system.
>
> So we’re i) describing services; ii) narrowing them down somehow; iii)
> describing how to build this thing.
> My concern is with iii) being something feasible and useful, not an
> obscure sci-fi document.
>

Uh, yeah.  That's our charter.  Narrowing down is in doc 2.  Are you making
the case we should do it in doc 1?



>
> Say we include DCCP. It’ll add some services that aren’t in the other
> protocols listed so far in this mail - e.g. drop notification (see section
> 3.6.3 in draft-ietf-taps-transports). Say, in step ii), we find no good
> arguments to remove drop notification. Then, in step iii), we’ll have to
> say how a TAPS system can support drop notification. So, to build a working
> TAPS system, one has to either:
> - include DCCP in the code base
> - extend other protocols to provide this functionality
>
> None of these two options are very helpful if we want to TAPS to be real
> thing one day.
>

a: TAPS is not chartered to do anything normative.  Doc 3 is about
experimenting.

b: You are having the discussion that we planned to have for Doc 2.  Make
your case to drop those protocols then.  Or, if no one wants to write
sections for the additional protocols for Doc 1a (an extended version of
draft-welzl-taps-transports), then folks are voting with their feet on the
utility of keeping them.

c: One of the goals of TAPS is to enable deployment of transport protocols
such as DCCP where networks permit it without forcing application (or
library) authors to handle probe and fallback.  If we don't include
protocols that aren't seeing deployment, what is the value of this activity?


>
> I understand that we can see these as optional, and end up with a document
> iii) that has a small mandatory base and lots of optional things - but this
> will then be a huge document, of which only a small subset will ever be
> implemented. Personally I think that’s a possibility but not really what we
> should aim at.
>