> On 15 Jul 2015, at 12:40, Karen Elisabeth Egede Nielsen > <[email protected]> wrote: > > Hi Michael, All > >> >> 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. >> > [Karen ] I both agree and disagree with this statement. My view on this is: > > If looking for an abstract interface I agree that many "implementation" > details of RFC6458 are unnecessary. > However a significant number of abstract functions are not described in > RFC4960 and for control of/API for those > one need to consult either RFC6458 - or for some of the functions - the api > section of the RFCs defining these abstract functions. > > I would not know why one should consider only the "core" services of SCTP > defined by RFC4960 > as some significant protocol features are only defined by auxiliary RFCs. > Further there are "core" features defined in RFC4960 for which - used (!) - > control functions are only exposed in RFC6458.
Okay, sigh :( not easy, is it? > I don't like the API parts of RFC793 as it does not so well represent the > API of the defacto TCP implementations - not the (very few) I know anyway. > For example both the sender side and the receiver side handling of PUSH > flag, which we seem to speak much about here, is not an example of a feature > where the RFC793 description well represent the implementations. > Also it obviously cannot well represent newer features, like e.g. control of > ECN. > Then, right, ECN may not make it as something we want to expose. Not sure. > > I think that RFC793 and RFC4960 may be good starting points, but saying that > one will not look beyond them is a misunderstanding. In my view. I understand >>> 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.) >> > [Karen ] Yes. But learning by doing has merits as well. Perhaps one now has > a more qualified view on what the "rules" should be. Agreed! Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
