[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/