Merged IKE - suites and negotiation

[Black_David@emc.com]

> For instance, although I still prefer
> suites, I'm not exactly sure how the ESP/AH
> extended sequence numbers are supposed to work, now that we're not
> individually negotiating features. I guess it will be defined as part
> of the suite (not only what cryptographic algorithms are used, but
> whether ESP/AH extended sequence numbers will be used).

What about viewing suites as one component of a multi-component
negotiation, where each component is negotiated independently
as in IKEv2?  I'm concerned about things like the extended
sequence number and options related to transport processing -
there's currently an SA attribute related to ECN, and I can't
be sure that another won't arise as part of allowing outer to
inner DSCP (Differentiated Services Code Point) propagation
at tunnel egress.  These don't feel like natural parts of a
crypto suite, and in essence demanding that everything be
part of an all-encompassing suite only works in 20/20 hindsight.
I got bit by the analogous structure of IKEv1 proposals in
the ECN work; if one actually tries to use the ECN Tunnel SA
attribute, it can easily double the number of proposals that
need to be offered.  I'd sure like to see IKEv2 not repeat
this problem or make it worse.  Having the humility to admit
that we might not have anticipated everything that ought to
be part of IKE would be a good thing.

Thanks,
--David