FWIW, I totally agree with Jinmei. I'd like a MAY, but SHOULD worded the-other-way-around, without "unless" is also acceptable.
On Thu, 20 Mar 2003, JINMEI Tatuya / [ISO-2022-JP] [EMAIL PROTECTED]@C#:H wrote: > 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] > -------------------------------------------------------------------- > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- 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] --------------------------------------------------------------------
