All, Thanks for the feedback on this subject so far.
I think we are now approaching a consensus, so here is a summary of resolution. - keep the M/O flags - clearly specify the protocols for the flags: RFC3315 for M and RFC3736 for O - clarify (change) the meaning of the M/O flags; they are just hints of availability of the corresponding services, not triggers for invoking the protocols under a certain level of requirement - remove or reword "requirements" regarding these flags according to the above change - remove ManagedFlag and OtherConfigFlag, which were implementation-internal variables in RFC2462 tightly depending on the "requirement" nature of the M/O flags - clarify the possible confusion coming from the fact that RFC3736 calls itself "stateless" while rfc2462bis uses "stateful" - leave the actual usage of the M/O flags will be used to a separate document. rfc2462bis mentions the other document The followings are the specific changes I'd propose. These are just a draft of draft, but would be very close to the final text (unless I get serious comments). I'm referring to rfc2462bis-00 as the "old" text, but it should not be so different from RFC2462 on this matter. 1. revise abstract as follows: [...] The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information should be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they should be obtained through the stateless mechanism, the stateful mechanism, or both. [...] [...] The details of autoconfiguration using the stateful protocol are specified elsewhere. To: [...] The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information can be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they can be obtained through the stateless mechanism, the stateful mechanism, or both. [...] [...] The details of autoconfiguration using the stateful protocol is specified in RFC3315 and RFC3736. 2. same change as the previous one to the first paragraph of Section 1. 3. Revise the third paragraph of Section 1 to: In the stateful autoconfiguration model, hosts obtain interface addresses and/or configuration information and parameters from a DHCPv6 server. Servers maintain a database that keeps track of which addresses have been assigned to which hosts. The stateful autoconfiguration protocol allows hosts to obtain addresses, other configuration information or both from a server. Stateless and stateful autoconfiguration complement each other. For example, a host can use stateless autoconfiguration to configure its own addresses, but use stateful autoconfiguration to obtain other information. 4. add the following paragraph between the third and fourths paragraphs of Section 1: To obtain other configuration information without configuring addresses in the stateful autoconfiguration model, a subset of DHCPv6 will be used [RFC3736]. While the model is called "stateful" in order to highlight the contrast to the stateless protocol defined in this document, the intended protocol is also defined to work in a stateless fashion. This is based on a result, through operational 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. 5. revise the last sentence of the (current) fourth paragraph of Section 1: [...] The site administrator specifies which type of autoconfiguration to use through the setting of appropriate fields in Router Advertisement messages [5]. To: [...] The site administrator specifies which type of autoconfiguration is available through the setting of appropriate fields in Router Advertisement messages [5]. 6. revise the last bullet of the list in Section 3: o System administrators need the ability to specify whether stateless autoconfiguration, stateful autoconfiguration, or both should be used. Router Advertisements include flags specifying which mechanisms a host should use. To: o System administrators need the ability to specify whether stateless autoconfiguration, stateful autoconfiguration, or both is available. Router Advertisements include flags specifying which mechanisms a host can use. 7. revise the fifth paragraph of Section 4 (page 9) as follows: The next phase of autoconfiguration involves obtaining a Router Advertisement or determining that no routers are present. If routers are present, they will send Router Advertisements that specify what sort of autoconfiguration a host should do. If no routers are present, stateful autoconfiguration should be invoked. To: The next phase of autoconfiguration involves obtaining a Router Advertisement or determining that no routers are present. If routers are present, they will send Router Advertisements that specify what sort of autoconfiguration a host can do. When no routers are present, stateful autoconfiguration may be available. 8. revise the sixth paragraph of Section 4 as follows: [...] Router Advertisements contain two flags indicating what type of stateful autoconfiguration (if any) should be performed. A "managed address configuration" flag indicates whether hosts should use stateful autoconfiguration to obtain addresses. An "other stateful configuration" flag indicates whether hosts should use stateful autoconfiguration to obtain additional information (excluding addresses). To: [...] Router Advertisements contain two flags indicating what type of stateful autoconfiguration (if any) is available. A "managed address configuration (M)" flag indicates whether hosts can use stateful autoconfiguration [RFC3315] to obtain addresses. An "other stateful configuration (O)" flag indicates whether hosts can use stateful autoconfiguration [RFC3736] to obtain additional information (excluding addresses). 9. add the following to the end of the previous part: The details of how a host may use the M flags, including any use of the "on" and "off" transitions for this flag, to control the use of the stateful protocol for address assignment will be described in a separate document. Similarly, the details of how a host may use the O flags, including any use of the "on" and "off" transitions for this flag, to control the use of the stateful protocol for getting other configuration information will be described in a separate document. 10. remove the definitions of ManagedFlag and OtherConfigFlag from Section 5.2 (page 12). We'll also need to adjust the wording around the definition. 11. revise Section 5.5.2 as follows: Even if a link has no routers, stateful autoconfiguration to obtain addresses and other configuration information may still be available, and hosts may want to use the mechanism. From the perspective of autoconfiguration, a link has no routers if no Router Advertisements are received after having sent a small number of Router Solicitations as described in RFC 2461 [5]. 12. remove the first and second paragraphs of Section 5.5.3 ("requirements" parts of the M/O flags). -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------