(Sorry for being too late response) I am really not sure why this thread is moved to *meta thought*. When I wrote this document, I originally thought this task was our explicit consensus to be a seperated document from 2462bis. Am I missing anything ? I don't think so.
See below link (October 2004) http://www1.ietf.org/mail-archive/web/ipv6/current/msg03799.html It would have been nice if you said your comment at that time. As you mentiond, simplicity is also good aspect and we (all author) was trying to make this document as simple as we can. If we feel it so heavy, we will make it more concise than now. --------------------------------------------- Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Thomas Narten > Sent: Saturday, May 21, 2005 2:24 AM > To: ipv6@ietf.org > Subject: meta thoughts on m/o bits > > > Stepping up a level (and this also reflects my thinking after a > private exchange with Ralph/Bernie - but not necessarily their > thinking!)... > > I think the M/O bits (in retrospect) have turned out to be more > trouble than they are worth. Indeed, they seem to be mostly just > confusing. Thus, maybe we should work towards removing them > completely. > > In an ideal world, there would be exactly one way for a client to > invoke DHC. That is, it would use the same message exchange to get > "addresses" as it did for "non-address configuration". In such a > world, there would be no need for the M/O bits, since the client would > do the same thing if either one of them were set. > > Unfortunately, we are not quite there, since DHC actually has HCB & > ICB message exchanges (using Ralph's terminology). Thus, there are > scenarios where invoking ICB is preferable over HCB. (Aside note: here > is another example where having two ways to do similar things, results > in undesirable complexity). Currently, we sort of need the M/O bits so > a client can know which variant of DHC to invoke. But, we now also > allow for the possibility of "silly states", i.e., states that aren't > supposed to happen, but can, e.g., through misconfiguration. Having > the M bit set but no addresses available is one such example. > > Ralph has already indicated that with some small changes to the DHC > spec, we might be able to fix the DHC issue so that there is one way > to invoke DHC that does the right thing in all combinations of > addresses and/or other configuration information being available via > DHC. > > If we had that, we wouldn't need two RA bits anymore. At most, a > single "there is stuff to obtain via DHC" bit would suffice. > > Indeed, one could go further and say "just always invoke DHC", and > don't even bother with an RA bit saying DHC is available. That has the > nice property of being simple to implement and you don't have silly > states where the RA bit(s) are configured incorrectly, etc. > > The only advantage I can see right off to having at least 1 RA bit is > to tell the client "there is no DHC server running, so don't even > bother". This would be a performance optimization to allow one to > avoid needing to invoke DHC and have it timeout -- before concluding > that there are no DHC servers. Is this a significant optimization? > Hard to say. > > What I would like to suggest: followup on the above proposed DHC > changes and see if we can actually "fix" DHC to simplify what the > client has to do to invoke it. And if that works, do away with one or > both of the RA bits. > > Remember, simplicity is Good! > > Thomas > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
