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

[Michael Tuexen <[e-mail]>]

> On 03 Nov 2015, at 14:33, [e-mail] 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.

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