Re: [Taps] IETF planning

[Aaron Falk <[e-mail]>]

On Mon, Oct 26, 2015 at 9:46 AM, Michael Welzl <[e-mail]> 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.
>