Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

"Ralf Weber" <> Wed, 21 December 2016 06:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2989312947E for <>; Tue, 20 Dec 2016 22:26:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OMGcIvOa-jkz for <>; Tue, 20 Dec 2016 22:26:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E7099127058 for <>; Tue, 20 Dec 2016 22:19:38 -0800 (PST)
Received: by (Postfix, from userid 107) id 2ED275F404CD; Wed, 21 Dec 2016 07:19:38 +0100 (CET)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 759185F402AD; Wed, 21 Dec 2016 07:19:35 +0100 (CET)
From: Ralf Weber <>
To: Paul Hoffman <>
Date: Wed, 21 Dec 2016 07:19:34 +0100
Message-ID: <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.6r5318)
Archived-At: <>
Cc: dnsop <>
Subject: Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Dec 2016 06:26:09 -0000


On 20 Dec 2016, at 17:33, Paul Hoffman wrote:

> On 20 Dec 2016, at 7:16, tjw ietf wrote:
>> Please review this draft to see if you think it is suitable for 
>> adoption by
>> DNSOP, and comments to the list, clearly stating your view.
> The draft itself is really not suitable for adoption by the WG. Just 
> slapping "Informational" on the document is insufficient for 
> preventing a lot of wasted effort by the WG in removing the parts of 
> the document that promote the practices described.
Other then in section 1, I didn't see this. However your response is yet 
examples why we don't have operator participation in the IETF though we 
say that we want it.

I've talked to lots of operators of recursive DNS servers and nearly all 
of them
have some form of DNS blocking/redirection, yet whenever this comes up 
in the
IETF sometimes even from operators (draft-livingood-dns-redirect) we 
look the
other way and say this does/should not exist.

Well it does and if the IETF wants to be relevant to those operators it 
would be
good if we had documents describing this, so they could be used as 

And while I don't like yet another draft that encodes something in DNS 
data that
was not meant to be DNS data I have to agree that this draft is relevant 
this working group and given that we have already multiple 
implementations of
it I think that the draft is something the working group should adopt.

So long