Jinmei, Your wording works for me well. Good suggestion too.
/jim > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of JINMEI Tatuya / ???? > Sent: Friday, May 21, 2004 4:12 AM > To: [EMAIL PROTECTED] > Subject: [rfc2462bis] reword "stateful" for other config info? > > One (perhaps last) question about the M/O flags for rfc2462bis: > > Currently, RFC2462 uses the term "stateful" as the counter > part of the "stateless" configuration defined in RFC2462, > both for address configuration (the M flag) and for other > configuration (the O flag). > > Using "stateful" should be okay for address configuration > (the M flag part). > > However, as Ralph pointed out before, "stateful" may not be > appropriate for other configuration information: > https://www1.ietf.org/mail-archive/working-groups/ipv6/current > /msg02262.html > > In particular, the fact that RFC3736 (which we are primarily > considering as the protocol for the O flag) is entitled > "*Stateless* Dynamic Host Configuration Protocol (DHCP) > Service for IPv6" will confuse implementors if we keep > calling it "stateful" in rfc2462bis. > > So, I strongly believe we should clarify this point in some way. > Possible solutions would include: > > 1. remove "stateful" from the definition of the O flag (in > rfc2461bis), that is, change > > O 1-bit "Other stateful configuration" flag. When > set, hosts use the administered > (stateful) protocol > for autoconfiguration of other (non-address) > information. The use of this flag is > described in > [ADDRCONF]. > (RFC2461 Section 4.2) > > to (e.g.): > > O 1-bit "Other configuration" flag. When > set, hosts use a separate protocol > for autoconfiguration of other (non-address) > information. The use of this flag is > described in > [ADDRCONF]. > > and reword rfc2462bis accordingly. > > 2. do not touch the definition of the O flag, but add notes for > clarification in rfc2462bis like this: > > While the flag and the corresponding protocol are called > "stateful" in order to highlight the contrast to the stateless > protocol defined in this document, the intended protocol > [RFC3736] is also defined to work in a stateless fashion. This > is based on a result, through experiments, that all known > "other" configuration information can be managed by a stateless > server, that is, a server that does not maintain state of each > client that the server provides with the configuration > information. > > I personally prefer the former with small preference since it > should be a cleaner clarification. But I can live with the > second approach, too. > > What do others think? Is there any other opinions? > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, > Toshiba Corp. > [EMAIL PROTECTED] > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [EMAIL PROTECTED] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > >
