[Taps] Mirja Kühlewind's No Objection on draft-ietf-taps-minset-08: (with COMMENT)

Mirja Kühlewind has entered the following ballot position for draft-ietf-taps-minset-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer

Re: [Taps] Ben Campbell's No Objection on charter-ietf-taps-01-00: (with COMMENT)

Hi Ben, this change rather removed the restriction to not analyze features of security protocols (other than tcpinc); this is mainly the first sentence. As we see a closer integration of TLS with QUIC and we in general think that security features are important, it is actually an important

[Taps] Mirja Kühlewind's No Objection on draft-ietf-taps-transports-usage-udp-06: (with COMMENT)

Mirja Kühlewind has entered the following ballot position for draft-ietf-taps-transports-usage-udp-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however

[Taps] Mirja Kühlewind's No Objection on draft-ietf-taps-transports-usage-08: (with COMMENT)

Mirja Kühlewind has entered the following ballot position for draft-ietf-taps-transports-usage-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please

Re: [Taps] New Version Notification for draft-fairhurst-taps-transports-usage-udp-03.txt

Hi all, quick question: what’s the advantage of having this as a separate doc instead of merging it with draft-ietf-taps-transports-usage (which was the original plan to my understanding)? Mirja > Am 06.10.2016 um 21:57 schrieb Aaron Falk : > > IMO, this is obviously

Re: [Taps] Abstracting away multi-streaming usage of multiple paths

Sorry… s/multicast/multipath/ (stupid auto-correct) > Am 19.07.2016 um 18:05 schrieb Mirja Kühlewind > <mirja.kuehlew...@tik.ee.ethz.ch>: > > Hi, > > for multicast there is the simple example where one access network is more > expensive to use than the other (

Re: [Taps] Abstracting away multi-streaming usage of multiple paths

Hi, for multicast there is the simple example where one access network is more expensive to use than the other (in the sense where the user gets a bill at the end). In this case the user would potentially rather except a disconnect for a short time than sending data unnecessary over the

Re: [Taps] Abstracting away multi-streaming and usage of multiple paths

Hi Michael, hi all, I believe there is actually quite a bit of discussion currently in MPTCP about how important it probably is to have an interface to the application and get input about upper layer preferences. Maybe ask on the mptcp list for input? Mirja > Am 19.07.2016 um 09:49 schrieb

Re: [Taps] is draft-ietf-taps-transports-07 ready for wg last call

Hi Aaron, what I meant was that we are done with the actual work for this doc. However, there are few minor things on the todo list, as Brian said. Further we were hoping to get some feedback from the list for a new revision. Especially there was a question that Brian posted regarding the

Re: [Taps] implementors

Hi Aaron, we would be interested and able to support implementation efforts, however, it’s not clear to me now what exactly should be implemented. Mirja > Am 28.10.2015 um 15:12 schrieb Aaron Falk : > > TAPS was started based on the assumption that there are folks who

Re: [Taps] IETF planning

f all services offered by all protocols. „ So how do we know that we actually caught everything? Further see below. > Am 27.10.2015 um 15:27 schrieb Michael Welzl <mich...@ifi.uio.no>: > > >> On 27. okt. 2015, at 15.00, Mirja Kühlewind >> <mirja.kuehlew...@t

Re: [Taps] draft minutes -- please review

Works, thanks! Am 06.08.2015 um 17:45 schrieb Aaron Falk aaron.f...@gmail.com: Thanks, Mirja. I tried to clarify what’s there. Please take a look. —aaron On Aug 6, 2015, at 4:50 AM, Mirja Kühlewind mirja.kuehlew...@tik.ee.ethz.ch wrote: Hi Aaron, thanks for preparing this! I

Re: [Taps] TCP components

Hi Michael, Am 18.06.2015 um 15:43 schrieb Michael Welzl mich...@ifi.uio.no: On 18 Jun 2015, at 10:48, Mirja Kühlewind mirja.kuehlew...@tik.ee.ethz.ch wrote: Hi Joe, I believe the approach Michael is proposing is to look at existing APIs as a starting point; not only abstract APIs

Re: [Taps] TCP components

Hi Michael, see below. Am 17.06.2015 um 09:36 schrieb Michael Welzl mich...@ifi.uio.no: Hi, On 11 Jun 2015, at 13:52, Mirja Kühlewind mirja.kuehlew...@tik.ee.ethz.ch wrote: Hi all, we gave it a first try to rewrite the component section for TCP. The insight I took from

[Taps] TCP components

Hi all, we gave it a first try to rewrite the component section for TCP. The insight I took from the discussion on the list is that components probably are much more linked to the implementation (choices) a certain protocol made while features are probably more high-level having the question

Re: [Taps] A proposal to throw out RTP

Hi Joe, the document defines one more term: Transport Service Instance: an arrangement of transport protocols with a selected set of features and configuration parameters that implements a single transport service, e.g. a protocol stack (RTP over UDP). This is to describe

Re: [Taps] A proposal to throw out RTP

___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps -- -- Dipl.-Ing. Mirja Kühlewind Communication Systems Group Institute TIK, ETH Zürich Gloriastrasse 35, 8092 Zürich, Switzerland Room ETZ G93 phone: +41 44 63 26932

Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

Hi Joe, hi Michael, I completely welcome to add more text to the Interface description section (3.1.2). Currently this section is very short and says regarding the (higher layer) interface described in FRC793: A User/TCP Interface is defined in [RFC0793] providing six user commands: Open,

Re: [Taps] API richness

Hi Karen, instead of discussing what applications currently configure, I would rather like to know why they configure it; what the goal they try to reach and what’s the problem they try to handle with that. The reason why I’m saying this, is because the current configuration possibilities are

Re: [Taps] I-D Action: draft-ietf-taps-transports-04.txt

Hi Joe, I agree. This is a working document and we are still in the phase of collecting data while the next step is to discuss which things that are currently listed must/should be listed or not and also which of the things must/should be exposed to the app. However, I think we are on the

Re: [Taps] TAPS: Getting things named correctly... what is a transport service

Hi all, one more proposal that in not inline with the charter definition but therefore more similar to Gorry’s proposal. Basically we could even avoid to use the term ‚transport service‘ as a stand-alone term and always use ‚transport service something‘ instead to make the meaning more

Re: [Taps] Fwd: Call for Papers: IAB Workshop on Stack Evolution in a Middlebox Internet (SEMI)

Board, the Internet Society, and ETH Zürich. Mirja Kühlewind and Brian Trammell, General Chairs. ___ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps ___ Taps mailing list Taps

Re: [Taps] TAPS charter rev 20140826

://www.ietf.org/mailman/listinfo/taps -- -- Dipl.-Ing. Mirja Kühlewind Communication Systems Group Institute TIK, ETH Zürich Gloriastrasse 35, 8092 Zürich, Switzerland Room ETZ G93 phone: +41 44 63 26932 email: mirja.kuehlew...@tik.ee.ethz.ch