This is still a problem. Please turn off whatever logging or debugging is
causing the servers to drop connections, and refuse to accept reconnects
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
David B. Nelson wrote:
This is still a problem. Please turn off whatever logging or debugging is
causing the servers to drop connections, and refuse to accept reconnects
It's not that it refuses to accept your connection, it's that it has
nothing to serve. one-through three stayed up through
On 2007-12-02 10:38 Bob Hinden said the following:
...
Based on the past record, we're talking about something that
happens 0.58% of the time, or less.
Of course, predicting the future from the past is iffy; there have
been 10 appeals in 2006 and only one (not document related) in
hmmm...
Henrik Levkowetz wrote:
On 2007-12-02 10:38 Bob Hinden said the following:
...
Based on the past record, we're talking about something that
happens 0.58% of the time, or less.
Of course, predicting the future from the past is iffy; there have
been 10 appeals in 2006 and only
Problem statement: IP source addresses can be spoofed. Packet delivery is based
only on destination addresses, to the spoofed traffic arrives, and hurts
(attacks/threatens) the destination. It'd be nice to stop the spoofing, and
existing solutions aren't sufficient.
There are product
Sorry; that got garbled by funny characters that came from copy/paste. Here it
is again:
Problem statement: IP source addresses can be spoofed. Packet delivery is based
only on destination addresses, to the spoofed traffic arrives, and hurts
(attacks/threatens) the destination. It'd be
+1
From: Henrik Levkowetz [EMAIL PROTECTED]
Date: Wed, 05 Dec 2007 13:37:05 -0800
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], ietf ietf@ietf.org, iesg [EMAIL PROTECTED]
Subject: Re: Should the RFC Editor publish an RFC in less than 2 months?
On 2007-12-02 10:38 Bob Hinden said the
Stephen and Martin,
# sorry for twice posting.
Thanks for your quick comments.
- Trust Anchor definition:
I agree your comments. I think the term trust anchor CA is more
appropriate.
- MUST NOT and MUST for trust anchor:
I understand IETF statement, so I am going to replace MUST to
strongly
The IESG has approved the following document:
- 'Mobility Header Home Agent Switch Message '
draft-ietf-mip6-ha-switch-06.txt as a Proposed Standard
This document is the product of the Mobility for IPv6 Working Group.
The IESG contact persons are Jari Arkko and Mark Townsley.
A URL of this
The IESG has approved the following documents:
- 'Host Identity Protocol '
draft-ietf-hip-base-10.txt as an Experimental RFC
- 'Using ESP transport format with HIP '
draft-ietf-hip-esp-06.txt as an Experimental RFC
- 'Host Identity Protocol (HIP) Registration Extension '
10 matches
Mail list logo
