Erik,
In some cases, people feel that SHOULD is weaker than indicated
in RFC 2119. In others, people feel it is stronger.
IMO, if we're not going to formally redefine the meaning, we're
obligated not to redefine it informally by usage. Otherwise, what is
the purpose of inserting the phrase that states that these words have
the meaning defined in RFC 2119?
--
Eric
--> -----Original Message-----
--> From: Erik Nordmark [mailto:[EMAIL PROTECTED]
--> Sent: Monday, April 17, 2006 5:52 PM
--> To: Thomas Narten
--> Cc: IPv6 Mailing List
--> Subject: Re: Proposed M&O bits text for RFC2461bis
-->
--> 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
--> --------------------------------------------------------------------
-->
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
