hi, Aaron, all, was just in the middle of trying to catch back up with this thread, thanks for giving me a point to hang this off of... :)
Speaking, as Spencer said, for myself (thanks, Spencer!)... On 21 Aug 2014, at 16:29, Aaron Falk <aaron.f...@gmail.com> wrote: > > On Aug 20, 2014, at 6:00 PM, Michael Welzl <mich...@ifi.uio.no> wrote: > > >> >> >>> In the third doc I tried to be a little more concrete about what a “support >>> mechanism” is: >>> >>>> 3) Specify experimental support mechanisms to provide the Transport >>>> Services identified in work item 2. This document will explain how to >>>> select and engage an appropriate protocol and how to discover which >>>> protocols are available for a given connection. Further, it will provide a >>>> basis for incremental deployment. The associated milestone will be >>>> scheduled and work on this document will begin when the TAPS Transport >>>> Services have been specified. >>> >>> Trying to piece an alternate phrasing from the thread I get: >>> >>>>> 3) Submit to the IESG an Experimental document exploring abstract >>>>> interfaces to Transport Services and defining an experiment to evaluate >>>>> such interfaces for incremental deployability. The associated milestone >>>>> will be scheduled and work on this document will begin when the TAPS >>>>> Transport Services have been specified. >>> >>> This seems less concrete to me. I like “select and engage protocols” but >>> I’d like to hear more input from the group. >> >> What we did mean when we wrote this was "Happy Eyeballs ++". The Happy >> Eyeballs folks are on the list and have stated interest in continuing it >> here; there were ideas (all in the list archives..) on making it more >> scalable by using it later, i.e. no need to send out so much SYN-style >> traffic so fast; caching information; first asking the other side what >> protocols it supports to only test those that really must be tested. How to >> state this more clearly? Not sure. I think we were all quite happy with the >> "select and engage an appropriate protocol" sentence. > > Ah! I thought there was some objection to ‘select and engage’. So, is the > version from the last charter rev acceptable? > > 3) Specify experimental support mechanisms to provide the Transport Services > identified in work item 2. This document will explain how to select and > engage an appropriate protocol and how to discover which protocols are > available for a given connection. Further, it will provide a basis for > incremental deployment. The associated milestone will be scheduled and work > on this document will begin when the TAPS Transport Services have been > specified. This works for me, and it seems to me like that's where we've converged (less the final sentence). > Addressing the matter of whether to include a scheduled milestone for the > third document or not, let me make a suggestion. I acknowledge and respect > that there are several folks in the group invested in seeing work take place > on the ‘engage & select’ mechanisms and I believe it is in the IETF’s > interests in seeing that work mature. (Indeed, I hope there are teams off > busily working on implementations now.) Agreed... > However, as I’ve already made clear, the ‘distraction’ risk to the working > group progress of a tantalizing research area is significant. I think there's two points of risk here. One is distraction. On that point I'll admit that half the reason I reversed my position on this point during discussions in Toronto is that I became convinced that the risk of distraction itself is actually lower than the risk of breaking this whole process on arguments over distraction, so let's stick a milestone on the charter and rely on ourselves to keep things on track. (The other point of risk is what makes this engineering-research: the approach might simply not provide much return, because the set of transports that can provide a given interface to are too limited, or because the diversity of path brokenness on the Internet is too narrow. I hope I'm being pessimistic when I say this, but hedging this bet is one of the reasons the IAB Stack Evolution program is exploring other divergent-but-related solutions to the problem, simultaneous with TAPS. Let's build the thing and find out, though. No rule I can find says we only get to try to solve the problem once. :) ) > I would propose adding the milestone for the third doc with some chair > ground rules: > 1. no agenda time will be allocated to that topic until the first two docs > are mostly complete and stable (in the chair’s opinion) I'd say "on track" as opposed to "mostly complete"... For the first document, especially, there will probably be significant editing work (compiling subparts of the document from multiple contributors into a coherent whole -- I've already volunteered to help out here). So this document may be "ready" as far as its feed-in to the happy-transports stuff well before it's complete. The second document, probably less so. > 2. mailing list discussion of such topics during that period may be > discouraged if it appears it is slowing progress on the docs 1 and 2. I'm personally less comfortable with this restriction, mainly because it feels kind of punitive (of course, I'd say that the list should discuss anything it wants, except how bad the cookies at the snack breaks are). Isn't it sufficient simply to gate the *submission* of the third milestone to the IESG on the *publication* of the first two? Cheers, Brian > Spencer would need to approve this and I would want the group to back me up > if (when) the time comes that some, er, discipline needs to be applied. > > Thoughts? > > —aaron > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
