[DNSOP] missing use case and problem statement for draft-woodworth-bulk-rr

Jim Reid <jim@rfc1035.com> Sat, 22 July 2017 18:59 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 D697B1318A8 for <dnsop@ietfa.amsl.com>; Sat, 22 Jul 2017 11:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 Jee71svRrVRv for <dnsop@ietfa.amsl.com>; Sat, 22 Jul 2017 11:59:37 -0700 (PDT)
Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D497212700F for <dnsop@ietf.org>; Sat, 22 Jul 2017 11:59:36 -0700 (PDT)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 0A6CC2421527; Sat, 22 Jul 2017 18:59:33 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <20170720152559.GD22702@laperouse.bortzmeyer.org>
Date: Sat, 22 Jul 2017 19:59:32 +0100
Cc: dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F388F80D-AFEA-4AA6-BB14-246C78B22E75@rfc1035.com>
References: <alpine.LRH.2.20.1707190347390.10419@ns0.nohats.ca> <20170719215749.2241.qmail@ary.lan> <20170720152559.GD22702@laperouse.bortzmeyer.org>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/97oX2oSe7HHpgMEIKMUFGx9PtkE>
Subject: [DNSOP] missing use case and problem statement for draft-woodworth-bulk-rr
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 22 Jul 2017 18:59:38 -0000

> On 20 Jul 2017, at 16:25, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
> 
> And DNSSEC is not the only case where we introduced RRtypes where you
> have to check your slaves to be sure they support it. There was also
> DNAME.
> 
> That's why I don't share the fears about BULK

BULK would be an RRtype which *by design* prevents another part of the DNS from working. That’s just wrong. Behaviour like that might be acceptable for a non-trivial protocol change like a new header bit or EDNS option (say). But a new RRtype? Really?

BTW, if there are cases where an ISP’s customers care about reverse DNS for their IPv6 addresses, what’s stopping those customer devices using dynamic update to provision their names or have the DHCP server do that for them? Why can’t the ISP's provisioning systems and tools spit out PTR records for the IP addresses which need this secret sauce?

It’s still not clear to me what problem is actually being fixed by BULK and why no other provisioning mechanism is applicable.

If the WG is to adopt this draft, I think there first has to be a clear problem statement backed by use cases. [Prettier log files doesn’t do it for me. YMMV.] That way, the WG will be able to decide how well the final version of the document addresses these requirement if/when it gets to WGLC.

Apologies for introducing a meaningful and relevant Subject: header.