> On 22. okt. 2015, at 22.23, Brian Trammell <[email protected]> wrote: > > hi Michael, > >> On 22 Oct 2015, at 18:19, Michael Welzl <[email protected]> wrote: >> >> >>> On 22. okt. 2015, at 16.14, Aaron Falk <[email protected]> wrote: >>> >>> >>>> draft-welzl-taps-transports currently only covers TCP and SCTP. But then: >>>> how many other protocols? >>>> It seems people agree that the protocols covered in >>>> draft-welzl-taps-transports should be a subset of the protocols covered in >>>> draft-ietf-taps-transports. My question is, then: how to choose the subset? >>>> >>>> It seems obvious to include protocols that are seeing some deployment, >>>> i.e. of course UDP, maybe UDP-Lite (?), but also MPTCP… >>>> However: if that is the only decision ground, we probably wouldn’t include >>>> DCCP. Are we then making a significant mistake, missing a lesson to be >>>> learned? >>>> >>>> That, to me, is a discussion I’d like to have in Yokohama. >>> >>> +1, and FWIW that's exactly the same starting point I got to on my own. >>> >>> >>> Any volunteers to kick off the lead the discussion? >> >> Let me try to roll this some more on the list, because I gave it some >> thought: >> >> The goal is to have something buildable. So if we allow protocols that are >> hardly deployed into draft-welzl-taps-transports, then this gives us a list >> that may include services that one can never implement unless >> hardly-deployed protocol X is used, or other protocols are extended to all >> of a sudden provide this functionality. >> >> Thus, boring as it may seem, “widely deployed protocols” can be the only >> reasonable criterion to allow adding protocols in draft-welzl-taps-transports > > s/widely deployed/widely implemented/g, but yes.
Agreed > Another thought: draft-gjessing (as it currently is) looks at the minimal set > of services. If there are services we believe are useful to support that are > not presently widely implemented or deployed, we can certainly add them as > optional, no? The only services that could not be handled in such a way would > be those that have an impact on the API other than just adding knobs and > meters, no? Sorry, you lose me here - in particular I don’t get the part about “have an impact on the API…”. Could you maybe give a toy example? Cheers, Michael _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
