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

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