I think that trying to codify in the specification differences in behavior based on which part of a specification a host implements is counterproductive because it adds unnecessary complexity and over-specifies the desired behavior. We should describe the behavior assuming an implementation of RFC 3315 without qualification. It is up to the implementor to decide how to behave if only part of the specification is implemented.
RFC 2461/2 does not make any accommodation for a host that does not implement stateless address autoconfiguration as specified in RFC 2462. There may, indeed, be such hosts whose intended networking scenario will never include stateless address autoconfiguration. Similarly, we don't need to add text to the description of the M/O flags to accommodate hosts that don't implement parts of RFC 3315. - Ralph On 4/14/06 7:26 AM, "JINMEI Tatuya / 神明達哉" <[EMAIL PROTECTED]> wrote: >>>>>> On Thu, 13 Apr 2006 09:09:15 -0400, >>>>>> "Bernie Volz (volz)" <[EMAIL PROTECTED]> said: > >> This new text doesn't work for the "O" flag. It implies that only >> dhcplite clients care about the O - this is not correct. *ALL* DHCPv6 >> capable clients need to honor the "O" flag - it just means that they >> only do Information-Request (not Solicits). > >>> - If the M flag is not set, nodes that implement >>> [DHCPv6lite] SHOULD use it as described in RFC3736. > >> This should be (as Thomas/Ralph had): >> - If the M flag is not set, the node SHOULD use DHCPv6 as >> described in RFC3736. > > I actually didn't intend to limit the applicability to > "DHCPv6lite-only" clients. In fact, since [DHCPv6lite] is a subset of > [DHCPv6], nodes that implement [DHCPv6] should be included in "nodes > that implement [DHCPv6lite]". But if my proposed text sounded so, I > don't mind using the original text here, or, more clearly: > > - If the M flag is not set, nodes that implement DHCPv6 (including > ones only implement [DHCPv6lite]) SHOULD use it as described in > RFC3736. > > Actually, my main point was to clarify that this one: > > - If the M flag is also set, the O flag is irrelevant (as > described above) and nodes that implement the full set > of the DHCPv6 protocol [DHCPv6] SHOULD use it to obtain > addresses and associated configuration information. > > applies to nodes "that implement full RFC3315". > >> Frankly, I thought the text that Ralph and Thomas worked out was >> sufficient. I don't mind if the "Note that" is changed as you suggest. > >> However, in a re-read of that text (and your text), I think you're all >> missing that with the M flag set, DHCPlite only clients should *ALSO* do >> DHCPv6 (though they'll only get "other configuration information"). The >> existing text implies to use DHCPv6 for addresses; not that all clients >> that are capable of DHCPv6 (either 3315 or 3736) run DHCPv6. > > Sorry, I'm not really sure exactly which part of the original (and my) > text you are referring to...could you be more specific? > >> Personally I've come to hate DHCPlite (3736) because it unnecessarily >> complicates matters. To me, M-bit set means: >> - send SOLICIT if client's DHCPv6 implementation supports it (ie, RFC >> 3315), or >> - send INFORMATION-REQUEST if not (ie, RFC 3315 or 3736), or >> - do nothing if no DHCPv6 support. >> If O-bit is set (and M-bit wasn't), send INFORMATION-REQUEST only or do >> nothing if no DHCPv6 support. > > I have a sympathy for you here, in that I also thought things are > unnecessarily complicated due to the combination of M/O and > DHCPv6/DHCPv6lite and implication of the combination. In my > understanding of the past discussion, however, others were not > convinced about the complexity and wanted to leave the "unseeable" > complexity open by preferring "simplicity", and they won the > discussion. So, I don't think we can reach a different consensus even > if we restart the old discussion... > >> And SHOULD is the correct terminology. If you or anyone else has good >> reason not do so, then you're free to do so. SHOULD is *NOT* MUST. It >> specifies the *DEFAULT* behavior which is what we're trying to do here. > > Well, while I said I agreed with some others about the SHOULD, I did > not actually oppose to the use of SHOULD; in fact, my proposed text > basically did not change the use of RFC2119 keywords. I just > "clarified" (IMO) that some of the requirements only apply to those > nodes that implement specific protocols. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
