Thanks for the comments.
>>>>> On Mon, 9 Aug 2004 15:40:00 +0300 (EEST),
>>>>> Pekka Savola <[EMAIL PROTECTED]> said:
> Editorial suggestion: please switch to use XML2RFC. Pretty please!
<co-author hat off>
I tend to agree. At least I-D editors should use a tool that can
produce text that conforms to the I-D nits...
<co-author hat on>
> Two bigger issues:
> 1) This document doesn't seem to take a stance what happens when/if the host
> has multiple routers (whether on the same or different interfaces), and some
> of them have O/M bits set and some others not. Would that lead to a
> set-unset-set-unset loop, with triggering? If heard on another interface,
> should that affect how DHCPv6 is run?
Regarding multi-interface hosts, the base documents (RFC2461/2462 and
their bis-versions) only provide incomplete considerations. I don't
see any strong reason for describing these cases in this derivative
work.
Then, now concentrating on the case of a single link (interface), I
also do not think inconsistency among multiple routers is a big issue.
If I understand the sense of RFC2462 correctly, it is administrator's
responsibility to provide the consistency, and inconsistent
configuration is basically an admin error.
As described in Section 5.6 of RFC2462, a host will simply regard the
inconsistent flag values as changes of the bits. So, basically, the
behavior on the flag change should simply apply here.
One point that may require consideration is that the "change" might be
so frequent and so rapid. And we may need a separate consideration
for such an erroneous case, depending on the behavior on the flag
change. At this moment, I don't have a clear idea on this point.
> 2) The treatment of M/O flag "transitions" and the initial state after a
> reboot is not 100% unambiguous.
I admit the terminology and/or description are not fully clarified on
this point. Perhaps we need something similar to the host-internal
variables defined in RFC2462 (ManagedFlag and OtherConfigFlag) to
describe the behavior for the transition.
Also, I agree that the usage of "on", "off", "reset", "set", "clear"
is not very clear. We'll need to clarify this in future versions of
the document.
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
--------------------------------------------------------------------
