On 19/09/13 17:59, Hannes Tschofenig wrote:
I am personally not worried that the standardization work in the IETF
can be sabotaged by governments since our process is open, and
transparent to everyone who cares to see what is going on.
Isn't it the other way round? That exactly because IETF
On 06/09/13 14:07, Hannes Tschofenig wrote:
While we are able to fill gaps in security protocols fairly quickly we
don't always seem to make the right choices because the interests of
various participants are not necessarily aligned.
So, what if an NSA guys comes in and proposes backdoor to
On 21/08/13 19:00, Joe Touch wrote:
So what would you use for muxing, if TCPMUX is not a good idea?
You need to roll your own. The requirements of systems vary widely, as
do the costs/benefits of different approaches.
I listed a few before, but here's a more comprehensive list:
-
On 21/08/13 20:03, Bob Braden wrote:
Indeed, TCPMUX is quite historic... it represents a Road Not Taken. My
memory is a bit hazy after 30+ years,
but I think there was a serious discussion around 1979 of using strings
instead of contact port numbers
for opening TCP connections. Here is the hazy
On 20/08/13 17:01, Joe Touch wrote:
However, see my other message - it's hard to recommend an approach when
we don't understand the problem you're trying to solve.
The scenario is simple.
You want admin to open one port in the firewall when the project is
started. Going through the
On 21/08/13 17:12, Joe Touch wrote:
The real problem here IMO is how to distinguish between adding a
completely new application -- which should require approval process --
and adding a new component within an existing distributed application
-- which should be managed by devs themselves.
IMO
On 16/08/13 20:07, Joe Touch wrote:
On 8/15/2013 10:38 PM, Martin Sustrik wrote:
On 16/08/13 03:23, Wesley Eddy wrote:
There are semantics issues to; see draft-touch-tcp-portnames-00 for
information (this is being revised for resubmission shortly, FWIW).
I totally agree. In fact
On 15/08/13 22:18, Joe Touch wrote:
Does anyone have any idea how widely is TCPMUX (RFC 1078) protocol used?
Is it the case that there are inetd daemons in TCPMUX mode running
everywhere, or can it be rather considered a dead protocol?
Specifically, if I implement a new TCPMUX daemon how
On 16/08/13 03:23, Wesley Eddy wrote:
There are semantics issues to; see draft-touch-tcp-portnames-00 for
information (this is being revised for resubmission shortly, FWIW).
I totally agree. In fact, in the update to the TCP roadmap [1], we
added TCPMUX to the section on Historic and
On 10/08/13 21:29, Wesley Eddy wrote:
On 8/10/2013 1:43 AM, Martin Sustrik wrote:
Hi all,
Does anyone have any idea how widely is TCPMUX (RFC 1078) protocol used?
Is it the case that there are inetd daemons in TCPMUX mode running
everywhere, or can it be rather considered a dead protocol
Hi all,
Does anyone have any idea how widely is TCPMUX (RFC 1078) protocol used?
Is it the case that there are inetd daemons in TCPMUX mode running
everywhere, or can it be rather considered a dead protocol?
Specifically, if I implement a new TCPMUX daemon how likely I am to
clash with an
On 25/02/13 07:56, Arturo Servin wrote:
If it were to collaborate, an ietf application with open standards
should be the way forward.
Moreover, entities controlling these social platforms are, presumably,
also participating in IETF. So, using these tools would give one party
unfair
Hi all,
During yesterday's takedown of the Internet [1] it has become
painstakingly obvious that the ability to distinguish malicious packets
in a quick and efficient manner is one of the most pressing security
concerns of today.
Thus, RFC3514 (a.k.a. evil bit) [2] support was implemented
On 08/01/12 13:00, John Day wrote:
You are also correct that strictly speaking the words protocol and
algorithm are probably the same.
That is an interesting point.
What I encounter often is the belief that protocol is just description
of bytes on the wire. People often forget about the
On 01/09/2012 01:35 PM, John Day wrote:
At 23:38 +0100 2012/01/08, Martin Sustrik wrote:
On 08/01/12 13:00, John Day wrote:
You are also correct that strictly speaking the words protocol and
algorithm are probably the same.
That is an interesting point.
What I encounter often is the belief
On 10/24/2011 07:16 PM, SM wrote:
If you do not go to meetings, it's unlikely that you will be able to
follow the BoF you are interested in. There may be times when decisions
are taken during a meeting. It is not worth the nit-picking if the
outcome won't change.
As BoFs are held in early
On 08/30/2011 06:07 PM, Bill McQuillan wrote:
How about recommending SHOULD ... BECAUSE to encourage the author
to justify the SHOULD.
+1
Although saying something like this should do: If there's a SHOULD
clause in the document, the document MUST provide background and
rationale for making
On 04/29/2011 04:36 AM, John Levine wrote:
So my advice would be to back up and write down in one or two
sentences what problem this document is supposed to fix or at least
describe, and then see how much of the rest of it might be salvaged.
I was thinking of storing data in DNS and the
On 03/30/2011 01:20 PM, Dave CROCKER wrote:
In some cases, there is a surprising benefit:
It makes a clear distinction between what is internal to the protocol,
versus what is payload that is delivered to the consumer (next layer up
or receiving application.)
Sometimes, the way a protocol is
Arnt Gulbrandsen wrote:
Ted Faber writes:
If an application needs a heartbeat, it almost always needs to be an
application to application (layer 7 to layer 7) heartbeat.
...
My point is that if you need that layer 7 heartbeat, the layer 4 (TCP)
one doesn't help much. I can't think of an
Ted Faber wrote:
Perhaps. I find the end-to-end violation more compelling. YMMV.
Good luck in tcpm.
Thanks for the interesting disucssion!
Martin
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Arnt Gulbrandsen wrote:
IMO, a TCP keepalive API needs contain only three functions. Two to
answer the questions are any acks overdue, and if so, by how long? and
what are the current RTT and bandwidth estimates? and one to provoke
the peer into sending an ack.
I would say that RFC1122
Ted,
The obvious problem is that heartbeats can thus sit in transmit buffer
waiting to be delivered. They can even be retransmitted. Etc. In any
case the functionality they are supposed to provide is pretty heavily
distorted.
FWIW, I don't think it matters if the keepalives are stuck in a
Ted,
The obvious problem is that heartbeats can thus sit in transmit buffer
waiting to be delivered. They can even be retransmitted. Etc. In any
case the functionality they are supposed to provide is pretty heavily
distorted.
FWIW, I don't think it matters if the keepalives are stuck in a
Arnt Gulbrandsen wrote:
A lot of the application code I've seen could be described as
second-guess one or more TCP timers, add pepper and salt, serve as
desired. The second half of that is obviously not amenable to
standardisation. The TCP stack cannot take any action. But the first
part
Michael,
I believe that the common practice is to send two timestamped copies
of every packet which are routed over two distinct network paths, i.e.
not sharing circuits or routers, and then the receiver waits for both
copies to arrive. If the delay between the two identical packets is
too
Hi all,
I haven't been able to find it but maybe someone knows here: Have there
been a protocol defined for checking whether TCP peer is alive or not?
(I mean one that plays well with networks with various latencies and
throughputs and won't congest the network even if used on a wide scale.)
Rémi Denis-Courmont wrote:
On Friday 25 June 2010 20:46:45 ext Martin Sustrik, you wrote:
I haven't been able to find it but maybe someone knows here: Have there
been a protocol defined for checking whether TCP peer is alive or not?
(I mean one that plays well with networks with various
Bob Braden wrote:
I trust you are familiar with section 4.2.3.6 of RFC 1122.
Yes. I am aware of it.
I was just interested in whether the behaviour have been defined for
those who need early failure detection (systems with failover
capabilities) and are willing to pay for the additional
Rémi Denis-Courmont wrote:
What I had in mind whether there ever been an attempt to define dynamic
keepalive algorithm that adjusts keepalive intervals according to the
observed throughput and roundtrip latency figures (dynamic in the same
way as CC dynamically adjusts throughput).
Any ideas?
Hi Ted,
The mechanism's not in TCP because the definition of a failed peer is
application dependent. A chemical plant automation application probably
has different requirements about when to treat a peer as failed than an
application that updates cute cat pictures, or one that keeps internet
Hi,
Is there a standard way to publish a call for discussion memo?
Searching though RFCs is seems there exists such type of document. For
instance RFC 970 says:
The purpose of this RFC is to focus discussion on particular problems
in the ARPA-Internet and possible methods of solution. No
Arnt Gulbrandsen wrote:
On 04/18/2010 06:58 PM, Martin Sustrik wrote:
Is there a standard way to publish a call for discussion memo?
Yes, an internet-draft, perhaps containg prose such as this draft is
intended to initiate discussion. At this time, the author does not
intend it to reach RFC
Steven, Marshall,
So basically, you write an I-D, send it to RFC editor. It gets
published, people discuss it. Later on it expires and is removed.
Not quite -- the RFC editor gets involved only when the decision has
been made to publish it as an RFC.
You submit I-Ds via
34 matches
Mail list logo
