Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt

Jim Reid <jim@rfc1035.com> Fri, 15 February 2019 09:34 UTC

Return-Path: <jim@rfc1035.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D148D1310D6 for <dnsop@ietfa.amsl.com>; Fri, 15 Feb 2019 01:34:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5h7ud2Q7PxA for <dnsop@ietfa.amsl.com>; Fri, 15 Feb 2019 01:34:20 -0800 (PST)
Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B3F513102A for <dnsop@ietf.org>; Fri, 15 Feb 2019 01:34:19 -0800 (PST)
Received: from wallace.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 71DEC24211EE; Fri, 15 Feb 2019 09:34:17 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <20190215090235.afz4x75j5dij2wo7@nic.fr>
Date: Fri, 15 Feb 2019 09:34:16 +0000
Cc: dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6168D7FB-3690-4398-A848-196D1EB414D3@rfc1035.com>
References: <154689301066.32204.17312124670782800354@ietfa.amsl.com> <20190214195125.nwbazwpk3rgrgxkf@sources.org> <CAHw9_iLeAwU8gskbhyd7OMPYEY68eCDocB9k6ezjUxYj=_WHRg@mail.gmail.com> <20190215090235.afz4x75j5dij2wo7@nic.fr>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/dferXxhENzTkySIBdM0Q-RjTmEQ>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-04.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Feb 2019 09:34:22 -0000


> On 15 Feb 2019, at 09:02, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
> 
> I really think it is important to make the difference between:
> 
> * I blocked your request because that's _my_ policy
> * I blocked your request because I'm compelled to do so, don't
>  complain, it would be useless.

Why? From the client's perspective, there's no effective difference between these. Their request was rejected for some policy reason and it doesn't really matter whose policy has been applied.

Besides in situations where blocking is being done because of someone else's say so, it's highly likely that the DNS operator will be subject to some sort of injunction which prevents them from disclosing that such blocking is taking place. Think warrant canaries.