Hi Michael, > Am 18.06.2015 um 15:43 schrieb Michael Welzl <[email protected]>: > > >> On 18 Jun 2015, at 10:48, Mirja Kühlewind <[email protected]> >> 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).
Okay, but then I don’t really understand your approach fully. Yes we should document and look at what’s already specified in RFC, however isn’t the goal of taps to actually figure out how to change/extend/improve these APIs? How can we figure out what’s missing/wrong if we only look at what’s already there? Mirja > > >> 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 <[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. > > 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 [email protected] https://www.ietf.org/mailman/listinfo/taps
