Re: [DNSOP] Clarifying referrals (#35)

Tony Finch <dot@dotat.at> Thu, 30 November 2017 12:24 UTC

Return-Path: <dot@dotat.at>
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 D0B93126DFE for <dnsop@ietfa.amsl.com>; Thu, 30 Nov 2017 04:24:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 VLRdh6w9KTdh for <dnsop@ietfa.amsl.com>; Thu, 30 Nov 2017 04:24:16 -0800 (PST)
Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 8F43F12708C for <dnsop@ietf.org>; Thu, 30 Nov 2017 04:24:16 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:57546) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1eKNt0-000t0X-1L (Exim 4.89) (return-path <dot@dotat.at>); Thu, 30 Nov 2017 12:24:14 +0000
Date: Thu, 30 Nov 2017 12:24:14 +0000
From: Tony Finch <dot@dotat.at>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
cc: dnsop@ietf.org
In-Reply-To: <20171130015900.vtd2wf7kysibctbj@mx4.yitter.info>
Message-ID: <alpine.DEB.2.11.1711301202130.22895@grey.csi.cam.ac.uk>
References: <20171129014436.sx546yjwvobepnyp@mx4.yitter.info> <8E36C30A-A7BC-4908-BE06-6D2B8B469006@isc.org> <20171129015303.kthpahbi6w6m645d@mx4.yitter.info> <AE976F3F-0270-4484-BCE4-FE0E9BF9D03E@isc.org> <20171129020347.b3zq3rcwsubmrlhh@mx4.yitter.info> <476FF2A7-DB80-40B6-917A-2675497DD6FC@isc.org> <20171129121706.4zh4kgx3wmtucmpc@mx4.yitter.info> <CAKW6Ri4T1h0n2r-Zp5xUUvW4n+u4oFPww2SDRnqwQMBF_wjY0g@mail.gmail.com> <8CA9C8EB-F117-4797-810F-DEF047F110BB@dotat.at> <F0D18DF2-1037-4BBA-B111-4D089E5E445F@dotat.at> <20171130015900.vtd2wf7kysibctbj@mx4.yitter.info>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1870870841-1564930901-1512044654=:22895"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/mKIq2k48Oz-2gRMBl6ygZyI2aRI>
Subject: Re: [DNSOP] Clarifying referrals (#35)
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: Thu, 30 Nov 2017 12:24:20 -0000

Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
>
> I think that's correct.  But what is not plain to me in my reading,
> insistent noises on the list notwithstanding, is whether the second ¶
> in step 3.b of the algorithm in section 4.3.2 of RFC 1034 is still
> part of what "a referral" means.  The ordinary English meaning, as far
> as I can tell, of that 3.b subsection is that everything one does as
> part of step 3.b is a referral response.

Yes. ¶2 tells you how to construct a referral.

> The problem is that "Go to step 4" is part of that last ¶, not a new
> ¶, and so what I think is obscure in the algorithm text is whether the
> stuff you're copying into the response in step 4.

I think you're missing a word or two here :-) but the key part of step 4
wrt referrals is "If there was no delegation from authoritative data",
i.e. if we already have a referral, don't overwrite it.

The "go to step 4" is a switch from serving authoritative data to
gossiping cached data, when the auth data can only provide part of the
answer. (There's also more gossiping in step 6.)

> It's at least as likely that such a reader will conclude that RFCs 1034
> and 1035 are written with a certain lack of terminological rigour --
> which is perhaps borne out by the effort we apparently need to make to
> clarify a term as fundamental as "referral".

It seems to me that these RFCs were written with a great deal of care, but
their informality makes them appear less precise than they are - you have
to read between the lines to work out the implicit meanings of the
technical terms. But I don't think the terms are used inconsistently.

> I don't think anyone in this discussion disagrees about how things
> _ought_ to operate.  But in the terminology document, I think we have
> tried to preserve the meanings that persist on the Internet.

I think it's worth being precriptive, but carefully. That is, telling
readers of the terminology RFC that if they are using a term precisely in
a document they are writing, they should only use it with the preferred
meaning - but some people use it with these different meanings so readers
need to be aware of these variations.

e.g. for referrals, saying something like "the term referral is sometimes
used in a way that also covers implicit referrals and upward referrals
(qv) but precise writing should only use referral to mean a downward
referral from authoritative data".

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Fitzroy, Sole: Northerly or northeasterly 5 or 6, occasionally 7 in east.
Moderate or rough. Showers. Good.