Francis Dupont wrote: > In your previous mail you wrote: > > and it can also satisfy per process behavior. > > > > => this is not true: I don't want to patch and recompile all > > applications. My concern is you provide a device then look for its > > usage, I prefer to get requirements and only after look for ways to > > satify them. > > I assume these socket options would be applicable more for new type of > applications. But I don't see a problem in updating existing > application with new socket option and recompile them, if the > application wants to serve special cases. For example, it's not > surprizing that common network application be modified for running > on mobile devices. > > => Oops, I believe the purpose of your draft is to help Mobile IPv6 > deployment... (:-) > > Also, per-socket control is more desirable than just per-process > control, as one application may choose to set different source > address for different set of sockets. > > => what I propose is not pure per-process control, it is to put the > control in the context of processes. It gives immediatly a per-process > control but with a way to manage the context from applications, it gives > a per-socket control too.
Though it may be with me with to be able to control this stuff through a process structure, I cannot find how your two points above are related to the goal of that draft which is to help IPv6 deployment. It does not necessarily conflict with your proposition, as it may not be the single _one_ means to tweak address selection. Some type applications may require frequent usage of this sort of tweaking, and it may be boring and not portability-proof to ask devellopers to manage themself these things through sysctl or whatever. The goal of that API is to provide a simple way to manage socket level preference. There is already IPV6_PKT_INFO that allows to manipulate address things, and these options just allows a more loose-grained control over that. Your idea may be a good proposal too and I cannot see why they would be exclusive. > > => if there are for each prefix a TMP and a PUBLIC addresses > > AI_PREFER_SRC_TMP & co are strictly useless so are candidate for a > > garbage collection when we'll run out of bits in ai_flag... > > I am not sure I understand your point here. > > => easy, if you have in each prefix a public address and some temporary > addresses the flags don't affect the source prefix choice. Yes, but there are situations when one does not want to have such a configuration. Thanks, --julien -------------------------------------------------------------------- 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] --------------------------------------------------------------------
