[DNSOP] Role of informational RFCs Re: DNSOP Call for Adoption draft-vixie-dns-rpz

Suzanne Woolf <suzworldwide@gmail.com> Wed, 21 December 2016 15:04 UTC

Return-Path: <suzworldwide@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2E5EB129511 for <dnsop@ietfa.amsl.com>; Wed, 21 Dec 2016 07:04:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id o3fntQVEYsvZ for <dnsop@ietfa.amsl.com>; Wed, 21 Dec 2016 07:04:42 -0800 (PST)
Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5800129456 for <dnsop@ietf.org>; Wed, 21 Dec 2016 07:04:41 -0800 (PST)
Received: by mail-qk0-x241.google.com with SMTP id n21so9066806qka.0 for <dnsop@ietf.org>; Wed, 21 Dec 2016 07:04:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jgkUohtZRwQ+egfV7HBcV1l6+qrc6TST29/m9AlKJ/Y=; b=Jzo7gvTiWUrhbug15jnZ+0ZV3Wc65NCsu9lkD+WRevUbWGBeH8EM5sFMm2ytMGtjRj HiPS2rXowYxBGN7eXRbop9VAl9P1KHsfmxqBVepGxr3vVvs7DvUbg8OLg3mGV574LwrC e1/y533EZ4/8TY/J27Aw1bgNLj3wlUGNzwmk4ysfuOxSkhFIHTzVqm+dgO2M465yIC2A dLztcanO7TUS3JcG4tB8qVeHnE1dYrQjRrM9PDI428Q3qEaXfWW4SU5FBbdeb7cXjmAq zMiKa3XKZBI7hruV5B4fexjgkS09yvFfaZLtbd54XfSsB6T3JBRY2sgAW6Ls8QX/vv5t x/4A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=jgkUohtZRwQ+egfV7HBcV1l6+qrc6TST29/m9AlKJ/Y=; b=QT9ka4n4Olt1nTD5djgKPR2lSAMjHP33y+qbB5vjFdKCLGpKC/Lp0ivvDXGrtwdpLW 36IzeVQ8ZExdp1lpbYpMlEOr+t25WdFX8Jffxwyrdn1eLNdRQ+TeE6AoT3U+2iQSwfmv iZt/g092C++ErBv5Jb9qoqA/4tKYbxLw4t4Wuz16zsLyj4mh9Zn+GN7RpAO5OyItTLA1 APdxD/K6i29yHD6aV0udj+bxmakhsfkQSS6D8gAnTkU2jAXZCgr2dof6Ugi+DM91pTQ9 T6FjUjrjIeEWK9Wg6gLRjZye16xbPwusgHfHDqHjijAhDuK9SLiy1lEVL9eeuz36hqGN T9PQ==
X-Gm-Message-State: AIkVDXJyjxwj4/mOXx/P3N9hvyt64nHcGe3EcwpABb3b8cgnfwwDcgBfVktdTTE7rdbW6A==
X-Received: by with SMTP id k21mr5148237qkk.252.1482332680668; Wed, 21 Dec 2016 07:04:40 -0800 (PST)
Received: from [] (c-24-63-89-87.hsd1.ma.comcast.net. []) by smtp.gmail.com with ESMTPSA id p47sm1382131qtc.25.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 21 Dec 2016 07:04:40 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Suzanne Woolf <suzworldwide@gmail.com>
In-Reply-To: <20161221071436.GD884@server.ds9a.nl>
Date: Wed, 21 Dec 2016 10:04:38 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <794D1A72-AC2A-4A47-869B-47BED9FA23A9@gmail.com>
References: <CADyWQ+ETSd199ok0fgh=PB=--hW7buPgSoCg22aK51Bk4xxBmw@mail.gmail.com> <C18E2D4E-EE89-4AF6-B4A0-FAD1A7A01B5E@vpnc.org> <8f78a52b-01ae-f529-a1ec-d7eb90fe94be@bellis.me.uk> <6EBB4C5C-E2D9-40B9-86B8-03614804282D@vpnc.org> <20161220174650.GA884@server.ds9a.nl> <E6401D03-04D9-4884-ABC7-022C2E763B0C@vpnc.org> <20161221071436.GD884@server.ds9a.nl>
To: bert hubert <bert.hubert@powerdns.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/0MaAlLpOE2zIatlEIucM4HeUAVQ>
Cc: dnsop@ietf.org, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: [DNSOP] Role of informational RFCs Re: DNSOP Call for Adoption draft-vixie-dns-rpz
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 21 Dec 2016 15:04:43 -0000


Just for clarity— no one is proposing standards track for this document; the intended status has been consistently discussed as “Informational”.

In discussing RPZ, as we’ve seen with other technology in the past, there’s a difference between “the consequences of having a controversial  technology in widespread use” and “given a controversial technology in widespread use, the consequences of having an RFC about it.”

As an IETF working group, DNSOP has a lot more to say about the latter than the former.

In the past, the WG has sometimes taken the position that there’s value in an informational document on a widely-used and interoperable protocol extension, even if the goal isn’t to make it part of the formal standard. RPZ seems to be such a technology, in that it’s widely deployed in the operational internet— an RFC is obviously neither necessary nor sufficient for that.

Users of such an informational RFC that’s separate from vendor documentation might include operators who want to deploy the feature responsibly, new implementers who need a reference on how to make new code interoperable, and operators who want to avoid use of a feature or simply understand its impact on their environment.

If the question is “Does the existence of an Informational RFC mean the IETF is endorsing or promoting a technology or practice?” the answer is “No."

If the question is “Does the existence of an Informational RFC mean people will think the IETF is endorsing or promoting a technology or practice, and are they more likely to use it as a result?” the answer is pretty subjective and tends to be “It depends”— on the technology, on whether the document includes warnings about shortcomings and side effects, and on the forces that got the technology invented and deployed in the first place.


> On Dec 21, 2016, at 2:14 AM, bert hubert <bert.hubert@powerdns.com> wrote:
> On Tue, Dec 20, 2016 at 10:46:40AM -0800, Paul Hoffman wrote:
>>> Unbound is also slated to have support for RPZ.
>> Unbound can document it or point to the ISC documentation.
> We might as well stop doing standards all together then. We have something
> that works. It interoperates. There is an ecosystem of services around it.
> And what do people say? "Not going to standardize it".
> The thing is, RPZ is not actually something that was slapped together. It
> makes sense. Vernon and Paul clearly were on to something when they wrote
> it.
> In other words, it is not "documenting a configuration file". It is a great
> thing to be able to point to and say this is the standard, this is how we do
> things.
> But meanwhile I will now use TCP/IP to send this message, without having to
> refer to some old BSD documentation.
> 	Bert
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop