This is all a matter of being consistent with the Advanced IPv6 API, and with the established practice in POSIX world. Pretty much every setsockopt uses int, unless it has very peculiar reason not to do so. Using something else will only confuse people, and add a (minor) extra implementation burden on implementors.
Please note that this API document is a guideline to the community for developing address selection implementation that wants to alter the default. IETF does not specify formal API specification, this API is intended to be used as a guideline for POSIX world, if they decide to define such API someday. uint32_t is used for examples and used as type of flags for inet6_is_srcaddr(). It makes more sense for a flag to be an unsigned quantity. This document has gone through experts review and no one objected to this. But, changing uint32_t to int is not a big deal if working group feels that flags should be type 'int' for consistency. Does anyone else in the working group feel strongly about it?
I do think it is semantically clean to use an "impossible" value as restore to system default, while it is NOT clean to use a "possible" value for that.
Point taken. The authors will discuss this in the light of practical deployment applications.
Have you had a look at RFC3542 at all? (hint: §6.3 and §6.5)
Yes, we did. In fact if you look at it carefully, you can see an overlap of a co-author in both documents :-) Regards, -Samita -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
