[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ECN and issue 58
Black_David@emc.com writes:
> > The issue 58 is marked closed, but the section 2.24 is still there in
> > the draft-ietf-ipsec-ikev2-10.txt. I think we should remove the first
> > paragraph of the section, and simply say that we will do ECN as
> > specified in the RFC2401bis.
> I'm a little uncomfortable with the wholesale removal of design
> explanation/rationale that would result. As an alternative, would
> it be ok w/you if I whacked that first paragraph down to a fraction of
> its size (and took out some of the details) to focus on the important
> point (RFC2401bis encapsulation changes are "MUST use" in order to
> avoid breaking ECN)?
That is fine by me. I just think tghat the important stuff (i.e MUST
use) in the second paragraph is enough, and I don't know if we need
any of the first paragraph. That text should be in the rfc2401bis
document.
I think the text could be something like this:
----------------------------------------------------------------------
2.24 ECN (Explicit Congestion Notification)
The RFC 3168 includes two ECN operating modes. In order to avoid
multiple ECN operating modes and negotiation, tunnel decapsulators
for tunnel-mode Security Associations (SAs) created by IKEv2 MUST
implement the full-functionality option processing specified in
[RFC3168] and [RFC2401bis] to prevent discarding of ECN congestion
indications.
--
kivinen@ssh.fi
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/