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