Good points, all. One of the things I noted from the WG meeting was the desire to separate the different types of redirect into distinct I-Ds, which I plan to do. That should help avoid conflating what are very different sort of redirect in practice.
Thanks Jason On 7/28/09 5:02 AM, "Alissa Cooper" <[email protected]> wrote: > Reflecting on something Rob said in yesterday's meeting, I think the > way that choice is dealt with in draft-livingood-dns-redirect could be > improved. Whether subscribers are opting in to DNS redirection or not > obviously has a huge impact on how the practice is judged. > > In the current draft, the four flavors of redirect (web error, > malicious sites, legally mandated and content-based) are articulated > as somewhat comparable alternatives. But the last two are actually > qualitatively different from a choice perspective: it seems highly > unlikely that legally mandated redirection would be operated with any > choice mechanism at all, and based on the description of content-based > redirection, it seems to be describing a purely opt-in service. At the > same time, the requests that are subject to redirection in both of > those cases seem to be largely unbounded. A legal mandate could apply > to any URL (assuming legal authorities act arbitrarily), and a user > could choose to avoid any content. This is, by definition, not true > for the other two redirect flavors. > > I understand the desire to avoid discussing opt-in/opt-out mechanisms > in much detail, but it seems like the broader notion that something > users choose for themselves is less objectionable that something that > is chosen on their behalf should be stated up front. This would also > help distinguish legally mandated and content-based redirection (where > the type of choice offered is more or less implicit) from web error > and malicious sites (where the ISP has a decision to make about how > choice will be offered). > > Alissa > _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
