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 Pekka Savola wrote: > > 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] --------------------------------------------------------------------
