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? Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
