We seem to have two documents in a space where we started with one. These
are different, to me this is OK. Both seem close to charter milestone 1. I
 don't see much overlap between the contents of the descriptive language
and the API-focussed analysis, and any overlap could be eliminated.

To me, doc 1 (current chartered item) can evolve to provide background and
 missing documentation for anyone in the IETF, and should compare 
transports in a broad way and draw out the idea that they provide
services. This appears to be harder to get right than I for one had hoped,
and still has a wide scope. Not a bad thing. I suggest it will provide a
reference to stop us rat-holing when people ask what is "this" and explain
how all these transports stack-up against one another (good pun?). We can
(I suggest) finish this doc in this way.

I do like the idea of a second document focussed ONLY on the Transport API
 (I'd call this 1a). In this we can avoid this"discussion of what are
transports"  and move to  a  more focussed  process in doc 1b,  Most of
that troublesome descriptive  text can go into 1, and ensure we keep that
one readable to anyone in the  IETF.

Could  I suggest the two docs against the first milestone will help us
make  progress towards the next milestone faster. (Assuming we can keep
the two aligned, which seems quite doable). I can see also how the  docs
are useful to different people. I'd like to see both mature and provide
inputs to move forward.

Gorry


> Interesting and inline to getting transport API(s)
>
> Marie-José Montpetit
> [email protected]
> [email protected]
>
>> On Sep 21, 2015, at 04:44, Michael Welzl <[email protected]> wrote:
>>
>> Dear all,
>>
>> In my presentation in Prague, I proposed an approach to identify the
>> services that transport protocols provide. At the end of the ensuing
>> discussion, I said that I (with co-authors) would write a draft that
>> explains the proposal by applying the proposed method to TCP and SCTP.
>>
>> We just submitted this document - see below;  I hope that this will lead
>> to some discussion on the list...
>>
>> Cheers,
>> Michael
>>
>>
>>> Begin forwarded message:
>>>
>>> From: <[email protected]>
>>> Subject: New Version Notification for
>>> draft-welzl-taps-transports-00.txt
>>> Date: 21 Sep 2015 10:35:33 CEST
>>> To: Michael Welzl <[email protected]>, Michael Welzl
>>> <[email protected]>, Michael Tuexen <[email protected]>, Naeem
>>> Khademi <[email protected]>, Michael Tuexen <[email protected]>,
>>> Naeem Khademi <[email protected]>
>>> Resent-From: <[email protected]>
>>>
>>>
>>> A new version of I-D, draft-welzl-taps-transports-00.txt
>>> has been successfully submitted by Michael Welzl and posted to the
>>> IETF repository.
>>>
>>> Name:        draft-welzl-taps-transports
>>> Revision:    00
>>> Title:        An Approach to Identify Services Provided by IETF
>>> Transport Protocols and Congestion Control Mechanisms
>>> Document date:    2015-09-21
>>> Group:        Individual Submission
>>> Pages:        23
>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-welzl-taps-transports-00.txt
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-welzl-taps-transports/
>>> Htmlized:
>>> https://tools.ietf.org/html/draft-welzl-taps-transports-00
>>>
>>>
>>> Abstract:
>>>  This document describes a method to identify services in transport
>>>  protocols and congestion control mechanisms.  It shows the approach
>>>  using TCP and SCTP (base protocol) as examples.
>>>
>>>
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> The IETF Secretariat
>>
>> _______________________________________________
>> Taps mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/taps
>
> _______________________________________________
> Taps mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/taps
>

_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps

Reply via email to