[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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------