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.
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.
—aaron
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
