Three fields: cookie, nonce, and SPI

[Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>]

Hugo made a suggestion that was more important with the "4" rather than
the "4/6", but I still like it. Currently there are two fields:

"cookie", used as an anticlogging token and a SPI
"nonce", used in the "4" version of IKEv2 for possibly keeping state
    (in addition to possibly keeping state in "cookie")

Hugo wanted the nonce to be completely random, to allow for weaker
assumptions on the prf function. I was unhappy about what seemed
like overconstraining the already overconstrained fields, but
he suggested separating them into 3 fields, which seemed a lot
less confusing:
   "cookie" (an anticlogging token)
   "nonce" (quantity chosen at random)
   "SPI" (connection identifier)
Any state that needed to be saved could be encoded in "cookie".

With the "4/6", it isn't necessary to keep state, other
than being able to verify the "cookie" as valid,
but I've always been uncomfortable making the "cookie" be
dual-purpose, since the algorithm for choosing the anti-clogging
token might be different from the best strategy for choosing
a SPI. And in case the cookie is chosen when Bob is being
stateless, I was always worried about him finding out that
he'd assigned the same cookie to two connections (admittedly
low probability, but if he's stateless it seems hard to
avoid). I suppose in that unlikely scenario he could break
the connection and start over. But I'd suggested allowing Bob
to change to a different SPI in message 4, which people always
winced at as "really really ugly", but reluctantly
agreed it was possible for Bob, when stateless, to compute
two identical cookies.

So, to avoid having people wince, and because I always found
the term "cookie" for "SPI" confusing, would anyone object
to separating things into the three fields Hugo suggested,
even though we are going back to "4/6"?

Radia