In line...
On 4/17/06 5:51 PM, "Erik Nordmark" <[EMAIL PROTECTED]> wrote: > 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. I disagree - the M and A flags are independent of each other. When both are set, the host uses SAAC to assign itself an address on the advertised prefix, and uses DHCP to have addresses and other configuration information assigned from the DHCP service. Whether or not that configuration makes any sense is an operational issue, not a protocol issue. On my soapbox for a second, it seems to me that we are trying to wordsmith the behaviors for address assignment *much* more carefully than is necessary for interoperable implementations. >>> (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 don't see why this spec should define anything aobut host local policy. SHOULD is explicit enough. >> 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 - Ralph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
