Hi Zach; At the end of the day, we need to establish states in the network for the IPv6 address in use. In that regard we are stateful. And that is how I understand that the DHCP world means it.
Yet we require minimal to no pre-configuration in the network. In that we are stateless. And that is how I understand that 4862 means it. The core question is whether people will understand better what we are doing if we qualify it as stateless or stateful based on their more or less intuitive understanding of the words, or if we'll just create more embarrassment for ourselves. Considering that the term stateful was deemed highly confusing and removed from RFC 4862, I tend to think that in a fashion stateless is also confusing and could be removed from our text. But I will not fight either way. Pascal >-----Original Message----- >From: Zach Shelby [mailto:[email protected]] >Sent: vendredi 12 juin 2009 10:30 >To: Pascal Thubert (pthubert) >Cc: Ralph Droms (rdroms); [email protected] >Subject: Re: [6lowpan] [Fwd: New Version Notificationfor draft-ietf-6lowpan-nd-03] > >Hi, > >Pascal Thubert (pthubert) wrote: >> Hi Jonathan: >> >>> On Jun 11, 2009, at 5:53 AM, Pascal Thubert (pthubert) wrote: >>>> Looks so alike and still is so fundamentally different. Ralph >>>> explained >>>> that in SFO a lot better than I can ever do but that has to do with >>>> the >>>> model below. >>>> >>>> In DHCP, the server owns the address and lends it away. You have to >>>> get >>>> back to that server to renew the binding. In whiteboard, the nodes >>>> owns >>>> the address and registers it where it wants, or anywhere (anycast). >>>> >>>> When we do SeND, that distinction might blur quite a bit but still, >>>> the >>>> white board acts on behalf of the node so it does not hold any master >>>> state (like a pool with LRI etc...) after the node is gone. >>> Hi Pascal, >>> >>> If Ralph could reiterate what he said at the WG meeting on the ML, >>> that would certainly help my understanding of the fundamental >>> difference between DHCP and whiteboard. >>> >>> At least in my mental model, the whiteboard is authoritative in what >>> nodes can use what address. The node MUST periodically renew the >>> binding with the whiteboard. The node cannot use that address when the >>> binding expires without renewal because the whiteboard could then >>> allow another node to use that same address. Whether or not we view >>> the node as "owning" the address is a non-issue for me. Functionally, >>> the whiteboard is authoritative and that's not unlike DHCP. >> >> Seems my words failed to convey the message and I hope Ralph will >> express that better. >> >> The key in my mind is that the owner is the node, and the whiteboard is >> just an attorney. >> Though he is the one who speaks during trial, the attorney can only say >> what his client agreed upon. >> And the client might switch attorney at will. >> >> With stateful DHCP, the server plays is like a chess player that places >> and controls its pawns at will. >> So the model is reversed. > >This is also my understanding. > >>> Also, in various places in the ND draft, we say *stateless* address >>> autoconfiguration - when in fact this is not the case. The whiteboard >>> maintains necessary state for all nodes in the network no matter how >>> you spin it. If that state does not exist, is not maintained properly, >>> or cannot be reached by the client node, DAD using the whiteboard will >>> fail. At the very least, I think we should drop the word "stateless" >>> everywhere in the draft. >> >> I think you're very right, that's an excellent point. > >I don't agree completely. The node is creating an address using >Stateless Address Autoconfiguration (RFC4862), we are not breaking that. >So in Section 5.2, where we are forming addresses, this is used correctly. > >The only thing we are changing, is the mechanism to perform DAD. > >I agree that the Whiteboard is not stateless, but it also does not start >with any state, nor does it require configuration from an administrator. >It is a blank slate.. > >> Stateful in the DHCP acceptance is certainly closer to what we are >> doing. >> >> Pascal > >-- >http://www.sensinode.com >http://zachshelby.org - My blog "On the Internet of Things" >Mobile: +358 40 7796297 > >Zach Shelby >Head of Research >Sensinode Ltd. >Kidekuja 2 >88610 Vuokatti, FINLAND > >This e-mail and all attached material are confidential and may contain >legally privileged information. If you are not the intended recipient, >please contact the sender and delete the e-mail from your system without >producing, distributing or retaining copies thereof. _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
