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