In your previous mail you wrote:

   The goal of that API is to provide a simple way to manage socket level 
   preference.

=> my concern is your goal is to fulfill a requirement from developpers
than my goal is to fulfill a similar requirement from users. As there
are far more users than developpers and as developpers are users too and
as my proposal works for both users and developpers, I consider you are
just solving the wrong problem...

   There is already IPV6_PKT_INFO that allows to manipulate address 
   things, and these options just allows a more loose-grained control
   over that.

=> I don't believe that IPV6_PKT_INFO is a good example of a developper
friendly device (:-).

   Your idea may be a good proposal too and I cannot see why they would be 
   exclusive.
   
=> they are not exclusive but we should work first on the most flexible/
general one. And before ask users about what they'd like to get.
As an user my immediate needs are:
 - a policy table in the context
 - a global flag to choose the largest scope
 - nothing about home/care-of or temporary/public as I don't use
   these features.
Today I have (in recent KAME codes) only a global policy table which
is not enough on multi-user boxes.

Thanks

[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to