--------------------

Francis Dupont (2005-10-16):
https://www.machshav.com/pipermail/mobike/2005-October/001120.html

- about 4.4: if/when we'd like to extend the mechanism, two things
seem to be interesting:
 - the capability to move to another addresses (than the addresses in
   the IP header of the message), for instance for network controlled
   mobility.
 - the capability to limit the update to a SA set (i.e., partial update).
Both will be easier with a payload...

--------------------

Jari Arkko (2005-10-23):
https://www.machshav.com/pipermail/mobike/2005-October/001160.html



I agree that there are potentially interesting extensions,
such as some kind of network control or limiting the SA
set. As we have decided earlier, these are indeed future
extensions and not a part of the initial base RFC.

But lets talk about what design is best to accommodate for
such future extensions. In both cases that you mention,
it seems that the addition of a payload (with appropriate
previous capability negotiation) does the job. For instance,
if we would like to design a "limited SA set update" feature,
then in the IKE init phase we can find out if both peers support
that. Then, if this particular movement is a limited update,
we can include a new payload to that effect in the IKE
exchange that tells the peer about the move.

Creating such payload now, however, would change the
design quite a bit and would imho make it hard to support
NATs.

So, I would suggest that there are no text changes needed
for the current document.

--------------------

Francis Dupont (2005-10-23):
https://www.machshav.com/pipermail/mobike/2005-October/001167.html

   So, I would suggest that there are no text changes needed
   for the current document.
   
=> my comment was about future (if/when...).

--------------------

Jari Arkko (2005-10-23):
https://www.machshav.com/pipermail/mobike/2005-October/001169.html

Right.

--------------------

Mohan Parthasarathy (2005-10-25):
https://www.machshav.com/pipermail/mobike/2005-October/001209.html

I agree that the new payload is the way to go. 

--------------------