[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [rfc2462bis] relationship between M/O flags and related protocols

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: ipv6-admin@ietf.org [mailto:ipv6-admin@ietf.org] On 
> Behalf Of Erik Nordmark
> Sent: Wednesday, May 19, 2004 1:57 PM
> To: Christian Huitema
> Cc: Erik Nordmark; Ralph Droms; JINMEI Tatuya / 神明達哉; ipv6@ietf.org
> 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
> ipv6@ietf.org
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
> 
 D Šx x%bz)ڶ+Ezli
bzj)fjb?