On 19. aug. 2014, at 14:01, Brian Trammell wrote: > > On 19 Aug 2014, at 13:40, Michael Welzl <mich...@ifi.uio.no> wrote: > >> >> On 19. aug. 2014, at 12:07, Brian Trammell wrote: >> >>> >>> On 19 Aug 2014, at 11:41, Michael Welzl <mich...@ifi.uio.no> wrote: >>> >>>> Hi Brian, thanks getting into this discussion! >>>> >>>> In line below: >>>> >>>> On 19. aug. 2014, at 11:32, Brian Trammell wrote: >>> >>> <snipping away the vast majority of the charter we seem to agree on> >>> >>>>> Per the third point of the charter, I think we want to add the third >>>>> milestone back, but make clear that the effort is experimental; something >>>>> like: >>>>> >>>>> M18: Submit to the IESG an Experimental document exploring abstract >>>>> interfaces to Transport Services, and defining an experiment to evaluate >>>>> such interfaces for applicability to common application design patterns >>>>> and incremental deployability >>>> >>>> I think this is a significant change to the wording that we had during >>>> IETF open review, which was: >>>> >>>> M18: Submit specification of how the transport services can be provided to >>>> IESG. >>>> >>>> I'd be fine with the status of this document explicitly being >>>> Experimental, as it was before, see: >>>> https://sites.google.com/site/transportprotocolservices/charter-proposal/charter-before-london >>>> i.e. to change this back to: >>>> >>>> M18: Submit Experimental specification of how the transport services can >>>> be provided to IESG. >>>> >>>> ...but your wording seems to be an entirely different thing: exploring >>>> abstract interfaces? defining an experiment to evaluate them for >>>> applicability to app design patterns? This is really something else. Why >>>> do you propose such a change at this late stage? Who else wants that, and >>>> why? >>> >>> I think we need something a bit more specific than "submit specification of >>> how the transport services can be provided to the IESG" -- since (for my >>> part) I'm not really sure what that means. My wording is simply an attempt >>> to take the language from the third "working group will" point and turn it >>> into a milestone: >>> >>>> 3) Specify experimental support mechanisms to provide the Transport >>>> Services identified in work item 2. >>> >>> i.e. "Submit to the IESG an Experimental document exploring..." >>> >>>> This document will explain how to select and engage an appropriate >>>> protocol and how to discover which protocols are available for a given >>>> connection. >>> >>> "...abstract interfaces to Transport Services..." (since "how to select and >>> engage" seems to me to very much be an abstract interface, maybe I'm >>> reading it wrong) >> >> I'm pretty sure that the whole phrase was meant to mean some form of "Happy >> Eyeballs++ for transports". I think this is obvious for the second half >> ("discover which protocols are available..."), but end-to-end, more than >> that is required. If Happy Eyeballs gives me a TCP response before it gives >> me a protocol X response that I'm hoping for, do I wait or just use X later >> in case it arrives? And: do we need to tell the other end what we're doing? >> Find out what the other side is even capable of? (for some services we do, >> for some we don't). > > ACK. > >> We can now start wordsmithing to try to put this into clearer words, but I >> didn't think this is the right time to do that... we've been wordsmithing so >> much?! and I have trouble interpreting the phrase as an "abstract >> interface", frankly, but this may be just me who has looked at the text from >> one particular angle for so long. > > So to me the abstract interface is how the application specifies what things > should get happy eyeballs'd (since trying to figure out if we can get PR-SCTP > down the path is pointless if we don't want retransmission at all). I know we > don't belong to the the billion-knobs school of transport configuration here, > but the app needs to be able to specify what it expects. > > (Further down the program -- in the bit of the work we specifically agreed > not to do yet because views start diverging wildly -- there's the question of > how to broaden out the interface beyond establishment time.)
Well... the group started out wanting to do an API. After grinding by the IETF mill, this became the first two documents: lists of services. So we shouldn't go down that path again, I'm afraid (don't get me wrong, I'd like to see an API; we had it in there once, as another Informational RFC, but someone asked to have it removed; maybe this is one of the things we can consider defining when we recharter?). >>>> 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. >>> >>> "...defining an experiment to evaluate such interfaces for... incremental >>> deployability". (The bit about application design patterns is admittedly >>> something I added to point out it's not _just_ incremental deployability we >>> care about, but I would submit that if we're not building this in the hope >>> that it addresses common application design patterns, then we can all go >>> home.) >> >> We've been around the "common application application design patterns" >> block, see Martin Sustrik's presentation in London, the minutes, and >> extensive list discussion on that topic. This didn't culminate in charter >> text and I'd suggest to not insert such text now. > > ACK. Though we still need language that makes it clear that it's applications > that are expected to make use of the transport services we specify. Isn't that obvious? Who else would? >>> I'm of course open to better wording that captures point (3), this is just >>> a first suggestion. And we do want something very open... but I think >>> "Submit Experimental specification of how the transport services can be >>> provided to IESG" is a bit too open. >>> >>> Thoughts? >> >> Personally I think this is less open than the wording you suggested, but >> that's just me not understanding what you even mean with "abstract >> interface", and inserting something about application design patterns >> doesn't exactly make it clearer I think. > > Okay. I can't really understand how I would evaluate whether a given document > provides a "specification of how the transport services can be provided", but > as long as the WG and the chairs can, then that doesn't really matter. > > One English as well: "can be provided" really reads here as though it binds > to "to the IESG". We're not trying to provide transport services to the IESG. > :) So I'd say at minimum we need to make this point parallel to the others, > and point out the apps-are-our-users bit: > > M18: Submit to the IESG an Experimental document specifying methods for > providing the Transport Services identified by the WG to applications. > > How's that? Fine by me (and thanks for the fix). Cheers, Michael _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
