>>>>> On Wed, 19 May 2004 10:56:39 -0700 (PDT),
>>>>> Erik Nordmark <[EMAIL PROTECTED]> said:
> So if you think that the existence of the ManagedFlag implies that there
> is an API (which I don't think FWIW) then shouldn't you argue that
> all existance of ManagedFlag (and OtherConfigFlag) should be removed
> from the document? (and not just the above paragraph)
> Hence I'm confused.
I was also confused about the same point, so I asked a question to
clarify the intention in a separate message...but I've not seen a
response to it.
> My concern is that in removing all mention of the state transitions
> we are removing information from the document, yet we haven't shown
> that that information is incorrect.
> (We haven't shown that it is needed either, but the approach seems to
> be leave things unchanged unless there is a reasonably strong case.)
Assuming it's okay for Christian to mention other documents on
details, can you live with the last proposal from Ralph?
The details of how a host uses the M flag from a valid Router
Advertisement it receives will be described in a separate document.
Or, if you feel happier by mentioning changes of the M bit explicitly,
we could alternatively say
The details of how a host uses the M flag, 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.
(based on a previous text from Ralph)
This way, we can avoid the use of the "possibly extraneous state
variable" which is internal information in the implementation, while
keeping the essential idea about external behavior.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
