Subject: [Mobike] Closing some less controversial issues

From: <[email-masked]>
Date: Fri, 6 Aug 2004 03:13:02 +0300

I think we should close some of the less controversial 
issues on the issues list. These have been discussed on the 
mailing list and meetings, and I think we have a rough
consensus on them. 

If you disagree, please tell so within a week or so.

Issue 2: "Is simultaneous movement of both parties supported?"

   "No; both parties can be mobile, but simultaneous 
   movement is not supported."

Issue 9: "Does MOBIKE require RFC2401bis?"

   "IKEv2 requires RFC2401bis, and MOBIKE requires IKEv2."

Issue 7: "Do we support tunnel mode only, or tunnel mode first and
transport later, or both by same document?"

   "First document will consider only tunnel mode."

Issue 13: "Does switching from IPv4 to IPv6 or vice versa work?
Presumably only for tunnel mode?" 

   "Changing from IPv4 to IPv6 or vice versa should work 
   for tunnel mode at least."

Cheers,
Pasi (as issues list maintainer)
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Joe Touch <[email-masked]>
Date: Thu, 05 Aug 2004 17:20:29 -0700

>    movement is not supported."

What mechanism will be used to ensure that only one end moves at a time? 
If you cannot ensure it, what happens _when_ it happens?

>    "First document will consider only tunnel mode."

IMO, it would be more useful to support transport mode than tunnel mode. 
(reasons in draft-touch-ipsec-vpn)

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 6 Aug 2004 03:29:06 +0300

>    for tunnel mode at least."

I agree to closing all these issues. 
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Fri, 06 Aug 2004 04:45:14 +0200

In your previous mail you wrote:

   
=> note that I plan to write a short document which explains both
why transport mode is out of scope and how transport mode can
take advantage of mobike (peer address list to be accurate).

=> please close them.

Regards

[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Fri, 06 Aug 2004 04:52:38 +0200

=> none.

=> message exchange failure, timeout and full reset of everything.

   
=> I understand your reasons but transport mode of tunnels is a bit
special and should be handled by specifics mechanisms...
Can we talk about this later and/or off-line?

Regards

---

From: Joe Touch <[email-masked]>
Date: Thu, 05 Aug 2004 19:58:01 -0700

> => message exchange failure, timeout and full reset of everything.

Thanks. My apologies for jumping in without a huge amount of context, 
and thanks for the answer. So long as it's handled, not defined-away ;-)

> Can we talk about this later and/or off-line?

Sure. Again, just concerned about the statement, and glad it's handled 
already.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 06 Aug 2004 09:03:14 +0300

I agree with closing these issues. Joe: I believe
transport mode is useful too, but I'd like to make
us do the tunnel mode first, as it fits our primary
scenario, the VPN roadwarrior case. Francis: Yes,
it would be very good if you could come up with the
the document that you mentioned.

--Jari

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 6 Aug 2004 09:30:53 -0700

I agree to close all this. But i don't understand your conclusion on Issue 9.
I am assuming the answer is yes.

-mohan

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Thursday, August 05, 2004 5:13 PM
Subject: [Mobike] Closing some less controversial issues

Cheers,

---

From: Jari Arkko <[email-masked]>
Date: Sun, 08 Aug 2004 11:15:57 +0300

The answer is yes. Pasi meant that since IKEv2
requires RFC 2401bis and MOBIKE requires IKEv2,
then MOBIKE has to assume RFC 2401bis also...

--Jari