In transit, please excuse the brevity. Broadly I appreciate the effort to do the decomposition in a less arbitrary way. I'm not convinced it's actually less arbitrary, but this is largely irrelevant: it's a *different* way to do the decomposition, so points of agreement (of which, at least on TCP and SCTP, there are many) reinforce confidence that we're doing this right. I tend to agree with Gorry's suggestion on the way forward.
Cheers, Brian Sent from my iPhone > On 05 Oct 2015, at 11:42, Aaron Falk <aaron.f...@gmail.com> wrote: > > Have others read this draft yet? It is clearly aimed at addressing charter > deliverable #1. Do other folks have an opinion on how well it helps the > group achieve the goals in our charter? Should we use this document in some > way? I'm looking for more input from the working group on how we should > proceed. > > My opinion: I am very mindful (& appreciative) of the significant effort by > Mirja and Brian and the other contributors on draft-ietf-taps-transports. > The discussion around this doc has been very useful for clarifying (to me) > how difficult it can be to pull useful common abstractions out of the 30+ > years of transport technologies. Having been down this path for over a year, > I appreciate the fairly narrow approach draft-welzl-taps-transports and think > it may be the best chance for TAPS to succeed. > > Please share your views. > > --aaron > > >> On Sat, Sep 26, 2015 at 10:50 AM, Michael Welzl <mich...@ifi.uio.no> wrote: >> +1 >> >> > On 26. sep. 2015, at 13.28, Marie-Jose Montpetit <ma...@mjmontpetit.com> >> > wrote: >> > >> > Makes sense. >> > >> >> On Sep 26, 2015, at 3:17 AM, go...@erg.abdn.ac.uk wrote: >> >> >> >> 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 >> >>> ma...@mjmontpetit.com >> >>> mari...@mit.edu >> >>> >> >>>> On Sep 21, 2015, at 04:44, Michael Welzl <mich...@ifi.uio.no> 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: <internet-dra...@ietf.org> >> >>>>> Subject: New Version Notification for >> >>>>> draft-welzl-taps-transports-00.txt >> >>>>> Date: 21 Sep 2015 10:35:33 CEST >> >>>>> To: Michael Welzl <mich...@ifi.uio.no>, Michael Welzl >> >>>>> <mich...@ifi.uio.no>, Michael Tuexen <tue...@fh-muenster.de>, Naeem >> >>>>> Khademi <nae...@ifi.uio.no>, Michael Tuexen <tue...@fh-muenster.de>, >> >>>>> Naeem Khademi <nae...@ifi.uio.no> >> >>>>> Resent-From: <mich...@ifi.uio.no> >> >>>>> >> >>>>> >> >>>>> 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 >> >>>> Taps@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/taps >> >>> >> >>> _______________________________________________ >> >>> Taps mailing list >> >>> Taps@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/taps >> >>> >> >> >> > >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps