Steve,
The goal here is that any use of IKEv2 to negotiate a tunnel-mode SA (or UDP-encapsulated tunnel-mode SA for NAT traversal) carry an implied promise that ECN will be supported and handled correctly for that tunnel. This avoids any need for IKEv2 to negotiate/report/etc. ECN handling, in contrast to IKEv1 where a negotiable SA attribute and some other stuff was necessary to deal with the installed base (see Section 9.2 of RFC 3168 and its subsections for details).
I like this sort of simple solution, and it fits with IKEv2's goal of simplifying negotiation, but for this solution to work, it has to be required of implementations before any IKEv2 installed base has a chance to develop, otherwise we wind up back in the IKEv1 situation of having to ask whether the other end of the SA supports ECN correctly or not and be prepared to behave differently depending on the answer. Not having to ask seems preferable.
An alternative would be to put a normative reference to 2401bis into the IKEv2 draft, although that may not be consistent with the intended time schedules of the two drafts.
Thanks, --David