Re: [Taps] IETF planning

HI, Just a note. Not necessarily relevant for the overall argument however. > > > > So we’re i) describing services; ii) narrowing them down somehow; iii) > > describing how to build this thing. > > My concern is with iii) being something feasible and useful, not an > > obscure sci-fi document.

Re: [Taps] IETF planning

> On 27. okt. 2015, at 10.44, Karen Elisabeth Egede Nielsen > wrote: > > HI, > > Just a note. Not necessarily relevant for the overall argument however. > >>> >>> So we’re i) describing services; ii) narrowing them down somehow; iii) >>> describing how to build this

Re: [Taps] IETF planning

Hi Michael, for me, when I was reading the following, that was when I found it quite arbitrary again: "In the list resulting from the second pass, some services are missing because they are implicit in some protocols, and they only become explicit when we consider the superset of all

Re: [Taps] IETF planning

Hi, Sorry for the long silence. I have been on vacation with almost no internet connection. I will attend IETF 94, but I don´t feel ready to lead a discussion about charter item 2. However, I will take part in the discussion and gladly contribute to the draft we eventually have to make to

Re: [Taps] IETF planning

> On 27. okt. 2015, at 15.46, Mirja Kühlewind > wrote: > > Hi Michael, > > for me, when I was reading the following, that was when I found it quite > arbitrary again: > > "In the list resulting from the second pass, some services are missing > because they

Re: [Taps] IETF planning

> > How are you going to do this when you don’t know what applies to connection > opening, connection maintenance, data transfer? What kinds of error messages > are available? We need that of course but I don’t see now any list of what are the common features between all transports (to start

Re: [Taps] IETF planning

On Mon, Oct 26, 2015 at 5:54 AM, Gorry Fairhurst wrote: > On 22/10/2015 15:14, Aaron Falk wrote: > >> >> > draft-welzl-taps-transports currently only covers TCP and SCTP. But >> then: how many other protocols? >> > It seems people agree that the protocols covered in

Re: [Taps] IETF planning

> On 26. okt. 2015, at 14.17, Aaron Falk wrote: > > On Mon, Oct 26, 2015 at 5:54 AM, Gorry Fairhurst > wrote: > On 22/10/2015 15:14, Aaron Falk wrote: > > > draft-welzl-taps-transports currently only covers TCP and

Re: [Taps] IETF planning

On Mon, Oct 26, 2015 at 9:46 AM, Michael Welzl wrote: > > Working towards a realistic end-goal of a deployable system. > > So we’re i) describing services; ii) narrowing them down somehow; iii) > describing how to build this thing. > My concern is with iii) being something

Re: [Taps] IETF planning

> On 22. okt. 2015, at 22.23, Brian Trammell wrote: > > hi Michael, > >> On 22 Oct 2015, at 18:19, Michael Welzl wrote: >> >> >>> On 22. okt. 2015, at 16.14, Aaron Falk wrote: >>> >>> draft-welzl-taps-transports currently

Re: [Taps] IETF planning

> On 19. okt. 2015, at 20.44, Aaron Falk wrote: > > Hi Folks- > > So, we have these two docs and a rough agreement that they are complimentary. > Gorry suggests that they both progress as responsive to milestone 1: > >> I suggest the two docs against the first

Re: [Taps] IETF planning

> On 19. okt. 2015, at 20.44, Aaron Falk wrote: > > Hi Folks- > > So, we have these two docs and a rough agreement that they are complimentary. > Gorry suggests that they both progress as responsive to milestone 1: > >> I suggest the two docs against the first

Re: [Taps] IETF planning

hi Michael, > On 22 Oct 2015, at 18:19, Michael Welzl wrote: > > >> On 22. okt. 2015, at 16.14, Aaron Falk wrote: >> >> >> > draft-welzl-taps-transports currently only covers TCP and SCTP. But then: >> > how many other protocols? >> > It seems

Re: [Taps] IETF planning

> > > > draft-welzl-taps-transports currently only covers TCP and SCTP. But > then: how many other protocols? > > It seems people agree that the protocols covered in > draft-welzl-taps-transports should be a subset of the protocols covered in > draft-ietf-taps-transports. My question is, then: how