I agree thanks for your persistence on this highly discussed topic of these two bits :---) WOW. /jim
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of JINMEI Tatuya / ???? > Sent: Monday, May 24, 2004 7:24 AM > To: [EMAIL PROTECTED] > Subject: [rfc2462bis] summary and proposal about the M/O flags > > 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 > -------------------------------------------------------------------- > >
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
