Thomas Narten wrote:
I think making that a SHOULD is premature and too strong, since we
haven't explored what the desirable behaviors are when both M and A
bits are set. (When M is set and no prefix has A, then using DHCP
is a no-brainer.)
Here is how RFC 2119 defines SHOULD:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that
there may exist valid reasons in particular circumstances to
ignore a particular item, but the full implications must be
understood and carefully weighed before choosing a different
course.
That is, it is not a standards violation to not follow this, but
unless you have a good reason to ignore the advice, follow it.
Given that, I think SHOULD is exactly right. This is what
implementations (that don't know any better) ought to be doing.
I've seen to many places were a stronger meaning has been assigned to
"SHOULD" to be happy with this. For instance, the implication has been
that to be fully compliant all MUST/MUST NOT has to be satisfied, as
well as all SHOULD/SHOULD NOT, and some vaguer notion of "conditional
compliance" or something like it if all the SHOULD/SHOULD NOT are not
satisfied.
I can imagine that a host wants to have the option to have local policy
to handle the case when both M and A bits are set, but there is nothing
in the "SHOULD" that allows for local policy control.
I can imagine that too. (And while I'm skeptical that this would
actually be useful in practice, that's beside the point). Adding such
a local option seems like a fine thing for implementations to add if
they want to. Nothing in our standards prevents an implementation from
doing so, and neither would the SHOULD above.
We have a history of making such knobs explicit - for instance, see the
discussion about default values in RFC 1122.
If what we really want to say is
An implementation MAY have a configuration option ignore
stateless addresses and/or stateful (DHCPv6) addresses when both
are present from their configuration protocols. If so, that
option SHOULD default to accepting addresses from both stateless
and DHCPv6.
then why can't we explicitly say that?
Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
