> On 05 Dec 2015, at 17:02, Michael Tuexen <[email protected]> > wrote: > >> On 03 Nov 2015, at 14:33, [email protected] 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/taps >>> >> Gorry >> >> _______________________________________________ >> Taps mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/taps >> > _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
