----- Original Message ----- From: <JINMEI Tatuya / [EMAIL PROTECTED]@C#:H (B <[EMAIL PROTECTED]>)> To: "Pekka Savola" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; "Soohong Daniel Park" <[EMAIL PROTECTED]> Sent: Tuesday, August 10, 2004 4:58 PM Subject: Re: comments on draft-daniel-ipv6-ra-mo-flags-00.txt
> 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. M/O flags indicate the avaialbility of the respective service, so if a router advertises the M/O flags bits ON, I think we should OFF them if and only if the same router advertises again to OFF. It is administartor problem if one advertises with bits ON, and other router with bits OFF. > > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
