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) > 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.) 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? Cheers, Brian > >>> M18: Recharter or close. >> >> I recommend we keep this milestone as well. > > +1. That one wasn't ever debated I think. Fine. > > > Cheers, > Michael > > _______________________________________________ > 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
