Re: issue 6: scope of SA changes

 In your previous mail you wrote:

   Lets have a consensus call on this.

=> consensus on a mailing list takes time...

   From the list
   discussion so far I don't see enough people commenting
   on this that would enable us to make decision. For
   a more accurate decision, I have broken the issue down
   into three questions.
   
   1. Would it be useful to treat different flows or applications
       in a different manner with regards to their multihoming
       behaviour? For instance, keep one flow always in GPRS
       but allow another flow to use LAN where available.
   
       Yes, mandatory [X]
       Yes, optional  [ ]
       No             [ ]
   
=> note this is exactly the way SCTP works.

   2. Would you like to provide this functionality through
   
       Separate IPsec SAs and their independent addresses   [X]
       Separate IKE SAs and their independent addresses     [ ]
   
=> one IKE SA to manage the whole thing is the simplest (so the best)
solution.

   3. If you prefer the use of IPsec SAs for this purpose,
       would you like
   
       always manage each SA separately           [ ]
       provide a default where all SAs are moved  [X]
   
   Send your answers by Wednesday, Nov 3rd, 2004.

=> not everybody is at 100% on this job, please give reasonable
dead-lines (i.e., don't follow another WG pretty bad example :-).

   The rationale
   behind your answers will help others form their opinions, so
   please state also why you are answering in a particular way.
   
=> there is something forgotten: what to do with the SPD?
If only SAD is updated, at the next re-keying the new SA pair
will use the old addresses... In the mobility case one can even
argue some SPD entries without corresponding SAs should be updated
too!

Regards

[email protected]