In your previous mail you wrote:
I look at it slightly differently although the result might be the same. The
mobile node should use its care-of address only if there's a very high
probablility that a movement will not break the application.
=> for me if P(movement) = 0 then P(a movement will break the app) = 0
then if (1. No mobility events will occur) then care-of should be used.
> I claim that it is up to the application to make these determinations,
> or else it is up to the context in which the user invokes the
> applications. Sometimes the same application may, or may not, have
> requirements for smooth network connectivity in the face of mobility
> events. Anything that is considered a "session" is an example of
> something that is likely to fail to satisfy the abovementioned
> conditions.
Ì agree with this - it should be up to the application.
=> but your draft doesn't implement what Charlie has written...
For example, suppose
a mobile node with care-of address CA and home address HA is opening a TCP
connection to a server D. If it's a telnet connection, you presumably want
to use HA. If it's a short-lived HTTP request, you presumably want to use
CA. Note that the mobile node might have both kinds of connections to D
simultaneously. So policies based solely on the addresses involved (D, CA,
HA) will not work.
=> then a single global policy table is not enough? I agree.
(One could consider policies that use port number/protocol, like IPsec
policies. The Zhao/Castellucia/Baker paper takes this approach. But
ultimately, it's really application/user knowledge that's needed here.)
=> the draft proposes a solution for application knowledge (socket option)
but not user knowledge (or do you suggest to add to every applications
some arguments and code in order to control address selections, I believe
this is not your intent, then clearly your draft needs something...)
I also agree that the use of anonymous addresses should be under the control
of the application. This is why my draft suggests, in both the mobility rule
and the privacy rule, that implementations may support a socket option to
control the preference.
=> I believe a socket option is not enough and the control should be done
through the contextual policy table too.
I think a default rule is possible & necessary.
=> I agree, freedom is not anarchy!
[EMAIL PROTECTED]
PS: can you explain how the control is done in your implementation?
PPS: perhaps an API for policy table control should be specified??
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
