> On 27. okt. 2015, at 10.44, Karen Elisabeth Egede Nielsen > <[email protected]> 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 _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
