Re: [rfc2462bis] relationship between M/O flags and related protocols

>>>>> On Thu, 13 May 2004 15:53:42 +0900, 
>>>>> JINMEI Tatuya <jinmei@isl.rdc.toshiba.co.jp> said:

> Although his suggestion was apparently supported by several key
> players in this group, I'm afraid details on actual changes for
> rfc2462bis may still vary.  So I'll soon throw concrete idea of the
> changes based on my own interpretation of his suggestion in a separate
> message.

And here are the proposed changes.  The basic idea is:

1. 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
2. remove "requirements" regarding these flags according to the above
   change
3. (optionally) make a separate document (standard or BCP) on how to
   interact the protocols with these flags

(In the followings, I'm assuming we have agreed that

  - we should clearly specify the corresponding protocols for the M/O
    flags
  - the protocol for the M flag is DHCPv6 (RFC3315)
  - the protocol for the O flag is the "stateless" subset of DHCPv6
    (RFC3736)

but these details are not the essential part of the proposal.)

The followings are some concrete examples of how I'd revise the
document based on the idea.

For 1, I'd revise the following sentence of RFC2462 Section 4 (page
9):

   A "managed address configuration" flag indicates whether hosts
   should use stateful autoconfiguration to obtain addresses.

to:

   A "managed address configuration" flag indicates whether DHCPv6 is
   available for hosts to obtain addresses.

For 2,
  - remove the notion of the ManagedFlag and OtherConfigFlag
   (conceptual) variables defined in Section 5.2, since these flags
   will become meaningless if we do not mandate invoking particular
   protocols by the RA M/O flags.
 - remove "requirement" sentences like the following one
     If the value of ManagedFlag changes from FALSE to TRUE,
     and the host is not already running the stateful address
     autoconfiguration protocol, the host should invoke the stateful
     address autoconfiguration protocol, requesting both address
     information and other information.
     (Section 5.5.3 of RFC2462)
- remove Section 5.5.2 of RFC2462 (that mandates performing the
  "stateful" protocol when no RAs)

Hopefully, these are not so different from what others imagined by
Christian's suggestion.  But I'm not that optimistic, and expect
objections.  Please make comments on the idea shown above,
particularly if you have an objection.

Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------