Re: [DNSOP] "anything goes" (was Re: Should we try to work on DNS over HTTP in dnsop?)

[Tim Wicinski <[e-mail]>]

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