> On 15 Jul 2015, at 11:03, Karen Elisabeth Egede Nielsen > <karen.niel...@tieto.com> wrote: > > HI Mirja, All > > Sorry for jumping late into this discussion. > >> -----Original Message----- >> From: Taps [mailto:taps-boun...@ietf.org] On Behalf Of Mirja Kühlewind >> Sent: Thursday, June 18, 2015 10:48 AM >> To: Joe Touch >> Cc: Brian Trammell; Michael Welzl; taps@ietf.org >> Subject: Re: [Taps] TCP components >> >> 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. > > [Karen ] > > I really do not think that it makes much sense to look into outdated and > deprecated APIs > as specified in RFC793 and RFC4960 when we have better material available. > For SCTP here specifically RFC6458. > Personally I cannot support this approach. I am not saying that we need very > detailed APIs and therefore do not want RFC793 or RFC4960, > but I want that what we do is based on the right specs (or the right defacto > implementations) not on known-to-be outdated ones.
I have been pointing at RFC6458 but was recently told (and I should have just read the thing instead of being told, sorry :-( ) that this RFC does not specify how SCTP's functions are supposed to be exposed to applications using them, but describes one example implementation (in great detail) instead. So, to identify the core functions of the protocol, RFC 4960 is probably a more appropriate source. > I understand that it is difficult to find out exactly what is the fundament > of TAPS - sometimes it is said that > it is the existing IETF specifications - which means for example that > SCTP-CMT and QUIC is outside of the scope. > Then in other Taps communications - e.g. TCP components - it is said that > one cannot fix the congestion control aspects of TCP as there I not > one CC for TCP - and "one do not know what people implements". I am not sure > exactly what Taps should to do when > the defacto standards (e.g. TCP) have superseded the actual standard. I > think that it shall be on a best judgment basis and when there _are_ specs > we should go with the most recent and sane ones and not with the outdated > ones. One of the very first versions of our charter started the work off with a document that would lay out rules for us, as a basis to make such decisions. I venture to say that I was right to put this document there, and whoever recommended that I should remove it was wrong :-) because such a document would now be good to have, and I think it's easier to first try to agree on detailed rules (a more fine-grain charter, if you will - which protocols are in scope, how do we decide what a "service" is, etc.) than trying to immediately agree on the actual items themselves (SCTP-CMT: include it or not? Is the Nagle algorithm a service or not? etc.) Cheers, Michael _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
