Erik, Just checking. We do need the M bit for those wanting to use stateful? Or do you not agree?
thanks /jim > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Erik Nordmark > Sent: Wednesday, May 19, 2004 1:57 PM > To: Christian Huitema > Cc: Erik Nordmark; Ralph Droms; JINMEI Tatuya / çæéå; [EMAIL PROTECTED] > Subject: RE: [rfc2462bis] relationship between M/O flags and > related protocols > > > > I'm certainly not implying any API. > > > Why do you think the text with the forward reference to > "a separate > > > document" > > > implies any API? > > > > The forward reference is asking the implementers to manage an > > extraneous state variable. As far as ND is concerned, the > host can be > > entirely conformant and interoperate fine with others > without that state variable. > > So, the only reason for the state variable is to facilitate the > > implementation of something else than ND, which will use > the value of > > the state variable. For that you need some form of API. > > Christian, > > I'm confused. You had propopsed text which still had the > ManagedFlag in there. Your proposal was: > 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. > > 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. > > 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.) > > Erik > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [EMAIL PROTECTED] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > DÅ ûúÂäx ®©¨¥x%Ëb¦þ¢z×è®