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] --------------------------------------------------------------------