Thomas - thanks for the review of the proposed text. Good catch on the "NOT not" problem.
I used [DHCPv6lite] as a citation for compatibility with the previous revs of the text, and the text RFC 3736 explicitly where I wanted to emphasize that there is a specific way to use DHCP described in that RFC. - Ralph On 4/12/06 3:34 PM, "Thomas Narten" <[EMAIL PROTECTED]> wrote: > Hi Ralph. > > Revisiting this thread... I think your proposed text is fine. The only > question I have is that I assume you want to be consistent in > referring to "DHCPv6lite" or "RFC3736" (both are used in the text > below.) Also, one nit (from my original text!) > > Thomas > > Ralph Droms <[EMAIL PROTECTED]> writes: > >> Second try, this time with new text on top and explanation below. > >> M : >> >> 1-bit "Managed address configuration" flag. When set, it >> indicates that addresses are available via Dynamic Host >> Configuration Protocol [DHCPv6]. When the M flag is set, >> nodes SHOULD use DHCPv6 to obtain addresses (and associated >> configuration information) to be assigned to the interface on >> which the RA was received. Note that when the M flag is >> set, the setting of the O flag is irrelevant, since the DHCPv6 >> server will return all available configuration information >> together with any addresses. > >> O : >> >> 1-bit "Other configuration" flag. When set, it indicates that >> DHCPv6 for other configuration information [DHCPv6lite] is available >> for delivery of other (non-address) information. Examples of such >> information are DNS-related information or information on other >> servers within the network. When the O flag is set, > >> - If the M flag is also set, the O flag is irrelevant (as >> described above) and the node SHOULD use DHCPv6 to obtain >> addresses and associated configuration information. >> >> - If the M flag is not set, the node SHOULD use DHCPv6 as >> described in RFC3736. > >> Note that if neither M nor O are set, the node SHOULD NOT not > > s/NOT not/NOT/ > >> request any information with DHCPv6. > > >> In the interest of simplicity and consistency (note that the protocol in >> question is referred to as DHCP or DHCPv6 through all of specifications [as >> well as in the original version of this text], not "DHC"), I suggest the >> text above. > >> Comments on previous earlier text: > >> including addresses that are likely not available via stateless address >> autoconfiguration. > >> Deleted as it adds no discernible content to the text. > >> Clients SHOULD use DHC to obtain addresses (and associated >> configuration information) as described in [ADDRCONF]. > >> S/Clients/The node/ >> S/DHC/DHCPv6/ >> Deleted reference to [ADDRCONF] (what part of [ADDRCONF] was referenced >> here?) >> Added reference to interface on which RA was received for clarity > >> since the DHC server will return "other" > >> S/DHC/DHCPv6/ >> s/"other"/all available configuration information/ > >> [DHCPv6lite] is available for autoconfiguration of other > >> s/autoconfiguration/delivery/ because the configuration involves a server >> and is not "autoconfiguration" > >> - If the M bit is also set, clients SHOULD use DHC to obtain >> addresses (and associated configuration information) as >> described above. > >> Reworded for clarity >> >> - Ralph > >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
