[Taps] RFC 6458 etc. in draft-welzl-taps-transports

Michael Welzl <michawe@ifi.uio.no> Tue, 03 November 2015 12:40 UTC

Return-Path: <michawe@ifi.uio.no>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 563321B3302 for <taps@ietfa.amsl.com>; Tue, 3 Nov 2015 04:40:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id bay5dWJ1C_9I for <taps@ietfa.amsl.com>; Tue, 3 Nov 2015 04:40:41 -0800 (PST)
Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FB2E1B32EF for <taps@ietf.org>; Tue, 3 Nov 2015 04:40:40 -0800 (PST)
Received: from mail-mx4.uio.no ([]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from <michawe@ifi.uio.no>) id 1ZtatC-0006m3-An for taps@ietf.org; Tue, 03 Nov 2015 13:40:38 +0100
Received: from boomerang.ifi.uio.no ([]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from <michawe@ifi.uio.no>) id 1ZtatB-0002RR-Qg for taps@ietf.org; Tue, 03 Nov 2015 13:40:38 +0100
From: Michael Welzl <michawe@ifi.uio.no>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <945E755A-3EB4-4325-8257-9ECC2EE3FC4B@ifi.uio.no>
Date: Tue, 3 Nov 2015 13:40:37 +0100
To: taps WG <taps@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
X-Mailer: Apple Mail (2.2104)
X-UiO-Ratelimit-Test: rcpts/h 10 msgs/h 6 sum rcpts/h 13 sum msgs/h 7 total rcpts 34691 max rcpts/h 54 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 25C5B682D7BA082FF25E5339B406ECB0C9CD73C9
X-UiO-SPAM-Test: remote_host: spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 6 total 8165 max/h 17 blacklist 0 greylist 0 ratelimit 0
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/dKfCmrN9lomwNQ0N5J43jHuQlSw>
Subject: [Taps] RFC 6458 etc. in draft-welzl-taps-transports
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: Tue, 03 Nov 2015 12:40:44 -0000

Dear all,

Sorry for not being able to attend the TAPS meeting on site or even remotely. I just finished watching the recording, and I noticed that the question of RFC 6458  - "why is the SCTP part of draft-welzl- ..  based on only RFC 4960 and not on RFC 6458?" - was brought up several times. I'd like to provide an answer and start a discussion about this.

There are two reasons why RFC 6458 wasn't used in draft-welzl-taps-transports-00: a very mundane one, and a more serious one. I'll list them both and hope we can discuss the second reason.

1) Reason one: RFC 6458 is quite long, and I wanted to limit the amount of work I'm putting into the -00 version, given that the point was to show people the procedure and the idea and see what they think, and not to fully cover everything 100% correctly yet. Basically, I didn't want to risk writing out all the stuff from RFC 6458 and then have people tell me to go away  :-)

2) Reason two, more serious: RFC 6458 is Informational, and my understanding was that this is just one description of one API implementation, not a recommendation or even prescription of what all SCTP implementations must provide. However, my decision for draft-welzl-taps-transports was to *exclude* things that are only optional to implement - I don't think we want to end up with a TAPS system that provides services that, alas, on Operating System XY are not available because here only a subset of the API is implemented. Therefore I went with a minimal set of functions that I thought we can assume are implemented everywhere (well, at least in every system that claims to "follow the spec").  Can we assume that every system that claims to implement SCTP in accordance with the spec fully implements RFC 6458?

A side note about TCP, because Karen made a comment about the TCP API too:  a similar logic applies here, irrespective of whether the API is old or not: I think we should cover whatever a system claiming to "implement the protocol in accordance with the spec" has to cover. Going down the path of looking at actual socket API implementations is dangerous in that we end up in "only implemented here, not there" - land. We want a minimal set of mechanisms that are (or at least really should be! for that, what else can we use as a basis than our own recommendations?!) available everywhere. Karen, you specifically mentioned URG and PSH and how they are implemented; what is it in draft-welzl-.. about these two mechanisms that you don't agree with?