Re: [DNSOP] Question regarding RFC 8499

Paul Vixie <paul@redbarn.org> Thu, 23 July 2020 21:28 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 472563A0E04 for <dnsop@ietfa.amsl.com>; Thu, 23 Jul 2020 14:28:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 6RC3B8zOtbkL for <dnsop@ietfa.amsl.com>; Thu, 23 Jul 2020 14:28:16 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33CD73A0D66 for <dnsop@ietf.org>; Thu, 23 Jul 2020 14:28:16 -0700 (PDT)
Received: from linux-9daj.localnet (dhcp-183.access.rits.tisf.net [24.104.150.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (1024 bits) server-digest SHA256) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id F0652C3F16; Thu, 23 Jul 2020 21:28:13 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: Tony Finch <dot@dotat.at>
Cc: Joe Abley <jabley@hopcount.ca>, dnsop WG <dnsop@ietf.org>, Evan Hunt <each@isc.org>, Robert Edmonds <edmonds@mycre.ws>
Date: Thu, 23 Jul 2020 21:28:13 +0000
Message-ID: <1689216.oKzlv0CYS6@linux-9daj>
Organization: none
In-Reply-To: <alpine.DEB.2.20.2007232059540.24797@grey.csi.cam.ac.uk>
References: <86c18e80-88ab-5503-f63c-f788766a2675@ghnou.su> <2141383.qLNa8zf0Xv@linux-9daj> <alpine.DEB.2.20.2007232059540.24797@grey.csi.cam.ac.uk>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4YKZQ00A0Tum_SkVSBuaeH7rBO0>
Subject: Re: [DNSOP] Question regarding RFC 8499
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 23 Jul 2020 21:28:17 -0000

On Thursday, 23 July 2020 20:10:49 UTC Tony Finch wrote:
> Paul Vixie <paul@redbarn.org> wrote:
> > that's why i've recommended we stop talking about "primary servers" or
> > "secondary servers", and instead talk about "transfer initiators" and
> > "transfer responders"
> 
> Agreed, except that if you include notify as part of the zone transfer
> machinery, the question of who is the initiator gets murky. (An upstream
> starts a zone transfer process by notifying a downstream that it might
> want to make a transfer request... who is taking the initiative here?)
> So I prefer upstream and downstream, to match the flow of zone data.

notify just accelerates the schedule of the next transfer, which begins with 
an SOA check. so the fact that the notify initiator is also the transfer 
initiator is interesting, but not confusing. upness and downness are 
subjective; initiation and response are not.

-- 
Paul