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 to
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 ch
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
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
I believe the idea was actually to have the policy after the socket intents
talk; maybe even after HE?
Mirja
> Am 06.07.2017 um 16:56 schrieb Aaron Falk :
>
> Updated. Still need a policy framing preso (#4) and timing.
>
> • Minimal Set of Transport Services for TAPS Systems, Naeem Khad
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 in scope for TAPS and a
Sorry… s/multicast/multipath/ (stupid auto-correct)
> Am 19.07.2016 um 18:05 schrieb Mirja Kühlewind
> :
>
> 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
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 expensi
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 Aa
Hi all,
this is the final version of the document. We only fixed a few minor nits and
reordered some of the subsections. We didn’t do this before the wglc has
reordering screws up the diff. I guess we are done. Thanks to everybody who
contributed and provided feedback!
Mirja
> Am 04.03.2016
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 want to
> implement the
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 featu
Hi Micheal,
this is only a personal opinion and I do not object to work on this doc.
Mija
> Am 28.10.2015 um 09:05 schrieb Michael Welzl :
>
> Hi Mirja,
>
> I’m not sure where this discussion is leading us: twice you just say you
> disagree without giving a reason; then you seem to get kind
Hi,
see inline.
> Am 27.10.2015 um 19:56 schrieb Michael Welzl :
>
>
>> 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 a
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 :
>
>
>> On 27. okt. 2015, at 15.00, Mirja Kühlewind
>> wrote:
>>
>> Hi all,
>>
>> I
Hi all,
I didn’t say anything so far because I don’t mind to have a second protocol
here, but I personally don’t see this doc as really needed. Effectively we will
have two docs that have the same results (a list of features) at the end. I
personally find the approach taken in the new doc even
Works, thanks!
> Am 06.08.2015 um 17:45 schrieb Aaron Falk :
>
> 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
>> wrote:
>>
>> Hi Aaron,
>>
>>
Hi Aaron,
thanks for preparing this! I think the conclusion at the very end about
congestion control was that we want to mention that there are different kinds
of congestion control (as it is already done in the doc) but there is no need
to e.g. describe LEDBAT in detail. Could you please add a
Hi Michael,
>
>> Again, if you have time to work on an alternative approach, please go ahead
>> and provide input or even submit an own draft and I’m/we’re really open to
>> discuss this and see what makes more sense.
>
> Ok well, I agree that what I request is easier said than done :-(
Hi Michael,
> *My* goal is, and has always been, to provide a simpler, general API that is
> protocol independent. Note that this is not only for simplicity for ease of
> use BUT also for the sake of being able to automatize. After all the major
> goal is to remove the strict binding between ap
Hi Michael,
> Am 18.06.2015 um 15:43 schrieb Michael Welzl :
>
>
>> On 18 Jun 2015, at 10:48, Mirja Kühlewind
>> wrote:
>>
>> Hi Joe,
>>
>> I believe the approach Michael is proposing is to look at existing APIs as a
>> starting point; no
Hi Joe,
I believe the approach Michael is proposing is to look at existing APIs as a
starting point; not only abstract APIs. The assumption is that someone who
implemented/designed an API, thought that it would be worth to provide a
configuration possibility to the higher layer. This assumption
Hi Michael,
see below.
> Am 17.06.2015 um 09:36 schrieb Michael Welzl :
>
> Hi,
>
>
>> On 11 Jun 2015, at 13:52, Mirja Kühlewind
>> wrote:
>>
>> Hi all,
>>
>> we gave it a first try to rewrite the component section for TCP. The insight
Hi Mohamed,
see below.
- Limited control over segment transmission scheduling (Nagle's
algorithm):
This allows for delay minimization in interactive applications.
GF: Not quite - To me, it prevents increased delay from the TCP protocol.
It doesn't really control anything to reduce d
Hi Gorry,
see below.
- Limited control over segment transmission scheduling (Nagle's
algorithm):
This allows for delay minimization in interactive applications.
GF: Not quite - To me, it prevents increased delay from the TCP protocol.
It doesn't really control anything to reduce delay
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 i
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 also
Hi Michael,
see below.
On 05.06.2015 11:05, Michael Welzl wrote:
On 5. jun. 2015, at 10.12, Mirja Kühlewind
wrote:
Okay, just to quickly clarify. In the charter only the word service is used. We
defined later on the words component and feature which are currently not
reflected in the
Okay, just to quickly clarify. In the charter only the word service is used. We
defined later on the words component and feature which are currently not
reflected in the charter. The part I've cited below, I think, it should say
components. However, it does not really matter because we will in t
.
-- Christian Huitema
___
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
--
--
Dipl.-Ing. Mirja Kühlewind
Communication Systems Group
Hi Joe
>
> My concern is that there is no clear relation between 3.1.2 and 3.1.3.
Yes, that’s actually true. Initially there was no section 3.1.2 as this doc is
not on interfaces. However it seems to be incomplete without mentioning
interfaces at all. If we keep this section, you are right, the
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, S
Hi Oliver,
I mostly agree with your understand, only minor points below.
> Am 29.05.2015 um 10:05 schrieb Olivier Mehani :
>
> Hi all,
>
> On Thu, May 28, 2015 at 09:33:43PM +0200, Michael Welzl wrote:
here is where the confusion comes from: this doc is not about APIs,
it’s about tran
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 o
Am 28.05.2015 um 19:35 schrieb Joe Touch :
>
>
>
> On 5/28/2015 1:49 AM, Mirja Kühlewind wrote:
>> Hi Joe,
>>
>> see below...
>>
>>
>>> Am 27.05.2015 um 19:20 schrieb Joe Touch :
>>>
>>>
>>> On 5/27/2015 6:02 AM, Mirja Kü
Hi Joe,
see below...
> Am 27.05.2015 um 19:20 schrieb Joe Touch :
>
>
> On 5/27/2015 6:02 AM, Mirja Kühlewind wrote:
>> 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 discus
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 writ
Hi Salvatore,
not sure Brian ever answered to this mail. We already have Dragana Damjanovic
who volunteered to help with Websocket. However, as you just might have seen on
the slides we’ve put your name down for Websockets as well. Please coordinate
with Dragana.
Thanks!
Mirja
> Am 21.03.20
Hi Karen,
section 3 should describe what currently is standardized. Am I right that there
is no RFC on CMT SCTP (yet)… and that this was/is the reason that there was
some discussion that this is out of scope? If so, what the status of CMT SCTP?
Will there be potentially be an RFC anytime soon?
Hi Olivier,
the quick answer for now is that section 3 should describe everything that is
current in the protocol, while section 4 will later on discuss what should be
there (and what should be exposed to the higher layer).
You can go for section 3.8 (incl. authentication); it’s not taken yet.
Hi Olivier,
see below
On 06.03.2015 00:33, Olivier Mehani wrote:
Hi Mirja, all,
On Thu, Mar 05, 2015 at 12:23:21PM +0100, Mirja Kühlewind wrote:
Sections 3.2 and 3.3 in draft-03 remind us that there are
commonalities between MPTCP (RFC6897) and SCTP APIs (RFC6458). They
could be further
_
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, Switzer
Hi Joe.
see below...
On 30.01.2015 20:23, Joe Touch wrote:
Hi, Mirja,
On 1/30/2015 3:46 AM, Mirja Kühlewind wrote:
Hi Joe,
I reply to the TCP part in this mail... see below.
On 19.12.2014 00:39, Joe Touch wrote:
Some feedback below. Although I focus on some TCP and UDP specifics,
some
r each of the other sections, but this is still open to discussion. The
document also includes at least a little text on most of the transport
protocols identified in the -00 revision. Welcome also to Mirja Kühlewind,
added as an additional editor.
If there are any additional transport
Hi,
just been quickly checking the transport service definition in RFC 2126. From my
understanding this is in line with the proposed definition of a transport
service (composition) (but not inline with the definition as given in the
charter). I still believe that we cannot only refer to RFC212
isting protocols. The emphasis of
this work is not security.
Kevin Fall: Are API changes in scope? (e.g. changing sockets to allow
data-with-SYN, out-of-order delivery)
Aaron Falk: Yes
———
13:15 Terminology Review (Kühlewind) – 30 min
<http://www.ietf.org/proc
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
‘ instead to make the meaning more explicit (see bel
accepted at:
https://www.easychair.org/conferences/?conf=semi2015
Submission Deadline: 31 October 2014
Notification Deadline: 17 November 2014
Workshop Dates: 26-27 January 2015
Sponsored by the Internet Architecture Board, the Internet Society, and
ETH Zürich. Mirja Kühlewind and Brian
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
50 matches
Mail list logo
