Re: [DNSOP] terminology: glue

Paul Hoffman <paul.hoffman@vpnc.org> Tue, 05 May 2015 15:00 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2391A015F for <dnsop@ietfa.amsl.com>; Tue, 5 May 2015 08:00:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level:
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 sh5nWGcdxDRf for <dnsop@ietfa.amsl.com>; Tue, 5 May 2015 08:00:31 -0700 (PDT)
Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7AB91A0161 for <dnsop@ietf.org>; Tue, 5 May 2015 08:00:25 -0700 (PDT)
Received: from [10.20.30.101] (50-1-98-218.dsl.dynamic.fusionbroadband.com [50.1.98.218]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t45F0GhE032129 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 May 2015 08:00:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: proper.com: Host 50-1-98-218.dsl.dynamic.fusionbroadband.com [50.1.98.218] claimed to be [10.20.30.101]
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <alpine.LSU.2.00.1505051535430.23307@hermes-1.csi.cam.ac.uk>
Date: Tue, 05 May 2015 08:00:15 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E8CCB3B-6EDC-495D-B21A-A9B382F44138@vpnc.org>
References: <CAEKtLiTq_OLY_aPqdntwHCQV0m64T=1wuDNRbtnLGi01bb90qw@mail.gmail.com> <alpine.LSU.2.00.1505051535430.23307@hermes-1.csi.cam.ac.uk>
To: Tony Finch <dot@dotat.at>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/NIoM2e6xTbqwZv-1XDdADWqpXVQ>
Cc: dnsop WG <dnsop@ietf.org>, Casey Deccio <casey@deccio.net>
Subject: Re: [DNSOP] terminology: glue
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 05 May 2015 15:00:34 -0000

On May 5, 2015, at 7:45 AM, Tony Finch <dot@dotat.at> wrote:
> 
> Casey Deccio <casey@deccio.net> wrote:
>> 
>> Glue records -- "[Records] which are not part of the
>>   authoritative data [for a zone], and are address resource records for
>>   the servers [in a subzone].  These RRs are only necessary if the name
>>   server's name is 'below' the cut, and are only used as part of a
>>   referral response."  Without glue "we could be faced with the situation
>>   where the NS RRs tell us that in order to learn a name server's
>>   address, we should contact the server using the address we wish to
>>   learn." (Definition from RFC 1034, section 4.2.1)
>> 
>>   A later definition is that glue "includes any record in a zone file
>>   that is not properly part of that zone, including nameserver records
>>   of delegated sub-zones (NS records), address records that accompany
>>   those NS records (A, AAAA, etc), and any other stray data that might
>>   appear" ([RFC2181], section 5.4.1).  Although glue is sometimes used
>>   today with this wider definition in mind, the context surrounding the
>>   RFC 2181 definition suggests it is intended to apply to the use of glue
>>   within document itself and not necessarily beyond.
> 
> I like this wording.

Seems OK to me, and I like the fact that it keeps puts the quotations in context. Are there any objections?

> Re "other stray data", can we conclude if it includes or excludes
> occluded records (as in RFC 6672 section 5.2 and RFC 2136 paragraph 7.18)?

I propose that we don't try to over-analyze RFC 2181 here, given that we are using the RFC 1034 definition as the more important one.

--Paul Hoffman