Erik Nordmark <[EMAIL PROTECTED]> writes:
> Thomas Narten wrote:
> > Per my comment above, if you don't invoke DHC, you won't get all the
> > addresses the network is configured to be giving you. Hence, you
> > SHOULD invoke DHC to get them.
> 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 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.
Stated another way, if an implementation added a local policy
mechanism that allowed the user to change the default behavior, I'd be
very surprised if that policy mechanism disallowed the setting of a
policy that would be consistent with the recommended behavior. Thus,
there would be no reason to consider it to be uncompliant (unless
perhaps the default configuration was inconsistent with the
recommended SHOULD - but even that would be open for debate). And if
it chose to set the default to something else, presumably the
implementor "understood and carefully weighed" the issues, and thus
ignoring the SHOULD was justified.
> If we want to work out more details in this space, I suspect we need to
> start with understanding why some operator would set both M and A bits.
> But I think we can defer that discussion until we have more deployment
> experience.
Rather than spend a lot of time thinking up use cases (and whether
they are compelling or not, since we might even agree that such cases
don't make much sense), I think we should just make it clear what the
expected behavior should be, given what we know today. (And, to cover
the cases that _will_ happen in practice where a client is forced to
deal with this situation, even if only due to a misconfiguration.)
If we can't agree that a SHOULD is appropriate, then to be completely
honest, I don't know why we've been wasting all this time discussing
the M&O bits for the last umpteen months. The original text doesn't
have a SHOULD in it, and people complained mightily that it is
unclear what implemenations are supposed to do. Or am I missing
something?
Thomas
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
