On 19. aug. 2014, at 12:07, Brian Trammell wrote:
>
> On 19 Aug 2014, at 11:41, Michael Welzl <[email protected]> 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).
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.
>> 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.
> 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.
I tried to explain what was meant with the original text but haven't made a
text proposal. If we must change the text then I'd welcome proposals from
others. But I seriously wonder if we *really* have to, and *really* should, at
this point: with every change we insert, one person that liked things as they
were during IESG review or IETF review might then not like the text anymore. I
guess we should do only very minor changes at this late stage, and I don't
actually think what we're now discussing is so minor.
Cheers,
Michael
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
