IETF Logo Mail Archive

Re: [DNSOP] Clarifying referrals (#35)

P Vix <paul@redbarn.org> Wed, 29 November 2017 12:23 UTC

Return-Path: <paul@redbarn.org>
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 CFB7F1270AE for <dnsop@ietfa.amsl.com>; Wed, 29 Nov 2017 04:23:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-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 wAu62dAMsQHI for <dnsop@ietfa.amsl.com>; Wed, 29 Nov 2017 04:23:42 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB254120725 for <dnsop@ietf.org>; Wed, 29 Nov 2017 04:23:41 -0800 (PST)
Received: from [172.31.1.84] (unknown [222.128.198.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 7D54461FA2; Wed, 29 Nov 2017 12:23:40 +0000 (UTC)
Date: Wed, 29 Nov 2017 12:23:36 +0000
User-Agent: K-9 Mail for Android
In-Reply-To: <20171129122101.mv7zlc6kdqe3ojnv@mx4.yitter.info>
References: <20171112075445.tf2ut5dxzhhnqe7l@mx4.yitter.info> <20171128195025.ifzwsjk42wz7ard6@mx4.yitter.info> <5A1DEEE1.3070809@redbarn.org> <20171129014748.7rrm2tvwdnjdl6ss@mx4.yitter.info> <5A1E2491.9070805@redbarn.org> <20171129122101.mv7zlc6kdqe3ojnv@mx4.yitter.info>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----UHV3ITPJ7WHA9WWOMA1LHOAVPGGHMF"
Content-Transfer-Encoding: 7bit
To: dnsop@ietf.org, Andrew Sullivan <ajs@anvilwalrusden.com>
From: P Vix <paul@redbarn.org>
Message-ID: <13A36237-CA11-44F3-BA80-69302F7D14F9@redbarn.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/tHCi9Bfge7f-W2f3lck-98vroJE>
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: Wed, 29 Nov 2017 12:23:44 -0000

1034 cannot be reasonably read that way. I am asking for a clarification not a rule change. 

On November 29, 2017 8:21:01 PM GMT+08:00, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
>On Tue, Nov 28, 2017 at 07:08:01PM -0800, Paul Vixie wrote:
>> that's fatally unclear.
>
>So I gather :)
>
>> then the thing to say would be "a referral should always be downward,
>and if
>> a non-downward referral is received, it should be treated as a
>network data
>> configuration error".
>
>No, that is attempting to define away other kinds of referrals, which
>is precisely the discussion we were previously having (and why Joe and
>I wrote that other draft).  The terminology draft should not, in my
>opinion, attempt to change any RFC; and, IMO, 1034 defines referrals
>in such a way that someone _could_ think that upward referrals are
>sometimes a normal part of operation.  If we want to change the advice
>of what to do there, I think a different document is needed.
>
>Best regards,
>
>A
>
>-- 
>Andrew Sullivan
>ajs@anvilwalrusden.com
>
>_______________________________________________
>DNSOP mailing list
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

v2.29.0 | Report a Bug | By Email | System Status