IETF Logo Mail Archive

Re: [DNSOP] BULK RR as optional feature

"John R Levine" <johnl@taugh.com> Tue, 28 March 2017 21:23 UTC

Return-Path: <johnl@taugh.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 594CE129637 for <dnsop@ietfa.amsl.com>; Tue, 28 Mar 2017 14:23:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=FSwzYtnu; dkim=pass (1536-bit key) header.d=taugh.com header.b=ePzY0NIZ
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 zRO_6DkmiAQN for <dnsop@ietfa.amsl.com>; Tue, 28 Mar 2017 14:23:18 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F7C7129689 for <dnsop@ietf.org>; Tue, 28 Mar 2017 14:23:16 -0700 (PDT)
Received: (qmail 40804 invoked from network); 28 Mar 2017 21:23:14 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9f62.58dad442.k1703; bh=sDChe/XW5r08zCEim6UVaQt8zIwBmTHYA3WUXblBl7A=; b=FSwzYtnu4G6KDSKY+BqsOdad1Cvt2MfbK3Ww9CyXyVPRMoG7SqAWsv94auXUr71f2F8YvW3dvFfQDZmProxg5rXWEZKoPS/jyxiDAyRFuHIiEF9Ciw13bGIaCQYrk93IkSCnNYU21T4YL0C/i6ZC9qpr3r2/1lGpxWRgzsPBidYt+FAmY3TD11gPxRWEw79f9UMvqrVri60De0KJRZUOYc82/F/pzuOPwkWg0QflXLLNy/esXUgyruE0Bvomq9Ty
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=9f62.58dad442.k1703; bh=sDChe/XW5r08zCEim6UVaQt8zIwBmTHYA3WUXblBl7A=; b=ePzY0NIZ/OLsxE021BLiPQkviuqa48fkGMPU3RgfJ2Zs0i/pv0oCv5O0VKG9mGgBiVyCht1mEkNCYa+6kEdOW4CreXEMo3GPo2obuwxqZEG9tsDlUpFxRelpHHa6RE2nYMyhYrxYQxjUQ5nC3BcjQa33XlUa5JEutsKUxyS7dXKiWUoNs6BHXL1A4mczu+lOKL8zNuizYCNYqmgRE3G2h9dTCKZFusRqio38zoZcHsrzpvTvsb+r2tty8Yt/sljo
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 28 Mar 2017 21:23:14 -0000
Date: Tue, 28 Mar 2017 16:23:13 -0500
Message-ID: <alpine.OSX.2.20.1703281621310.4758@dhcp-80f1.meeting.ietf.org>
From: John R Levine <johnl@taugh.com>
To: Evan Hunt <each@isc.org>
Cc: dnsop@ietf.org
In-Reply-To: <20170328210548.GB23506@isc.org>
References: <20170328183156.2467.qmail@ary.lan> <20170328205151.GB23312@isc.org> <alpine.OSX.2.20.1703281554510.4584@dhcp-80f1.meeting.ietf.org> <20170328210548.GB23506@isc.org>
User-Agent: Alpine 2.20 (OSX 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nf8F6YfqkIblJPqsszumMpLkKWQ>
Subject: Re: [DNSOP] BULK RR as optional feature
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: Tue, 28 Mar 2017 21:23:20 -0000

>> That doesn't work -- this is intended to generate rDNS for IPv6 and other
>> places where you can't possibly store the full expansion.
>
> It doesn't work for that particular use case, no, but there are other
> benefits to BULK (the draft specifically mentions "the ability to transfer
> BULK RR intentions from primary to secondary nameservers with minimal
> bandwidth and memory requirements"), and a transition mechanism for
> secondaries that don't implement BULK would be a useful addition.

I don't see how it's a very useful transition mechanism.  The bit about 
transferring intentions from primary to secondary assumes the secondary 
understands the RR.  The use cases all seem to me to be stuff too big to 
do statically with generate.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

v2.23.0 | Report a Bug | By Email