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
--------------------------------------------------------------------

Reply via email to