On Aug 20, 2014, at 6:00 PM, Michael Welzl <[email protected]> wrote:
>
>
> 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.
So, I admit that my understanding has been evolving over the course of the
charter discussion and I’m perfectly willing to undo prior ‘improvements’ that
I’ve made. Anyone else want to weigh in?
>
>
>> 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.
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.)
However, as I’ve already made clear, the ‘distraction’ risk to the working
group progress of a tantalizing research area is significant. 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)
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.
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
[email protected]
https://www.ietf.org/mailman/listinfo/taps
