Hi Michael, for me, when I was reading the following, that was when I found it quite arbitrary again:
"In the list resulting from the second pass, some services are missing because they are implicit in some protocols, and they only become explicit when we consider the superset of all services offered by all protocols. „ So how do we know that we actually caught everything? Further see below. > Am 27.10.2015 um 15:27 schrieb Michael Welzl <[email protected]>: > > >> On 27. okt. 2015, at 15.00, Mirja Kühlewind >> <[email protected]> wrote: >> >> Hi all, >> >> I didn’t say anything so far because I don’t mind to have a second protocol >> here, but I personally don’t see this doc as really needed. Effectively we >> will have two docs that have the same results (a list of features) at the >> end. > > I think draft-welzl-taps-transports highlights how many services (or > transport features or whatever we want to call them) are lost when we just > compile a list as in draft-ietf-taps-transports. > To give a few examples: SCTP: "ordered and unordered delivery within a > stream” does not make it clear that you can in fact specify per-message > whether ordering matters or not. > In TCP, during the lifetime of a connection, you can change the DSCP value. > In TCP, you can open a connection to listen at one local interface or any; in > SCTP, you can specify a list of local interfaces > > We can debate whether these things are unnecessary details, but they are > things that appear in draft-welzl-taps-transports as a result of the > systematic approach I’ve taken. > For me that would be good feedback for taps-transport, to include these things. We have for each protocol a section on interface(s). We could even include more background text there if needed. However, for the things you’ve mentioned that’s for me rather a question on the level of detail of certain features. We’ve already discussed that we might need something like ‚aspects‘ for each feature. I believe we decided to not provide more details in this doc because we wanted to move on. However, I also believe that people in this group understand well that in some cases we’ll need more detailed information on the feature. And for me even if we submit and publish the taps-transport as it is, this is not written in stone and we can still say later on, that we rename a feature or split it up or whatever. For me that would even be part of the second doc in the charter. Again, I’m okay to have two docs here. I don’t think a second doc is absolutely necessary. An alternative would be to merge both docs… just as a side note. But I’m okay with both, two or one docs. > >> I personally find the approach taken in the new doc even more arbitrary and >> reading this discussion of what should be in and out just underlines this >> point. > > Even more arbitrary => could you please explain? > I think the discussion of what should be in and out has absolutely nothing to > do with the arbitrariness of the approach taken in the doc. See above. For me the only question is, how can we make sure we cover the right things and don’t forget important stuff. And in both cases the answer is we can’t. For me analyzing (only) the interfaces, is the more arbitrary approach because the current interfaces are already arbitrary to some extend and that’s exactly what we want to change. But that’s my personal view and there might not be an objective conclusion here. > > >> From my point of view the taps-transports is ready now. Btw. we did not >> leave out (hopefully) any features of RTP, we just decided to keep the >> description very short and only focus in the description on those parts that >> are actually transport related. >> >> I agree that the taps-transport doc is quite long, but for the wg I don’t >> the the purpose of this doc in having it but in getting it. I mean the >> process we had so far to get this doc in the right shape was very helpful >> and I believe we are ready to move on. The only think that is interesting >> now for the wg is the final list of feature, which is there and ready to >> use. >> >> As a side note, I also believe that other people might be interesting in >> reading the doc for other reasons than participating in taps because it’s >> actually a quite nice overview doc now. > > I agree that it’s a nice document and ready. As for “The only thing > interesting for the wg is he final list of features, which is there and ready > to use”, see the discussion above: the draft-ietf-taps-transports is a nice > and useful survey, but I do not think it is a good basis for an implementable > TAPS system, which we eventually want (doc 3). I don’t have the feeling that the new doc is much better. Important is that the wg knows that these features are not written in stone and we still have to think about the right choices here for any future work. I believe that’s true for both docs. Mirja > > Cheers, > Michael > > > >> >> That’s just my 2c. I don’t want to hold the wg from any further steps >> regarding draft-well-taps-transports; I just had the feeling I should also >> express a different opinion here. >> >> Mirja >> >> >>> Am 27.10.2015 um 14:47 schrieb Michael Welzl <[email protected]>: >>> >>> >>>> On 26. okt. 2015, at 17.35, Aaron Falk <[email protected]> wrote: >>>> >>>> On Mon, Oct 26, 2015 at 9:46 AM, Michael Welzl <[email protected]> wrote: >>>> >>>> Working towards a realistic end-goal of a deployable system. >>>> >>>> So we’re i) describing services; ii) narrowing them down somehow; iii) >>>> describing how to build this thing. >>>> My concern is with iii) being something feasible and useful, not an >>>> obscure sci-fi document. >>>> >>>> Uh, yeah. That's our charter. Narrowing down is in doc 2. Are you >>>> making the case we should do it in doc 1? >>> >>> Well, just because we narrow down in doc 2 doesn’t mean that doc 1 has to >>> contain everything under the sun as a starting point. Consider the >>> discussion around RTP in draft-ietf-taps-transports - I think the consensus >>> was to have only very short text on RTP in there, not a list of all the >>> protocol features. The starting point for draft-welzl-taps-transports >>> should probably be limited in a similar way, but I’d suggest limiting it >>> more than draft-ietf-taps-transports - partially because >>> draft-ietf-taps-transports can already show that certain protocols are not >>> adding new transport features to the mix that don’t yet exist. >>> >>> Of course, the main reason behind my argument is to keep >>> draft-welzl-taps-transports within a reasonable length. Look at its length >>> now, with only two protocols! I think the length is inevitable, but if we >>> have good reasons not to cover certain protocols, I think we should keep >>> them out. At least it’s a valuable discussion to have! >>> >>> >>>> Say we include DCCP. It’ll add some services that aren’t in the other >>>> protocols listed so far in this mail - e.g. drop notification (see section >>>> 3.6.3 in draft-ietf-taps-transports). Say, in step ii), we find no good >>>> arguments to remove drop notification. Then, in step iii), we’ll have to >>>> say how a TAPS system can support drop notification. So, to build a >>>> working TAPS system, one has to either: >>>> - include DCCP in the code base >>>> - extend other protocols to provide this functionality >>>> >>>> None of these two options are very helpful if we want to TAPS to be real >>>> thing one day. >>>> >>>> a: TAPS is not chartered to do anything normative. Doc 3 is about >>>> experimenting. >>> >>> Sure! But it’s still about stuff that someone should be able to build - I >>> just don’t want doc 3 to become a sci-fi literature piece :-) >>> >>> >>>> b: You are having the discussion that we planned to have for Doc 2. Make >>>> your case to drop those protocols then. Or, if no one wants to write >>>> sections for the additional protocols for Doc 1a (an extended version of >>>> draft-welzl-taps-transports), then folks are voting with their feet on the >>>> utility of keeping them. >>> >>> See my arguments above; about getting sections done for >>> draft-welzl-taps-transports, I don’t worry too much: this is only the very >>> first version, we haven’t asked anyone for inputs yet (and I can volunteer >>> to cover a few more protocols myself). >>> >>> >>>> c: One of the goals of TAPS is to enable deployment of transport protocols >>>> such as DCCP where networks permit it without forcing application (or >>>> library) authors to handle probe and fallback. If we don't include >>>> protocols that aren't seeing deployment, what is the value of this >>>> activity? >>> >>> This is a very good point. I’m not sure - do we really need to cover >>> absolutely all protocols that are in draft-ietf-transports in >>> draft-welzl-taps-transports, then? I am concerned about the >>> implementability of the final beast… >>> >>> Cheers, >>> Michael >>> >>> _______________________________________________ >>> Taps mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/taps >> _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
