HI,
Thanks a lot.
Please find inline below.
Nothing outstanding as far as I can tell :-)
BR, Karen
> -Original Message-
> From: Brian Trammell [mailto:i...@trammell.ch]
> Sent: 12. november 2015 15:47
> To: Karen Elisabeth Egede Nielsen <karen.niel...@tieto.com>
&
Yes we agree ! :-) .
Glad that ended here.
Thanks a lot for the patience.
BR, Karen
> -Original Message-
> From: Michael Welzl [mailto:mich...@ifi.uio.no]
> Sent: 4. november 2015 21:39
> To: Karen Elisabeth Egede Nielsen <karen.niel...@tieto.com>
> Cc: <go...@e
HI Joe,
Yes I agree. But still there are finer features and BCP for api
and protocol implementations that have appeared from the api's defined
outside of the IETF and for which one need to look outside of RFC docs.
Or for PUSH bit one can also look at RFC1122 which describes it as
optional.
BR,
HI,
Please accept the following comments.
Use them as/if you see fit.
(Given my wretched, non-twistable, arms you are allowed not to take them
too seriously)
Section 3.1.1:
6'th paragraph:
" In addition, a congestion control
mechanism may react to changes in delay as an early indication for
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.
Hi Michael,
[Karen ] TCP maps the received soft destination unreachable ICMPs to
ENETUNREACH or EHOSTUNREACH pending errors on socket.
OK. FreeBSD provides EHOSTUNREACH instead of ETIMEDOUT for TCP.
It doesn't support ENETUNREACH. I don't think we do this in SCTP...
[Karen ] Yes. We do this
Hi Joe,
-Original Message-
From: Joe Touch [mailto:to...@isi.edu]
Sent: Thursday, July 16, 2015 7:49 PM
To: Karen Elisabeth Egede Nielsen; taps@ietf.org
Cc: to...@isi.edu
Subject: Re: [Taps] I-D Action: draft-ietf-taps-transports-06.txt
Hi, Karen,
On 7/16/2015 12:27 AM, Karen Elisabeth
HI Michael,
Agreed, however the other ways that SCTP doesn't pass validated ICMPs
to the user seems like a mistake to me.
[Karen ] I agree and we have for our SW recently discussed as to
whether we should implement such notification following the UDP and
TCP semantics. But at present none
HI,
A few initial comments the definition of the transport service features as
they appear from section 3 (and TAPS1):
Unidirectional/bidirectional: I am not sure what this means exactly:
Does it refer to that data transfer is negotiated for both directions
perhaps ? But then it only applies to
HI Michael,
[Karen ] This might (the MAY) results in hard trouble if the
association is closed due to entering of dormant state.
That's why we believe that this MAY reaction should be coupled with
robust dormant state handling.
I think we have to distinguish two things here:
[Karen ] Yes, I
HI Michael,
-Original Message-
From: Michael Tuexen [mailto:michael.tue...@lurchi.franken.de]
Sent: Thursday, July 16, 2015 12:45 PM
To: Karen Elisabeth Egede Nielsen
Cc: Joe Touch; Pal Martinsen (palmarti); taps@ietf.org
Subject: Re: [Taps] TAPS Transports and ICMP
On 16 Jul 2015
HI,
-Original Message-
From: Michael Welzl [mailto:mich...@ifi.uio.no]
Sent: Thursday, July 16, 2015 1:23 PM
To: Karen Elisabeth Egede Nielsen
Cc: taps@ietf.org; Stein Gjessing
Subject: Re: [Taps] Comments on draft-gjessing-taps-minset-00.txt
Hi, thanks!
Below:
On 16 Jul 2015, at 11
Hi Michael, All
I have been pointing at RFC6458 but was recently told (and I should have
just
read the thing instead of being told, sorry :-() that this RFC does
not specify
how SCTP's functions are supposed to be exposed to applications using them,
but describes one example implementation
-Original Message-
From: Taps [mailto:taps-boun...@ietf.org] On Behalf Of Michael Tuexen
Sent: Thursday, June 04, 2015 9:20 PM
To: Joe Touch
Cc: Pal Martinsen (palmarti); taps@ietf.org
Subject: Re: [Taps] TAPS Transports and ICMP
On 04 Jun 2015, at 20:27, Joe Touch to...@isi.edu wrote:
Hi,
Please find a very few comments to the document. Nothing major. Please use
if you see fit and only then :-)
Section 1: End First Paragraph:
Here it is said that a transport service feature may be minimal latency.
Opposed to the other features listed here,
like e.g. in-order or reliable
Hi,
Please find a very few comments to the document. Nothing major. Please use
if you see fit and only then :-)
Section 1: End First Paragraph:
Here it is said that a transport service feature may be minimal latency.
Opposed to the other features listed here,
like e.g. in-order or reliable
HI,
As an example of presently relied on API richness, then the following
parameters of TCP/SCTP are parameters that today typically are tuned by
signaling applications on a per connection/association basis or an a per
signaling application basis. Here multiple signaling applications may share
17 matches
Mail list logo
