On 10/10/14 21:32, Ted Lemon wrote: > On Oct 10, 2014, at 3:03 PM, Tomek Mrugalski > <[email protected]> wrote: >> This option follows behavior described in Sections 17.1.1 and >> 18.1.1 of RFC3315. Clients can insert those options with specific >> values as hints for the server. Depending on the server >> configuration and policy, it may accept or ignore the hints. Client >> MUST be able to process received values that are different than >> the hints it sent. > > What guidance would you give the client as to what hints to send? > How would you avoid having the server do the wrong thing with hints > based on stale data? This is why I think the "client hints" thing > in 3315 is a mistake. I simply don't see how you can support this > in any interoperable way. Supporting it at all is not likely to do > anything, because both sides have to support it, but if they do, > there's no way to predict whether it will actually work, because we A well defined protocol should leave certain aspects up to implementors. DHCPv6 already allows lots of leeway wrt to server policy. This is in my opinion another differentiating factor between implementations. It is certainly reasonable to imagine a server implementation that can be configured to provide a range for a value. If client doesn't send a hint, a default value is sent. If client sends a hint and it is within a range allowed by an administrator, then the server sends this requested value. Dibbler does that for lifetime, T1, T2 and couple other parameters. I suspect that ISC DHCP allows similar logic, as there are min-lease-time, default-lease-time and max-lease-time parameters.
> have never said _how_ it works. So I am against specifying it this > way; rather, this document should forbid the client sending it, so > that if a server that implements this mistake is used, nothing bad > will happen. Ooops, I read your mail too late. I just uploaded -09 couple minutes ago :( In my opinion there's no harm done with clients sending hints. Servers will likely ignore it, but in some specific deployments this is a mechanism that allows fine tuning. But I suppose that won't convince you, so I won't insist. In the next revision we'll replace this text with the one you proposed: This option has no meaning when sent from client to server. However, servers may take options sent by clients as a hint for what values to return, so clients MUST NOT send this option to servers. Sorry I missed it with -09 update. Tomek _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
