On 20. aug. 2014, at 16:54, Aaron Falk <[email protected]> wrote:
> We have a problem that folks who have not been part of the discussion from > the beginning (like myself) need additional clarity when talking about > “support mechanisms”. I’ve tried to add some in the descriptions of docs 2 > and 3 but apparently it needs refinement. The current charter says: > >> 2) Note that not all capabilities of IETF Transport protocols need to be >> exposed as Transport Services. This document will recommend the minimal set >> of Transport Services for inclusion in the abstract API. The resulting >> document will also provide guidance on making a choice among available >> mechanisms and protocols to obtain a certain Transport Service. > > Some folks on the list have proposed the following alternative: > >>> 2) Define the minimal set of Transport Services that must be provided by >>> mechanisms such as those to be specified in work item 3. The resulting >>> document will give guidance on choosing from available mechanisms and >>> protocols to provide a given Transport Service. Note that not all the >>> capabilities of IETF Transport protocols need to be exposed as Transport >>> Services. > > The problem here is that we haven’t described what work item 3 is. I’d > prefer a statement that stands on its own. If you don’t like my text above, > please propose something you like better. Work item 3 is just the third item in the list, where the text you cite above is the 2nd item. If that isn't clear enough, we could replace the sentence above them: The Working Group will: with: The Working Group will consider the following three work items: In my opinion, the clearest version is in the charter that went to IETF open review: *** - Specify the subset of those Transport Services, as identified in item 1, that end systems supporting TAPS will provide, and give guidance on choosing among available mechanisms and protocols. *** which you changed into the "work item 3" text on 26 July, i.e. during IETF open review, and documented in the diff file: "charter-diff-20140722e-20140726.pdf" that you sent to the list, and justified with: "I've been working on a few changes that I think clarify the charter, particularly the document goals. Since I wasn't part of the initial discussions I may have misunderstood where there is agreement. For example, the role of the second document seems to be really about getting consensus on some requirements for the third." I couldn't see any other input leading to this change. My suggestion would be to undo it. > 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. Cheers, Michael
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
