Thanks for your review, Brian. Happy to hear that questions have been answered. At this point I have no objection to publishing the doc…
Jari On 11 Oct 2014, at 12:07, Brian E Carpenter <[email protected]> wrote: > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
