> From: Erik Nordmark [mailto:[EMAIL PROTECTED]
>
> > 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.
>
> The issue is that by having PREFER_FOO and PREFER_NOTFOO flags
> is that the absense of having any of PREFER_FOO and PREFR_NOTFOO flags
> set in a setsockopt nothing about the "foo" state can change.
> If it did change they the application couldn't change the state for
bar
> independently of foo.
The spec doesn't currently discuss this issue, but this is what I meant
by
"confuses the issue". It currently implies that setting the flag to
PREFER_FOO will undo your orthogonal PREFER_BAR, since it implies that
setting PREFER_NOTFOO will undo a previous PREFER_FOO.
This is actually another argument for splitting the option into 3
separate
options. Then it's clear that a set overrides any previous set, and
doesn't interfere with the other 2 orthogonal options.
It also provides a reasonable meaning for the value 0.
As presently worded, it's unclear what the meaning of value 0 is.
> > 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.
>
> With the complications that some failures will appear late e.g. due to
> a source address of the type not (or no longer) being available on
> the outbound interface.
Right.
> Another complication is that I don't know what it means to
> say REQUIRE_HOA or REQUIRE_COA if the node isn't
> currently mobile or when it is at home.
> The softer notion of preferences avoids this, but addition
> validation ("is this address a HoA") adds that complication
> back in I think.
Agree.
My personal vote is that it's still worthwhile. Let's see what
others say.
-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]
--------------------------------------------------------------------
