Hi Jinmei,
The proposed text is OK with me.
John
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of [EMAIL PROTECTED]
> Sent: 24 May, 2004 14:24
> 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
--------------------------------------------------------------------
