Re: [DNSOP] Question regarding RFC 8499

Paul Vixie <paul@redbarn.org> Fri, 07 August 2020 07:49 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 157673A0CD2 for <dnsop@ietfa.amsl.com>; Fri, 7 Aug 2020 00:49:37 -0700 (PDT)
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, SPF_HELO_NONE=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 2mIxQFsY-VbX for <dnsop@ietfa.amsl.com>; Fri, 7 Aug 2020 00:49:34 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B7CA3A0CC9 for <dnsop@ietf.org>; Fri, 7 Aug 2020 00:49:34 -0700 (PDT)
Received: from linux-9daj.localnet (dhcp-161.access.rits.tisf.net [24.104.150.161]) (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 C0932C3F19; Fri, 7 Aug 2020 07:49:33 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: Evan Hunt <each@isc.org>
Cc: dnsop@ietf.org, Michael De Roover <ietf@nixmagic.com>
Date: Fri, 07 Aug 2020 07:49:32 +0000
Message-ID: <8406460.GrWiC6mHCb@linux-9daj>
Organization: none
In-Reply-To: <20200807041818.GA38652@isc.org>
References: <86c18e80-88ab-5503-f63c-f788766a2675@ghnou.su> <1725851.NVhN7QJb2C@linux-9daj> <20200807041818.GA38652@isc.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/llNCudEdRDcJBT0OnZhvBlMubB0>
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: Fri, 07 Aug 2020 07:49:37 -0000

On Friday, 7 August 2020 04:18:18 UTC Evan Hunt wrote:
> On Wed, Aug 05, 2020 at 01:04:22AM +0000, Paul Vixie wrote:
> > ...
> > 
> > what's your proposal?
> 
> As I said earlier, I think "primary" and "seconary" are well-enough
> understood concepts now that we can describe roles in a particular
> transaction with phrases like "acting as a primary" or "acting as a
> secondary" and get the point across without much difficulty. But if
> that's not acceptable, then maybe "transfer provider" and "transfer
> recipient"?

when we started, bind was using the words "primary" and "secondary" in its 
config file, and was documenting the phrases "primary server" and "secondary 
server" in its operations guide. confusion was common, because in those days 
recursion wasn't optional and shared a namespace with authority data. so we 
also had terms like "recursive server" and "authority server" in wide use.

virtually any semantically meaningful term that's applied to the transaction 
rather than to the zone or the server, is fine by me. including going back to 
"primary" and "secondary", which feels a bit like going through a time machine 
to go back to when i was 25 and tell my younger self "just leave things as 
alone, trust me."

-- 
Paul