Subject: RE: [rfc2462bis] summary and proposal about the M/O flags

From: [email-masked]
Date: Tue, 25 May 2004 09:21:50 +0300

Hi Jinmei,

The proposed text is OK with me.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of [email-masked]
> Sent: 24 May, 2004 14:24
> To: [email-masked]
> 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-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 25 May 2004 13:41:21 -0400

I agree thanks for your persistence on this highly discussed topic of these two bits :---) WOW.
/jim 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of JINMEI Tatuya / ????
> Sent: Monday, May 24, 2004 7:24 AM
> To: [email-masked]
> I think we are now approaching a consensus, so here is a 
> summary of resolution.
> 
> - keep the M/O flags
> 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"