I've read this document, and I would like to see it accepted as a WG document and charter item.
Comments on the current text: Section 3 > It is recommended that the application does a getsockopt() prior > calling to setsockopt() call so that it can save the existing > source address preference value, in the cases when the application > might need to restore the preferences. I think the above paragraph is unneeded and confuses the issue. Setting the flags to 0 will restore the system default behavior. If the app is using multiple values at different times, the behavior is really up to the app, and the issue is not specific to this socket option. RFC 2553 etc do not contain a similar statement for other socket options which have the same issue. I'd suggest deleting this paragraph. Section 4 > The above flags are ignored for the AF_INET address family. If a > returned address is an IPv4 address (either as AF_INET6 when > AI_V4MAPPED, or as AF_INET) then the source preference flags have > no effect. If someone implements Mobile IPv4, wouldn't the HOME/COA flags be applicable to IPv4 source addresses? Section 7: > Is there a need for REQUIRE flags in addition to or instead of the > PREFER flags? Note that in general it isn't possible to verify > that a requirement can be satisfied until sendto() or connect() > (when the destination address is known) thus this would result > in late errors being reported to the application. I agree "require" flags would be nice. For example, if an app requires a particular type of address and there are no such addresses available, it may be better to fail the setsockopt than either failing all sends or using another type of address instead. If the consensus is go this way, it would be better in my opinion, to split the socket option into 3 separate options (HOME/COA, TMP/PUBLIC, and CGA/NONCGA). For each of those three options, you'd have 5 values: Require A Prefer A Use system default rules Prefer B Require B I also saw a couple of typos/grammar issues which I will just send to the authors. -Dave -------------------------------------------------------------------- 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] --------------------------------------------------------------------
