Re: [Taps] IETF planning

[Michael Welzl <[e-mail]>]

> On 27. okt. 2015, at 10.44, Karen Elisabeth Egede Nielsen <[e-mail]> wrote:
> 
> HI,
> 
> Just a note. Not necessarily relevant for the overall argument however.
> 
>>> 
>>> 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.
>>> 
>>> 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
>>> 
> 
> SCTP also provides drop notification (SEND_FAILURE).

… and it’s actually covered in draft-welzl-taps-transports, on page 16  ( https://tools.ietf.org/html/draft-welzl-taps-transports-00#section-4.2 ). Silly me!

It’s an interesting example, though: forgetting that drop notification (with a cause code) exists in SCTP, I picked “drop notification” as an example service of DCCP because I remembered it as an interesting functionality when the protocol was made, and (more importantly) because it kind of stood out in the list in draft-ietf-transports.

Maybe the right thing to do is to use the list of “transport features" in draft-ietf-transports to see if a protocol adds anything new to the mix or is really just essentially duplicating services that already exist in the other protocols in draft-welzl-taps-transports, and use that to decide whether to include a protocol or not?

Cheers,
Michael