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

Michael Welzl <michawe@ifi.uio.no> Wed, 09 December 2015 08:28 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B251B29F5 for <taps@ietfa.amsl.com>; Wed, 9 Dec 2015 00:28:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIpWTwHxzNoD for <taps@ietfa.amsl.com>; Wed, 9 Dec 2015 00:28:25 -0800 (PST)
Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (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 2703F1B29EA for <taps@ietf.org>; Wed, 9 Dec 2015 00:28:24 -0800 (PST)
Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from <michawe@ifi.uio.no>) id 1a6a6o-0001jD-OI for taps@ietf.org; Wed, 09 Dec 2015 09:28:22 +0100
Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from <michawe@ifi.uio.no>) id 1a6a6o-00073b-4r for taps@ietf.org; 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 <michawe@ifi.uio.no>
X-Priority: 3 (Normal)
In-Reply-To: <C3052E94-31A5-433D-AAFF-B69AFCD0A7F4@lurchi.franken.de>
Date: Wed, 9 Dec 2015 09:28:20 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <CF76B11D-72C0-4BC4-A444-337669C002B1@ifi.uio.no>
References: <945E755A-3EB4-4325-8257-9ECC2EE3FC4B@ifi.uio.no> <6f6d07994fde18062e39ced796f199a9.squirrel@erg.abdn.ac.uk> <C3052E94-31A5-433D-AAFF-B69AFCD0A7F4@lurchi.franken.de>
To: "taps@ietf.org" <taps@ietf.org>
X-Mailer: Apple Mail (2.2104)
X-UiO-SPF-Received:
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: 129.240.68.135 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: <http://mailarchive.ietf.org/arch/msg/taps/LuQnCcESQsDHEx2wz8z9wnTjCgU>
Subject: Re: [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: Wed, 09 Dec 2015 08:28:28 -0000

> On 05 Dec 2015, at 17:02, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
> 
>> On 03 Nov 2015, at 14:33, gorry@erg.abdn.ac.uk 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.

Cheers,
Michael


> 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
>>> Taps@ietf.org
>>> https://www.ietf.org/mailman/listinfo/taps
>>> 
>> Gorry
>> 
>> _______________________________________________
>> Taps mailing list
>> Taps@ietf.org
>> https://www.ietf.org/mailman/listinfo/taps
>> 
>