Hi Joe, I believe the approach Michael is proposing is to look at existing APIs as a starting point; not only abstract APIs. The assumption is that someone who implemented/designed an API, thought that it would be worth to provide a configuration possibility to the higher layer. This assumption is more true for SCTP than for TCP because there are quite a few different TCP implementation that are grown over time. Quite often a new interface was only created because a new feature was added to TCP; and to be on the safe side we allow the user to turn it off again.
That’s the reason why I prefer the approach we are/I'm taking right now (analyzing components). I think we should still describe the abstract API of RFC793 (and we do) as well as the SCTP API of RFC4960 in this document, but I personally would not and will not spend too much time analyzing other API. However, everybody who has time and is interested in this can of course provide his/her outcome as input for this document and we will happily take it and compare it to what we have so far. Mirja > Am 17.06.2015 um 20:10 schrieb Joe Touch <[email protected]>: > > > > On 6/17/2015 1:44 AM, Michael Welzl wrote: >> I think that this discussion with Joe maybe suffered from focusing on >> TCP. > > To be fair, TCP has a simpler abstract API. > >> SCTP is perhaps a better starting point because it supports >> almost everything. > > IMO, that makes it very hard as a starting point, and I also think that > TCP's variant of an API description is much better as an example. > > E.g., Section 10 of RFC4960 claims it defines an abstract API > (ULP-to_SCTP), but it begins by describing a call to initialize a data > structure (INITIALIZE). That's decidedly NOT an abstract API; it's a > generic description of an implementation issue. > > IMO, if we don't understand the difference between the API in RFC793 vs. > that in RFC4960 (and why 793 is a better example), then this is going to > be a very bumpy road. > > Joe > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
