Subject: RE: Server address assignment policies Re: [was: Temporary Addres s Solution]

From: [email-masked]
Date: Fri, 9 Mar 2001 10:27:46 -0600

Thomas,

> My take would be that the document should explain that how it assigns
> addresses is an important topic with interesting implications, and
> give suggestions on what a server should do. It might even make sense
> to recommend that server support a number of ways of assiging
> addresses (e.g., just use EUI-64 for interface ID, use random numbers,
> number sequentially starting at 1, etc.), with knobs in a config file
> for selecting which policy one wants.
> 
> Thomas
> 

Can you be more clear here.  I may have to push back hard on this
suggestion.

It has and always should be how any server implementation sets up its
database or configures how it assigns addresses is implementation specific.
I am highly confident all implementors will agree with me.   But I do not
think your asking us to do this?  

Another thing that you may be asking is a simple statement that a server
should support multiple address scenarios as an editorial comment.  If its
just an editorial comment you are suggesting I am fine with that.

But we cannot and should not mandate anything on the above in an IETF server
to client protocol.

I guess its not clear to me what your asking for here.

regards,
/jim

---

From: Thomas Narten <[email-masked]>
Date: Fri, 09 Mar 2001 11:36:18 -0500

Jim,

> think your asking us to do this?

I think it makes sense to ask the question whether it should just be
left to implementations (saying very little) or whether the WG thinks
it a good idea to describe some possible implementations (and when I
say implementations, I'm really saying behaviors on how addresses are
assigned, e.g., random vs sequential addresses vs. something
else). The WG might also think it good to not just describe the
possibilities but recommend those that a server (say) SHOULD provide.

I'd really like to get a perspective here from folks that are shipping
DHCPv4 servers today and whether this makes sense.

Also, I'm asking, not saying.

Thomas