Re: Protocol Drafts - What's different.

 In your previous mail you wrote:

   Window size requirements
     
=> if you speak about the IKE message window, there are two windows,
one for each way (i.e., one for each peer as the initiator of
the exchange). Without two windows simultaneous exchanges could
give deadlocks and/or spurious retransmissions.

      addrmgmt: Probably does not work with window size 1, since 
      return routability is verified using a separate informational 
      exchange before updating SAs.
   
=> the optional RR check uses the other way...

   NAT behavior
   
      mobike-protocol, addrmgmt: Do not work with NATs.
   
=> and nothing will be done to change this if the WG still believes
interoperability with NATs is not useful.

   When A changes its address, and B has several addresses:
     
      addrmgmt: Seems to assume that B's address stays the same?
   
=> the answer is simple: B is supposed to manage its addresses.
Note that the addrmgmt provides a way for A to change the B address too
but it is not the standard way.
     
   If there is no response to an IKE request, and both parties have
   several addresses (so it is not clear which end is having problems):
   
      addrmgmt, smobike: Seem to assume the information is obtained 
      in some other, unspecified way?
   
=> yes, this is supposed to be done by the generic mobility/multi-homing/etc
control mechanism.
   
   Scope of address updates:
   
      addrmgmt: Updating individual child SAs is possible.
   
=> IMHO this is the main difference: the idea is to manage all the IPsec
SAs between two multi-homed peers using different peer addresses from
one IKE SA.

Regards

[email protected]