Since I won't be able to join the decision making about the
requirement level of DHCPv6, I'd like to present my opinion in an
off-site manner. I'll separate the requirement for stateful address
autoconfigurataion (the M bit) part and other configuration (the O
bit) part, as suggested by Dave.
As for stateful autoconfiguration by DHCPv6:
If I was just asked to vote either for MAY or for SHOULD, I would vote
for MAY, just for the same reason as the one Christian said in the
Monday session. However, I can live with SHOULD as well, as long as
the requirement clearly states that there may be IPv6 nodes that do
not support stateful autoconfiguration and that administrators should
take care.
What I'm afraid about when we take SHOULD is that the administrators
might naively assume it is safe to specify the "M" bit in Router
Advertisement (without specifying prefixes that can be used for
stateless autoconfiguration). Then many nodes not supporting stateful
autoconfiguration might lose global connectivity.
>From this point of view, I don't think the following proposal in the
ML is a perfect compromise:
Stateful Address Autoconfiguration SHOULD be supported, unless all
possible use cases for the specific implementation concerned are clearly
satisfied by Stateless Address Autoconfiguration.
because the phrase "all possible use cases for the specific
implementation concerned" is ambiguous.
I'd like the text to specify (examples of) "the possible use cases"
concretely.
Or I'd reverse the logic, like:
Stateful Address Autoconfiguration SHOULD be supported, when some
use cases for the specific implementation concerned are not
satisfied by Stateless Address Autoconfiguration.
And/or I'd add an explicit warning to administrators:
At the same time, network administrators should take care about the
effect of disabling stateless autoconfiguration (see Section 5.3).
As for other configuration (e.g. DHCPv6) by DHCPv6:
I would vote for SHOULD, with one condition that
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
p.s. I have read RFC 2461 and 2462, and I believe I understand the RFCs.
p.p.s I'll be offline for 10 hours in 15 minutes.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
