Re: [DNSOP] Question regarding RFC 8499

Joe Abley <jabley@hopcount.ca> Thu, 23 July 2020 17:39 UTC

Return-Path: <jabley@hopcount.ca>
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 5D4833A0C9C for <dnsop@ietfa.amsl.com>; Thu, 23 Jul 2020 10:39:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 WecD2W8DQIQL for <dnsop@ietfa.amsl.com>; Thu, 23 Jul 2020 10:39:02 -0700 (PDT)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41A893A0C9B for <dnsop@ietf.org>; Thu, 23 Jul 2020 10:39:02 -0700 (PDT)
Received: by mail-qt1-x82d.google.com with SMTP id t23so1891973qto.3 for <dnsop@ietf.org>; Thu, 23 Jul 2020 10:39:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HPqFZDGHASuUcEyWTFabEm/gANI6tjoH6XAatjb8cMk=; b=OTh+PwmGGa5uMK5DsOgotyKOV3Du7xPXtLBwtmYvZkRWRQB/JwH7anFms3fgs4AyFj Yi7PU8Pjo90USe5UYJo1Igd5utpBcmOL6CvvHDZlBjUvdsXab1q0S/DdhfR+sL00m3C0 +P8U91hJ4qPHjOgwRaG7o4fMo+Yv4FAXtmQzI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HPqFZDGHASuUcEyWTFabEm/gANI6tjoH6XAatjb8cMk=; b=izQOEBwd3eeTgb/OD5LuYgc3izGUWU4pKHRQt/M0xBPS3gKKA/buX3otpnMD7vBgrc EdIssqiyJPaxDyQRjb2yuWinZs8jks+CS49FhIOQc4NpDT3KZGJYeFHDFvTycZaFeIJq Z/5bKaei9vdx661tskmpJ4inRSJbsr68Mjvdz2YpYTKzy4OV/hFgUXaN3LNy+lBc/wgP pUurER/TXWvkA334+urxHN7FDGSUCpLYycdZ5GnIF0R0dBFXHoXy+gudqLMkGDKtf9SB Kdpb2yKn5IgYBArB+W4KaUNTtGfG1UVozcihYPSXFkHk6+VaR3xxNcuWtGEOZpWSQ3Tw +a8A==
X-Gm-Message-State: AOAM530xifqZxwrinIvPifJuR4wKvzs+x3NkyLH1ZvxGm3lMyh1lJwOB jo7j+a2m8EbB6nGUTr5rB8LuUknx3GOHaQ==
X-Google-Smtp-Source: ABdhPJxQg9gccfN8Ttcd4lvGKiJ2p3GkDhOttTodaLcL6o5nZzo6wOx3Ok/YVZ+1hryDxSqWkUzA0w==
X-Received: by 2002:ac8:4b47:: with SMTP id e7mr5603182qts.242.1595525941070; Thu, 23 Jul 2020 10:39:01 -0700 (PDT)
Received: from [192.168.1.149] (24-246-23-138.cable.teksavvy.com. [24.246.23.138]) by smtp.gmail.com with ESMTPSA id x24sm3399848qtj.8.2020.07.23.10.38.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Jul 2020 10:39:00 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <20200723172449.GA371024@mycre.ws>
Date: Thu, 23 Jul 2020 13:38:58 -0400
Cc: dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1C6ACEA9-CCC5-41F5-AEAD-432B48370D12@hopcount.ca>
References: <86c18e80-88ab-5503-f63c-f788766a2675@ghnou.su> <20200723172449.GA371024@mycre.ws>
To: Robert Edmonds <edmonds@mycre.ws>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/KhIsLifITQ9WedV9p1W1bDGGnl4>
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 17:39:03 -0000

On 23 Jul 2020, at 13:24, Robert Edmonds <edmonds@mycre.ws> wrote:

> Michael De Roover wrote:
>> Regarding the primary and secondary servers, it's a fair euphemism but this
>> among further fracturing of nomenclature in other projects makes this
>> definition very fragmented (master/slave is now primary/secondary, main,
>> parent/child, etc). This is something I find unnecessary and harmful, as it
>> creates confusion while merely redefining the same.
> 
> "Primary" and "secondary" are not euphemisms or later re-definitions.
> They appear extensively throughout STD 13 and appear to be the preferred
> nomenclature, e.g. in the below description of zone transfers from RFC
> 1034. "Slave" does not appear anywhere in STD 13 to the best of my
> knowledge; the closest reference is to "non-master" servers.

I don't think primary/secondary are exact substitutes for master/slave in the way that those four terms are commonly used today.

STD 13 assumes a model where there is a single authoritative nameserver which acts as a source of truth for zone data ("primary"), from which other nameservers retrieve data and also make it available ("secondary"). As such they describe the whole of a simple directed graph of zone transfers.

In my experience, in common usage today, master and slave describe functions along a single edge of such a graph. A single piece of software might act as a master server on one edge, and a slave on another. As such those terms can be used to describe more complicated graphs than the particular topology imagined in STD 13.

Adding further complication, there are many deployments in which there is no single "primary" source of data as far as the zone transfer graph is concerned; the source of truth might be a different type of database altogether with its own replication schemes, and the zone transfer graph might distribute data from two or more known-consistent zone transfer sources.

I do appreciate that STD 13 mentions "master" in some cases as a synonym for "primary"; however, it doesn't mention them in a couple with "slave" and I think this is an example of where low-numbered RFCs sometimes need to be read in their historical context rather than with slavish (ho ho) devotion to individual words. I realise that RFC 8499 does the same. I think common usage is usefully different, however (e.g. see various implementations' configuration syntax).

If we are looking for alternative terminology to master/slave (which I am not against, because change is a constant and inclusiveness and awareness amongst all industries is surely to be supported and encouraged) in my opinion we should find new words and not redefine or overload the common meaning of primary and secondary.


Joe