>>>>> On Tue, 18 May 2004 20:16:15 -0400,
>>>>> Ralph Droms <[EMAIL PROTECTED]> said:
> I share your concern about mandating the implementation of a possibly
> extraneous state variable. Perhaps replacing your suggested text:
> 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.
> 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?
(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,
>>>>> Tim Chown <[EMAIL PROTECTED]> said:
>> Please let me check: are you suggesting to replace the "should"s with
>> "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.
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:
The details of how a host uses the M bit from a valid Router
Advertisement it receives will be described in a separate document.
(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
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
--------------------------------------------------------------------
