RE: [rfc2462bis issue 277] M/O flags and DHCPv6

[[e-mail]]

Jinmei,

Here are my 2 cents; I'll send comments on the points I have
comments, otherwise note any non-comment as a non-objection.

> Since this message is lengthy, I'll first summarize the major
> (proposed) changes as follows:
> 
> - clarify that the stateful protocol *is* DHCPv6.  For example, say in
>   Section 1 that:
> 
>    In this document, Stateful autoconfiguration for IPv6 means DHCPv6
>    [7].
> 
> - change the first part of Section 5.5.2 to:
>    If a link has no routers, a host MAY attempt to use stateful
>    autoconfiguration to obtain addresses and other configuration
>    information.  An implementation MAY provide a way to enable the
>    invocation of stateful autoconfiguration in this case, but the
>    default SHOULD be disabled.
> 
> (i.e. change MUST in the first sentence to MAY, and modify the second
>    sentence accordingly)
> 
> - use "SHOULD" instead of "should" in some related sentences of
>   Section 5.5.3.  For example, we'll have the following sentence:
> 
>    If the value of ManagedFlag changes from FALSE to
>    TRUE, and the host is not already running the stateful address
>    autoconfiguration protocol, the host SHOULD invoke the stateful
>    address autoconfiguration protocol, ...

This is OK with me.

> *** regarding question c ****
> 
> I'd first like to answer this question.  RFC2462 currently says:
> 
>    Stateful autoconfiguration for IPv6 is the subject of future work
>    [DHCPv6].
> (Section 1)
> 
> And, considering the latest standardization status, the current
> revision of rfc2462bis says:
> 
>    Stateful autoconfiguration for IPv6 is the subject of DHCPv6 [7].
> 
> However, I still don't think this is crystal clear.  I believe we
> should first clarify whether "stateful autoconfiguration" *equals to*
> DHCPv6 (as specified in RFC3315), or whether we should still leave the
> possibility of (future) other stateful protocols.  And then we should
> clarify this point in rfc2462bis more explicitly.
> 
> Personally, I would prefer the first option (i.e., the "stateful
> protocol" equals to DHCPv6).  Flexibility is in general a good thing,
> but in this case, I don't see a reasonable practical reason to leave
> other possibilities with ambiguous wording, particularly because the
> ambiguity has annoyed people and caused similar questions/discussions
> again and again.
> 
> If we can agree on this, I'll change the above sentence like:
> 
>    In this document, Stateful autoconfiguration for IPv6 means DHCPv6
>    [7].

I agree with your text.  I don't see the need to keep this as an open
issue in the standard.

> *** regarding question a ****
> 
> First, I think we can concentrate on Section 5 "PROTOCOL
> SPECIFICATION" (and its subsections).  For example, someone pointed
> out that the following sentence in section 4 is "ambiguous":
> 
>    A "managed address
>    configuration" flag indicates whether hosts should use stateful
>    autoconfiguration to obtain addresses.
> 
> because it uses "should", not "SHOULD".
> 
> But I don't think we should care about the wording in Section 4, since
> it's just an overview of the protocol, not the protocol specification
> itself.  In fact, there are no RFC2119 keywords throughout Section 4.
> Of course, we may have to revisit the wording when we resolve question
> b ("which keyword?") though.
> 
> Concentrating on Section 5, I've found the following candidates of
> RFC2119 keywords:

I don't have a strong opinion on the use of keywords.  Either way is OK,
in my opinion.
> (I interpret "the configuration-only version of DHCPv6" as so called
> "stateless DHCPv6" described in 
> draft-ietf-dhc-dhcpv6-stateless-04.txt.)
> 
> This is not a strong opinion, but I'd currently say "no" for this
> question.  The reasons are:
> 
> - in my opinion, the stateless DHCPv6 service should be a "ubiquitous"
>   service, and hosts that need autoconfiguration should try it by
>   default (that is, without seeing an O flag set, which needs an
>   explicit configuration in routers).
> 
> - the O bit indicates a "stateful" mechanism for other configuration
>   information than addresses.  If the information actually includes
>   some real "other" stateful resources (probably in a future
>   extension), using the stateless version of DHCPv6 may result in an
>   incomplete service.
> 
> Even if we agree on my opinion, however, it might still be useful to
> note that the protocol invoked by the O bit should be the full-spec
> DHCPv6 instead of the stateless version.

I think noting this would be a good thing.

John

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------