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
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
