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

Michael Welzl <> Wed, 09 December 2015 08:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 92B251B29F5 for <>; Wed, 9 Dec 2015 00:28:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iIpWTwHxzNoD for <>; Wed, 9 Dec 2015 00:28:25 -0800 (PST)
Received: from ( [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2703F1B29EA for <>; Wed, 9 Dec 2015 00:28:24 -0800 (PST)
Received: from ([]) by with esmtp (Exim 4.80.1) (envelope-from <>) id 1a6a6o-0001jD-OI for; Wed, 09 Dec 2015 09:28:22 +0100
Received: from ([]) by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from <>) id 1a6a6o-00073b-4r for; Wed, 09 Dec 2015 09:28:22 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Michael Welzl <>
X-Priority: 3 (Normal)
In-Reply-To: <>
Date: Wed, 9 Dec 2015 09:28:20 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: "" <>
X-Mailer: Apple Mail (2.2104)
X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 5 sum rcpts/h 10 sum msgs/h 5 total rcpts 36236 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: 1737DCA7FBCA9D8786110D01ADBC6243540E3059
X-UiO-SPAM-Test: remote_host: spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 5 total 8700 max/h 17 blacklist 0 greylist 0 ratelimit 0
Archived-At: <>
Subject: Re: [Taps] RFC 6458 etc. in draft-welzl-taps-transports
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Dec 2015 08:28:28 -0000

> On 05 Dec 2015, at 17:02, Michael Tuexen <> wrote:
>> On 03 Nov 2015, at 14:33, wrote:
>> A note just on the INFO status of SCTP APIs (below):
>>> 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?
>> GF: From a TSVWG Chair perspective, beware here...  *ALL* more recent IETF
>> SCTP API work from TSVWG is INFO.  Each SCTP RFC is expected to have an
>> informative section that describes the API together with the normative
>> protocol spec. That is not because there are expected to be alternatives
>> to choose from:  It's because, as I understand, the IETF is not the formal
>> standards body for specification of such normative APIs.
> I would like to point out that the API sections focus on the socket based
> API described in RFC 6458.
> The abstract API described in RFC 4960 an the one described in RFC 6458
> are both informational. Therefore RFC 6458 should be also considered. You
> don't have to take the C structures and the exact function signatures into
> account, but you should consider what parameters can be changed, what
> information can be provided when sending a user message and so on.

That's in line with what Karen said. I wanted to hear a second opinion on this not because I didn't trust Karen's expertise (I do!) but because I wanted to make sure that I'm not doing this potentially rather large amount of work in vain.
=> that's all fine, I'll cover RFC 6458 in a future version of draft-welzl-taps-transports.


> The same applies to extensions. They don't have an abstract API at all,
> it was considered better to extend RFC 6458...
> Best regards
> Michael
>>> 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?
>>> Cheers,
>>> Michael
>>> _______________________________________________
>>> Taps mailing list
>> Gorry
>> _______________________________________________
>> Taps mailing list