On 23 Jul 2020, at 13:24, Robert Edmonds <edmo...@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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
