Subject: some opinion about the requirement level of DHCPv6 (for nodereq)

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 20 Mar 2003 03:31:22 +0900

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

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

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 20 Mar 2003 04:19:38 +0900

(oops, sorry, the message was incomplete)

>>>>> On Thu, 20 Mar 2003 03:31:22 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> I would vote for SHOULD, with one condition that 

... that the other configuration specification is clearly separated
from full support of DHCPv6 (to mitigate the load of implementing the
full spec).  draft-droms-dhcpv6-stateless-guide may help to explore
this separation.

					JINMEI, Tatuya

---

From: Pekka Savola <[email-masked]>
Date: Thu, 20 Mar 2003 17:50:24 +0200 (EET)

FWIW,

I totally agree with Jinmei.  I'd like a MAY, but SHOULD worded 
the-other-way-around, without "unless" is also acceptable.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Mar 2003 19:51:18 +0100

I'm afraid it makes no sense in English to use
"when", since we are trying to weaken the SHOULD,
not to tell implementors how to design their products.

I voted for "SHOULD...unless" but I can't support
"SHOULD...when". 

  Brian