Re: [DNSOP] Question regarding RFC 8499

Martin Hoffmann <martin@opennetlabs.com> Fri, 24 July 2020 09:29 UTC

Return-Path: <martin@opennetlabs.com>
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 6FAD33A0DB9 for <dnsop@ietfa.amsl.com>; Fri, 24 Jul 2020 02:29:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 i2aXMqJdRIRm for <dnsop@ietfa.amsl.com>; Fri, 24 Jul 2020 02:29:00 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 B54173A0DB5 for <dnsop@ietf.org>; Fri, 24 Jul 2020 02:29:00 -0700 (PDT)
Received: from grisu.home.partim.org (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id C8D7C33FDF; Fri, 24 Jul 2020 11:28:56 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com
Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com
Date: Fri, 24 Jul 2020 11:28:56 +0200
From: Martin Hoffmann <martin@opennetlabs.com>
To: Paul Vixie <paul@redbarn.org>
Cc: Joe Abley <jabley@hopcount.ca>, dnsop@ietf.org, Evan Hunt <each@isc.org>, Robert Edmonds <edmonds@mycre.ws>
Message-ID: <20200724112856.31e31e96@grisu.home.partim.org>
In-Reply-To: <2141383.qLNa8zf0Xv@linux-9daj>
References: <86c18e80-88ab-5503-f63c-f788766a2675@ghnou.su> <1C6ACEA9-CCC5-41F5-AEAD-432B48370D12@hopcount.ca> <20200723183407.GB34140@isc.org> <2141383.qLNa8zf0Xv@linux-9daj>
Organization: Open Netlabs
X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_W6tba7EF6GQsF1k2tRgRDmVLtc>
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, 24 Jul 2020 09:29:02 -0000

Paul Vixie wrote:
> On Thursday, 23 July 2020 18:34:07 UTC Evan Hunt wrote:  
> > 
> > I share the desire for perfection, but IMHO the transition from
> > "master" to "primary" and "slave" to "secondary" is far enough
> > under way and well enough understood at this point that I suspect
> > it would be easier to add modifiers when necessary than to try to
> > deploy new vocabulary entirely.

I have to agree: Primary and secondary are now used fairly consistently
in software documentation. They are about as expressive and lacking in
precision as the previous terms.

> -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.

The problem with this is that the initiation of a transfer and data
flow are opposite which makes this all very confusing. Reading
"initiator" and "responder", I have to stop and think "Wait, how did
XFR work again?"

Whereas primary and secondary describe the data flow in a rather
natural way. If I hear these terms, I know immediately who has which
role in this particular exchange.

The terms may not be perfect and may not precisely describe any
possible arrangement of servers one can come up with, but unless we
switch to German-style descriptive terms, we’ll always fall short. And
those descriptive terms tend to then turn into acronyms which is a
straight road into undecipherable jargon.

Side note: Whenever using "upstream" and "downstream", I’ve pretty much
always first had a half-hour discussion what each means and still later
ran into issues a la "What was downstream again?"

Kind regards,
Martin