Re: [DNSOP] Question regarding RFC 8499

Evan Hunt <each@isc.org> Thu, 23 July 2020 21:31 UTC

Return-Path: <each@isc.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 6A46D3A0E13 for <dnsop@ietfa.amsl.com>; Thu, 23 Jul 2020 14:31:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 OGrUQ-KeF1xf for <dnsop@ietfa.amsl.com>; Thu, 23 Jul 2020 14:31:53 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 0157A3A0E0B for <dnsop@ietf.org>; Thu, 23 Jul 2020 14:31:52 -0700 (PDT)
Received: from bikeshed.isc.org (unknown [IPv6:2001:4f8:1:f::88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 5A6A13AB006; Thu, 23 Jul 2020 21:31:49 +0000 (UTC)
Received: by bikeshed.isc.org (Postfix, from userid 10292) id 4D27D4442E; Thu, 23 Jul 2020 21:31:49 +0000 (UTC)
Date: Thu, 23 Jul 2020 21:31:49 +0000
From: Evan Hunt <each@isc.org>
To: Paul Vixie <paul@redbarn.org>
Cc: Joe Abley <jabley@hopcount.ca>, dnsop@ietf.org, Robert Edmonds <edmonds@mycre.ws>
Message-ID: <20200723213149.GD34140@isc.org>
References: <86c18e80-88ab-5503-f63c-f788766a2675@ghnou.su> <1C6ACEA9-CCC5-41F5-AEAD-432B48370D12@hopcount.ca> <20200723183407.GB34140@isc.org> <2141383.qLNa8zf0Xv@linux-9daj>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <2141383.qLNa8zf0Xv@linux-9daj>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/tmhHduKyOPRPS0Gb-7YCTKIv-Hk>
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:31:54 -0000

On Thu, Jul 23, 2020 at 07:40:25PM +0000, Paul Vixie wrote:
> -1. there are zones lacking primaries, and a secondary which can also
> talk to other secondaries gives a second role to those other secondaries.
> we must not simply revert to the STD 13 terminology. the role of an
> authority server depends on what zone we're talking about and what other
> server they're talking to. that's why i've recommended we stop talking
> about "primary servers" or "secondary servers", and instead talk about
> "transfer initiators" and "transfer responders", where the transfer
> pertains to a zone and the initiator or responder is a server's role with
> respect to that zone and that transfer.

I am visualizing a newly-hired and inexperienced administrator being
shown the ropes, and told:

- "this server is the master and that one is the slave",
- "this server is the primary and that one is the secondary", or
- "this server is the responder and that one is the initiator"

...and I think either of the first two versions would be clearer and
more informative to them than the third.

Within the specific context of discussing a zone transfer operation,
"initiator" and "responder" are clear enough, but in the broader context of
servers, service providers, and zone configurations, I don't see it as an
improvement.  (Come to think of it, even in that specific context, there's
potential confusion in the fact that a primary server could meaningfully be
said to "initiate" a transfer operation when it sends a NOTIFY.)

On the other hand, you can say "server A acts as primary for server B",
and it's fairly easy to understand even if technically neither one of
them is *the* primary.

-- 
Evan Hunt -- each@isc.org
Internet Systems Consortium, Inc.