On 12/20/15 1:31 PM, Paul Vixie wrote:
On Sunday, December 20, 2015 08:13:42 AM joel jaeggli wrote:
I think we dramatically better off, if we are willing to critically
consider the implications of proposals someplace and expose the record
of that, and I don't have a better location on offer then here.
i was not trying to stifle discussion. what a wg chair told me was that
the essence of a dnsop rfc was, "if you're trying to accomplish thing X,
here's one way to do it." sadly for me, because of the ietf's
imprimatur, such specifications will be used in industry as if they were
recommendations.
in the specific example of edns client subnet, i have previously
supplied extensive technical argument against the systemic costs of
expanding the Q-tuple in this way. those arguments did not find
consensus in the WG, and are not reflected in the draft. see also
"afasterinetnet.com".
the edns-client-subnet is a very specific edge case - it has
security/privacy issues, it's done poorly, and even the current authors
want to fix what is there.
In the shepherd document I wrote the following:
"There are security issues with this version, as raised by
various people. They are correct, and the intent is not to
correct the security flaws with this document, but to describe
how this option behaves currently. It is suggested a new
version will be worked on in a year which addresses the
security issues, and addresses other issues about this option."
While you are right that such specifications may be used in industry as
recommendations, having several large vendors deploying something has
the same effect. My current employer was convinced that client-subnet
was already a 'standard' and wanted to know why didn't everyone support
it. Educating employers have always been the rock some of us push
uphill every day.
tim
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
