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

> 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
>> 
> 