On 21.7.2015 10:55, Michael StJohns wrote: > On 7/21/2015 4:32 AM, David Conrad wrote: >> On Jul 21, 2015, at 9:07 AM, Michael StJohns <m...@nthpermutation.com> wrote: >>> The decision with respect to "clients ... would see some benefit..." has >>> to be based on what the servers know. >> Yes, and the information provided by the mechanism described by Warren's >> draft would provide at least some information to the servers as to state of >> the clients. > > And that's the point. It's not a benefit to the client. It's a benefit to > the server.
I oppose this. It is very much to benefit of the client to inform us that the client is not ready for roll-over. We may decide not to break it if we know that it is not ready. >>> Causing a client to emit something that isn't necessary to get the service >>> is generally considered a requirement for opt-in type of consideration. >> Do you disable "Software Update"-like probes on your operating system(s) and >> applications? > > On about half of them I disable things. I never, ever allow them to > automatically install software. But the key point is that I personally decide > whether or not to allow the software to send the probes in the first place - > e.g. OPT IN as I indicated above. I pretty much say "NO" to "do you want to > help us improve the product by sending blinded data" questions and I'm pretty > sure that's not an unusual approach for other IETF attendees. > > You cannot assume that every single new installation of modified client code > to do Warren's stuff will agree that sending the root this data is of use to > them, and they may not agree to enable the protocol. I pretty much believe > you need to give them the option to say no. This whole debate is about MUST vs. SHOULD (opt-in/out), is that right? -- Petr Spacek @ Red Hat _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
