That won't affect my "Ready" review (since my questions have all been answered).
Brian On 12/10/2014 08:02, Tomek Mrugalski wrote: > 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
