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

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 13 May 2004 15:53:42 +0900

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.
					[email-masked]

Subject: RE: the protocols for the M/O flags (Re: [rfc2462bis] whether we need the M/O flags)
From: "Christian Huitema" <[email-masked]>
To: JINMEI Tatuya / 神明達哉 <[email-masked]>, "Tim Chown" <[email-masked]>
Cc: <[email-masked]>
Date: Wed, 28 Apr 2004 09:29:23 -0700
List-Id: IP Version 6 Working Group (ipv6) <ipv6.ietf.org>

I think a whole lot of the issue has to do with the supposedly mandatory nature of the M flag, which leads to phrases like "do DHCP, and only if it fails do auto-config." It would be much simpler to simply define the flags as "announcing an available service", as in:

1) The "M" flag is set to indicate that a DHCPv6 address configuration service is available on this link, as specified in RFC3315.

2) The "O" flag is set to indicate that a DHCPv6 information service is available on this link, as specified in RFC3736.

We should then leave it at that, and leave it to nodes to decide whether they want to use these services or not. For example, a server with a configured address will never use DHCPv6 address configuration; an appliance that never has to resolve DNS names will never use the information service. By setting the flags to indicate service availability, we will reduce the amount of useless chatter on the link when the services are not in fact available.

We should note that, from a protocol point of view, there is no need to use the M bit to control stateless address configuration. This function is already achieved by the "Autonomous flag" in the prefix information option. If the flag is not set, the hosts will not configure information from the prefix. 

-- Christian Huitema

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

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 13 May 2004 20:00:14 +0900

>>>>> On Thu, 13 May 2004 15:53:42 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> changes based on my own interpretation of his suggestion in a separate

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

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 17 May 2004 17:42:29 +0900

Are folks happy with the following approach?  I've not seen any
objections (or any agreements either), but I'm not sure if I can start
editing based on the proposal, considering the fact that this is quite
a big set of changes.

Explicit support or objections are highly appreciated.  If the list is
still silent, I'll start revising the document anyway.

Thanks,

					JINMEI, Tatuya

>>>>> On Thu, 13 May 2004 20:00:14 +0900,

---

From: Tim Chown <[email-masked]>
Date: Mon, 17 May 2004 10:01:44 +0100

> still silent, I'll start revising the document anyway.

I agree with the changes, though...
 
> >   "stateful" protocol when no RAs)

Perhaps these can be written as "may" rather than "should"?  
 
Tim

---

From: "Christian Strauf (JOIN)" <[email-masked]>
Date: Mon, 17 May 2004 11:09:30 +0200

Jinmei,

> still silent, I'll start revising the document anyway.
I support all of your proposed changes.

Christian

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 17 May 2004 20:17:04 +0900

>>>>> On Mon, 17 May 2004 10:01:44 +0100, 
>>>>> Tim Chown <[email-masked]> said:

 

> Perhaps these can be written as "may" rather than "should"?  

Please let me check: are you suggesting to replace the "should"s with
"may"s instead of removing these sentences (which is my proposal)?

					JINMEI, Tatuya

---

From: Tim Chown <[email-masked]>
Date: Mon, 17 May 2004 12:45:59 +0100

> "may"s instead of removing these sentences (which is my proposal)?

Yes.  I suspect implementations may do both, thus rather than implementors
looking at the spec and wondering whether the issue has been considered, 
a "may" shows that it has, and the behaviour is their choice.

I do not feel strongly on it though, so would also support removal.

Tim

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 May 2004 09:18:23 -0700 (PDT)

Overall your proposal is good.

>      (Section 5.5.3 of RFC2462)

I think I'm suggesting the same thing as Tim.
Loosing the above setence means that implementations might not
look for changes in the flag value (but perhaps instead only look
at the flag in the first RA).
So saying something like
	Hosts which invoke DHCPv6 based on the ManagedFlag need to
	not only look for this flag when booting, but also observe whether
	the ManagedFlag changes from FALSE to TRUE in a subsequent Router
	Advertisement.

> >   "stateful" protocol when no RAs)

Restating that to not be a requirement also makes sense.
I think the section should become more of a note which points out
that in the absense of any routers hence router advertisements, 
stateless address autoconfiguration isn't available
and that a host MAY wish to use DHCPv6 in this case.

It would presumably make sense to clarify in that section that even
if this is done the host continues to operate the stateless protocol
i.e. the reception of a router advertisement (with A-flag in one
or more prefix option) in the future will trigger stateless.
This is to make it more clear that the absense of a router while
booting must not automatically "turn off" the stateless protocol.

  Erik

---

From: Alain Durand <[email-masked]>
Date: Mon, 17 May 2004 10:02:17 -0700

> I support all of your proposed changes.

Same here.

	- Alain.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 17 May 2004 15:04:17 -0400

I am basically in agreement with your approach; here are a couple of 

> >    invoking the protocols under a certain level of requirement

Rather than "hints", the M/O flags explicitly indicate that the
corresponding service is intended to be available (note that the service
might not be available due to some network or system failure).

> > 2. remove "requirements" regarding these flags according to the above

Agreed.

> >    interact the protocols with these flags

Can you give some examples of what conditions or interactions might be
included in such a document?

> >    available for hosts to obtain addresses.

Agreed.

> >    protocols by the RA M/O flags.

Agreed.

> >      (Section 5.5.3 of RFC2462)

This particular sentence would go away because of the previous bullet
(removing ManagedFlag and OtherConfigFlag)?  In general, editing out
requirements sentences sounds like the right thing to do.

As an aside, thinking about legacy implementations, I think the idea of
making the M/O flags indicators rather than triggers will avoid backward
compatibility problems.  For example, if an implementation uses an
OtherConfigFlag according to the current RFCs, it will use DHCPv6 for other
configuration when the O flag first transitions to the set state, and
continue to use DHCPv6 regardless of subsequent transitions.  Such behavior
seems to be compatible with the proposed changes (both practically and
because the proposed changes make no requirements on client behavior).

What about the situation if the 'M' flag transitions from set to not set?  I
don't have a good answer off the top of my hear...perhaps this situation is
an example of what should go into the BCP document you suggest?

> >   "stateful" protocol when no RAs)

Yeah, I guess this would fall under the general recommendation that M/O are
indicators and not triggers, and the client behavior if no RAs are received
might be discussed in the BCP doc...

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Mon, 17 May 2004 15:11:18 -0400

I think Jinmei-san suggested deleting the whole notion of an
internal-to-the-implementation ManagedFlag and OtherConfigFlag.  I
extrapolated from that suggestion that the host would (in a stateless way)
base its behavior on the most recently received values for M/O (which, I
guess, means the implementation really does need ManagedFlag and
OtherConfigFlag).  So, as soon as the M/O bits transition to set, the host
would begin using DHCPv6.

The host behavior when the M/O flags transition from set to unset is a
little less clear.  In the case of the O flag, the host will stop using
DHCPv6 for other configuration information.  Should it also stop using the
configuration information it received through DHCPv6?

Similarly, when the M flag transitions from set to unset, should the host
stop using any addresses obtained through DHCPv6?  Or should the host simply
not try to extend the lifetimes of any assigned addresses?

- Ralph

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 17 May 2004 18:00:48 -0700 (PDT)

> would begin using DHCPv6.

I think the intent is not to prescribe "begin using" but merely to make it
clear that the transition means that DHCPv6 is now available
whereas before the transition it was not available.

> not try to extend the lifetimes of any assigned addresses?

And the higher-level question is whether it is important to
recommend a particular host behavior in those cases.
I think one can make the case that life is easier for the network
administrator if all implementations behave the same during these
transitions, but given that we don't seem to want to prescribe that
DHCPv6 is trigger by the "on" transitions, perhaps it doesn't make
sense to try to prescribe behavior for the "off" transitions?

I think what is apparent is that after an "off" transition it
isn't useful for a host to try to renew information (addresses or others)
that it has received from DHCPv6, since the flags being "off" means
that the DHCPv6 service (the full or the stateless, respectively)
isn't available.
Perhaps we should make this statement in the document.

  Erik

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 18 May 2004 15:02:44 +0900

>>>>> On Mon, 17 May 2004 15:04:17 -0400, 
>>>>> Ralph Droms <[email-masked]> said:

> included in such a document?

It's just a rough sketch, but I'm currently thinking about a document
that describes

- how a host that implements DHCPv6 should behave.  The host would
  have an internal (conceptual) variable, controlling the policy about
  autoconfiguration, which should have at least three values:
  1: it should invoke DHCPv6 for address autoconfiguration regardless
     of the content of receiving RAs or the existence of RAs
  2: it should invoke DHCPv6 for address autoconfiguration if and only
     if it sees an RA changing the M bit from unset to set
  3: it should not invoke DHCPv6 for address autoconfiguration
     regardless of the content of receiving RAs or the existence of
     RAs
- same thing for a host that implements the "stateless" subset of
  DHCPv6 (RFC3736) for other configuration information.

The details can change based on further discussion, of course.  But at
the moment, I'd like to know if we can start editing rfc2462bis with
an expectation that we'll have some separate document like above.

And,

> an example of what should go into the BCP document you suggest?

Yes, probably.

BTW: RFC2462 currently says the transition from set to unset means
"nothing":

   If the value of the ManagedFlag
   changes from TRUE to FALSE, the host should continue running the
   stateful address autoconfiguration, i.e., the change in the value of
   the ManagedFlag has no effect.
   (Section 5.5.3)

Personally, I don't think this behavior makes much sense, but of
course we'll need to be careful if we try to change this (in the "BCP"
document, or wherever) since it may have an effect on existing
implementations.

					JINMEI, Tatuya

---

From: "Christian Strauf (JOIN)" <[email-masked]>
Date: Tue, 18 May 2004 08:32:42 +0200

Ralph,

> not try to extend the lifetimes of any assigned addresses?
very good questions. If Jinmei thinks that Tim's approach of using
"may"s is good, then I believe one should also propose a behaviour in
the cases when M/O bits are switching to unflagged. E.g.:

        (a) If the O flag is unset, a client may discontinue using
        stateless DHCPv6 and it may choose to discontinue using
        configuration information that was received while the O flag was
        set.

Similarly, I would propose something like

        (b) If the M flag is being unset, a DHCPv6 client may choose to
        send a Renew/Rebind message. If no renewal/rebinding is possible
        the client may discontinue using stateful DHCPv6. If the O flag
        is set, a client may try to receive other configuration
        information using stateless DHCPv6. Otherwise, a client may
        choose to behave as described in (a).

for the M flag.

Of course there are other ways of reacting to M/O flags that switch to
unflagged but I think that the above behaviour is reasonable. Trying a
Renew/Rebind will also handle the question if or if not a client should
continue using addresses that where received while the M flag was set
(basically, the DHCPv6 server will decide).

Christian

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 18 May 2004 15:36:55 +0900

>>>>> On Mon, 17 May 2004 18:00:48 -0700 (PDT), 
>>>>> Erik Nordmark <[email-masked]> said:

> whereas before the transition it was not available.

My intention was basically to stop prescribing "begin using" and make
it clear that the transition means the availability.  In that sense,
Erik is correct.  But then I also suggested to remove ManagedFlag and
OtherConfigFlag (which are internal-to-the-implementation) since they
are only meaningful when we are prescribing the invocation of DHCPv6,
so Ralph's understanding is also correct in that sense.

Regarding whether the host would begin using DHCPv6 at the transition
of the M flag from unset to set: rfc2462bis wouldn't say anything
about this point by the original intention.  If we can agree on making
a separate BCP document, it will clarify this point.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 18 May 2004 16:05:28 +0900

>>>>> On Mon, 17 May 2004 09:18:23 -0700 (PDT), 

> Loosing the above setence means that implementations might not
  ^^^^^^^ you meant "Losing" here, didn't you?

> 	the ManagedFlag changes from FALSE to TRUE in a subsequent Router

Good point.  Then how about the following approach?

- change the definition of ManagedFlag

  From:
      ManagedFlag      Copied from the M flag field (i.e., the
                       "managed address configuration" flag) of the most
                       recently received Router Advertisement message.
                       The flag indicates whether or not addresses are
                       to be configured using the stateful
                       autoconfiguration mechanism. It starts out in a
                       FALSE state.
  To:
      ManagedFlag      Copied from the M flag field (i.e., the
                       "managed address configuration" flag) of the most
                       recently received Router Advertisement message.
                       The flag indicates whether or not DHCPv6 is
                       available to obtain addresses.  It starts out
                       in a FALSE state.

- and revise Section 5.5.3 as follows:

   On receipt of a valid Router Advertisement (as defined in
   [DISCOVERY]), a host copies the value of the advertisement's M bit
   into ManagedFlag. If the value of ManagedFlag changes from FALSE to
   TRUE, it indicates DHCPv6 becomes available for address
   autoconfiguration.  The details of how the host should react to
   this change will be described in a separate.

(I'm assuming we'll have a separate document to describe the details.
But if we cannot agree on this path, we'll need to revise the proposed
text above accordingly.)

					JINMEI, Tatuya

---

From: "Christian Strauf (JOIN)" <[email-masked]>
Date: Tue, 18 May 2004 09:09:16 +0200

>   DHCPv6 (RFC3736) for other configuration information.
This might be tricky to implement. A potential problem would be how to
get the M information that arrives in the kernel space to a program like
DHCPv6 that runs in the user space (on many operating systems).

It would be easy to integrate this behaviour in a DHCPv6 client if that
client would listen to RAs and read M/O bits itself. You could then
store the policy information 1-2 in the DHCPv6 client's configuration
while policy 3 would be covered by not starting the DHCPv6 client at
all. Same goes for RFC3736-like behaviour.

Christian

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 18 May 2004 16:33:10 +0900

>>>>> On Tue, 18 May 2004 09:09:16 +0200, 
>>>>> "Christian Strauf (JOIN)" <[email-masked]> said:

> DHCPv6 that runs in the user space (on many operating systems).

Let me check...this should apply to the current RFC2462, shouldn't it?
I'm not sure why you are making this point in this context...

					JINMEI, Tatuya

---

From: "Christian Strauf (JOIN)" <[email-masked]>
Date: Tue, 18 May 2004 09:48:30 +0200

> I'm not sure why you are making this point in this context...
No, I was referring to your suggestion of writing a document (standard
or BCP) about the details of the protocol interaction which I believe is
a good idea because my feeling is that there are too many open questions
at the moment that need answers which could be given in such a document.

I that context, I think that it might be useful to figure out very early
at which level to implement the policies you suggest (kernel space (IPv6
stack) or user space (DHCPv6 client)). That was basically what I wanted
to remark. The comment was not targeted at changes of RFC2462.

Christian

---

From: Ralph Droms <[email-masked]>
Date: Tue, 18 May 2004 06:25:36 -0400

>whereas before the transition it was not available.

I agree; the flag indicates DHCPv6 is available and the spec will not 
prescribe host behavior based on the availability of DHCPv6...

>recommend a particular host behavior in those cases.

Yes.

>sense to try to prescribe behavior for the "off" transitions?

No, it doesn't make sense to prescribe the behavior in RFC 2462bis.  Would
it be useful to discuss alternatives and capture that discussion in a BCP?

>that the DHCPv6 service (the full or the stateless, respectively)

Yes ... sending more DHCPv6 message when the flag is off probably doesn't
make sense.  There might be some question about what the host does with the
information previously obtained through DHCPv6.

>Perhaps we should make this statement in the document.

It might even be something explicitly non-prescriptive like "This document
does not prescribe how a host behaves in response to the M/O flags."

---

From: Ralph Droms <[email-masked]>
Date: Tue, 18 May 2004 06:32:26 -0400

Your list of behaviors is a good starting point for a BCP document.  As you
point out, if we know there is rough consensus in support of writing such a
doc, RFC 2462bis can proceed without explicit prescription of client behavior.

I remember (my memory, of course, may be faulty) that the behavior of the
client you cite from RFC 2462 was specified to avoid DoS attacks in which
rouge RAs with the M/O flags set to off would not cause hosts to stop using
DHCPv6.

- Ralph

At 03:02 PM 5/18/2004 +0900, JINMEI Tatuya /

---

From: Tim Chown <[email-masked]>
Date: Tue, 18 May 2004 11:52:48 +0100

> rouge RAs with the M/O flags set to off would not cause hosts to stop using

So would such a document branch out to include cases like a node moving
between networks when using M and/or O hints?

Tim

---

From: Ralph Droms <[email-masked]>
Date: Tue, 18 May 2004 08:18:25 -0400

Regarding the last paragraph of suggested text:

mentioning just the FALSE to TRUE transition seems too limited (why is just 
the time of transition interesting?)  How about:

    On receipt of a valid Router Advertisement (as defined in
    [DISCOVERY]), a host copies the value of the advertisement's M bit
    into ManagedFlag, which saves the mostly recently received value of
    the M bit.  The details of how the host uses the M bit to control
    the use of DHCPv6 for address assignment will be described in a
    separate document.

- Ralph

At 04:05 PM 5/18/2004 +0900, JINMEI Tatuya /

---

From: Ralph Droms <[email-masked]>
Date: Tue, 18 May 2004 08:20:03 -0400

Yes - mobility (and DNAv6?) would be good topics for a BCP doc...

- Ralph

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 18 May 2004 10:23:42 -0700 (PDT)

Yes.

That assumption is fine with me.

>     the use of DHCPv6 for address assignment will be described in a

Better. But how about also stating that it might be useful to detect
when the flag values change. For instance,
    On receipt of a valid Router Advertisement (as defined in
    [DISCOVERY]), a host copies the value of the advertisement's M bit
    into ManagedFlag, which saves the mostly recently received value of
    the M bit.  The details of how the host uses the ManagedFlag,
    including any use of the "on" and "off" transitions for this flag, to
control
    the use of DHCPv6 for address assignment will be described in a
    separate document.

   Erik

---

From: Ralph Droms <[email-masked]>
Date: Tue, 18 May 2004 13:57:27 -0400

Erik - your proposed text looks good to me...

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Tue, 18 May 2004 20:16:15 -0400

I share your concern about mandating the implementation of a possibly
extraneous state variable.  Perhaps replacing your suggested text:

      the M bit.

with:

      The details of how a host uses the M bit from a valid Router
      Advertisement it receives will be described in a separate document.

would indicate that the use of the M bit is left to the implementation but
is not prescribed here?

- Ralph

At 03:17 PM 5/18/2004 -0700, Christian Huitema wrote:

> > I'm certainly not implying any API.
> > Why do you think the text with the forward reference to "a separate
> > document"
> > implies any API?
>
>The forward reference is asking the implementers to manage an extraneous 
>state variable. As far as ND is concerned, the host can be entirely 
>conformant and interoperate fine with others without that state variable. 
>So, the only reason for the state variable is to facilitate the 
>implementation of something else than ND, which will use the value of the 
>state variable. For that you need some form of API.
>
>-- Christian Huitema
>

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 19 May 2004 17:56:29 +0900

>>>>> On Tue, 18 May 2004 20:16:15 -0400, 

> would indicate that the use of the M bit is left to the implementation but

(I can personally live with any of the proposals, but)

Please let me clarify the things...it seems to me that Christian (H)
wanted two things:

1. minimize referring to other documents
2. avoid using a possibly extraneous state variable (ManagedFlag)

But in Christian's proposal (the first one of the above citation) he
only addressed the first point.  On the other hand, your (Ralph's)
proposal, you seem to have addressed the second point.  According to
what Christian originally said, either proposal seems to me
incomplete...

Meanwhile, there was a different opinion that it would be better to
clearly show the issue around the M/O flags has been considered:

>>>>> On Mon, 17 May 2004 12:45:59 +0100, 

> a "may" shows that it has, and the behaviour is their choice.

Considering all the three points, if Christian's main point is to
avoid the state variable rather than to minimize references, I guess
the last proposal from Ralph is the best:

(but if so, the appropriate place to put this text is not Section
5.5.3, but should be some introductory part of the document (section 1
and/or 4, probably).  Also, with this proposal we'll remove the
definition of ManagedFlag from Section 5.2.

					JINMEI, Tatuya