On Sat, 31 Dec 2016, Ted Lemon wrote:
There is no _way_ to make it easier for said outside forces to pressure
providers. They have the force
of law on their side. What we do makes no difference in that arena. The
arena in which it _does_
make a difference is protecting people from losing their homes because they got
suckered by some malware
that got into their personal records on their computer.
IOW, the argument you are presenting has nothing to do with the choice that
faces us. If you want to
make the case for rpz being a bad thing, the argument you should be making
would have to show why
protecting people in this way is the wrong solution to the problem, and why
some other solution to the
problem (e.g., a blacklist in the browser) is less bad.
Can’t we have that conversation, instead of these repeated assertions about
things over which we have no
control?
Some of us tried that and were told "that's not how RPZ works, we are
not changing how RPZ works".
The only thing I asked for is tracability and accountability, but not
witholding DNSSEC information but by passing it along in a different
section so that:
- RPZ still works as it does now for existing users/providers
- In the future RPZ filtering cannot be used as an out-of-the-box
involuntary censorship tool.
- Accountability can be added by adding a different key of last
mile trust anchor.
I'm interested in hearing technical reasons why this change cannot be
done, and lacking those, I would hope the WG does not adopt this document
if the authors are unwilling to make the changes to facilitate this..
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
