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

Now I'd like to (re)start a bigger discussion about the M/O flags: how
we should describe the relationship between the M/O flags and the
related protocols.

So far, many people seem to have (somehow) agreed on what Christian
said (attached below): the M/O flags should just be hints of
availability of the corresponding services (or protocols) rather than
a trigger to invoke the protocols under a certain level of requirement.

While some part of his interpretation (i.e., "do DHCP, and only if it
fails do auto-config") was not really accurate according to the
specification as others already pointed out, I still think he made
important points, in that RFC2462 has "supposedly mandatory nature"
with ambiguity on details.

An example of the "mandatory nature" is the following sentence of
Section 5.5.3:

   If the value of ManagedFlag changes from FALSE to
   TRUE, ..., the host should invoke the stateful
   address autoconfiguration protocol, ...

The "ambiguity" includes:
  - the level of requirements (e.g., should the above "should" be
    actually SHOULD?, etc)
  - what is the protocol to be invoked by this statement (we are now
    trying to clarify this point)
  - what hosts should do if the M/O flags keep being cleared; e.g.,
    does this mean the hosts should not invoke the protocols?
  - what if the hosts do not implement the stateful protocol? (recall
    that in the node requirements document it is basically optional to
    implement DHCPv6 for the stateful address configuration)

I interpreted Christian's suggestion as one that tries to remove the
"mandatory nature" considering the current deployment/implementation
status, and in that sense, I tend to agree.  The suggestion won't
fully solve the ambiguity issues, but it will make the document
well-balanced based on the current status.

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.

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