> On 18 Jun 2015, at 10:48, Mirja Kühlewind <mirja.kuehlew...@tik.ee.ethz.ch> > wrote: > > Hi Joe, > > I believe the approach Michael is proposing is to look at existing APIs as a > starting point; not only abstract APIs.
No, wrong. Only abstract ones from RFCs, I said this before. These things would typically have preceding IETF debate, whereas trying to cover implementations is a huge and probably meaningless endeavour (the bar may be high for adding function calls to an API on system X and low for an API on system Y). > 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. But you misunderstood me. I was talking about RFCs (btw 6458, not 4960), not implementations out there. More below, answering Joe (hm, that rhymes ;-) ) - > > Mirja > > >> Am 17.06.2015 um 20:10 schrieb Joe Touch <to...@isi.edu>: >> >> >> >> 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. How abstract it is in the RFC indeed isn't my main concern here: it's to start with the interface (however abstract it is) offered to applications as described in the RFCs, as this reflects what the designers (with some level of IETF consensus) thought should be exposed. Now, of course SCTP has more options and is more complex in its usage than TCP, but it covers a larger part of the space of services in protocols - so I thought it's a good starting point, as in: 80% done by looking at 1 protocol, check the others for the remaining 20%. Something like that. This is just me being pragmatic and trying to have a more systematic approach to developing a list of services. I agree with Brian that some level of arbitrariness will always be there, but we must try to minimize it I think. Cheers, Michael _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
