Replacing master/slave terminology

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Replacing master/slave terminology

Nate Coraor
Hi all,

I'd like to propose that an effort be made to replace master/slave
terminology in MIT and Heimdal implementations at some future milestone. I
suspect this would be a fairly large undertaking, but hopefully it could be
done incrementally and in a largely backwards compatible way. For example,
ISC BIND now accepts "primary" and "secondary" as synonyms for "master" and
"slave" in configuration files and documentation.

I looked for a prior discussion on this, tracked issues/bugs, etc. but
didn't find anything, so I apologize if this has been brought up before. I
am aware that this has been a contentious issue with other projects and I
am certainly not trying to cause any disagreement, but avoiding these terms
is a small piece of fostering inclusivity in the world of free and open
source software. I know that "master" and "slave" are terms in long use in
computer science in general and Kerberos in specific, but their direct
connection to the institution of slavery should relegate their use where it
can be helped.

Thanks,
--nate
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Replacing master/slave terminology

Greg Hudson
On 6/10/20 3:48 PM, Nate Coraor wrote:
> I'd like to propose that an effort be made to replace master/slave
> terminology in MIT and Heimdal implementations at some future milestone.

MIT krb5 switched to using "replica" for non-primary KDCs as of release
1.17.  This was an easy change technically, as the old term was only
used in a user-visible way in documentation and in the name of one
profile relation.  The pull request for that change was here:
https://github.com/krb5/krb5/pull/851

Replacing the term "master" is a larger technical challenge.  We use
that term in a DNS SRV record label (_master_kdc), and migrating that
would come with a cost in network traffic and latency.  Aside from the
kprop architecture, we also use the term "master key" to describe the
key used to encrypt long-term keys in the KDC database.

I have rationalized to myself that the term "master" is the less
problematic of the two terms, as it is used in a lot of different
contexts (such as physical master keys, martial arts masters, master
plumbers, and master recordings of records).  But I don't know if that
rationalization is adequate; from recent discussion I know that git's
use of "master" for the initial default branch name has become a point
of contention.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Replacing master/slave terminology

Nate Coraor
On Wed, Jun 10, 2020 at 5:04 PM Greg Hudson <[hidden email]> wrote:

> MIT krb5 switched to using "replica" for non-primary KDCs as of release
> 1.17.  This was an easy change technically, as the old term was only
> used in a user-visible way in documentation and in the name of one
> profile relation.  The pull request for that change was here:
> https://github.com/krb5/krb5/pull/851


Hi Greg,

This is fantastic and encouraging news, thanks! I'm not sure how I missed
this. If I can find the time I'll see if it'd be as simple for Heimdal, or
perhaps someone from the Heimdal side will chime in. In specific, iprop
uses "slave" even more prominently than kprop did, I believe.


> Replacing the term "master" is a larger technical challenge.  We use
> that term in a DNS SRV record label (_master_kdc), and migrating that
> would come with a cost in network traffic and latency.  Aside from the
> kprop architecture, we also use the term "master key" to describe the
> key used to encrypt long-term keys in the KDC database.
>

Technical considerations are certainly factors. I wonder if it'd be
reasonable to allow clients to specify a preference when performing the SRV
record lookup?

I have rationalized to myself that the term "master" is the less
> problematic of the two terms, as it is used in a lot of different
> contexts (such as physical master keys, martial arts masters, master
> plumbers, and master recordings of records).  But I don't know if that
> rationalization is adequate; from recent discussion I know that git's
> use of "master" for the initial default branch name has become a point
> of contention.
>

I largely agree here, it's less problematic. I do think it'd be preferable
to refer to the "master" server as e.g. "primary", but master key seems
fine as it has an established unencumbered meaning.

Thanks,
--nate
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Replacing master/slave terminology

Jeffrey Altman-2
On 6/10/2020 5:26 PM, Nate Coraor ([hidden email]) wrote:

> On Wed, Jun 10, 2020 at 5:04 PM Greg Hudson <[hidden email]> wrote:
>
>> MIT krb5 switched to using "replica" for non-primary KDCs as of release
>> 1.17.  This was an easy change technically, as the old term was only
>> used in a user-visible way in documentation and in the name of one
>> profile relation.  The pull request for that change was here:
>> https://github.com/krb5/krb5/pull/851
>
>
> Hi Greg,
>
> This is fantastic and encouraging news, thanks! I'm not sure how I missed
> this. If I can find the time I'll see if it'd be as simple for Heimdal, or
> perhaps someone from the Heimdal side will chime in. In specific, iprop
> uses "slave" even more prominently than kprop did, I believe.
For Heimdal, the term "slave" is part of the both the iprop process name
and command line switches for the iprop_master.  Changing these could
adversely impact end user deployments that are not expecting their
configuration scripts and packaging to break.

>> Replacing the term "master" is a larger technical challenge.  We use
>> that term in a DNS SRV record label (_master_kdc), and migrating that
>> would come with a cost in network traffic and latency.  Aside from the
>> kprop architecture, we also use the term "master key" to describe the
>> key used to encrypt long-term keys in the KDC database.
>>

Changing the name in DNS SRV records is really untenable.  The impact on
end user organizations would be significant.  The support for master_kdc
lookups and configuration parsing could not be removed because doing so
would result in interop failures.  Likewise end user organizations would
be required to publish both the new record and the old.

> Technical considerations are certainly factors. I wonder if it'd be
> reasonable to allow clients to specify a preference when performing the SRV
> record lookup?

Not really.  It doesn't change anything other than adding a new
configuration option that must reference the "master_kdc" service name
in its documentation.

As a real world example, in 2011 the IETF deprecated the use of AFSDB
records in favor of SRV records for AFS services.  This was an official
standardization action that took more than a year to complete.  It has
been nearly a decade and by my most recent inventory nearly 2/3 of AFS
cells are still configured with AFSDB records and only 40% have SRV
records.  Approximately five percent support both.  As a result it has
been impossible to even consider removing the support for AFSDB records
and the additional delays that result from trying one and falling back
to the other.

> I have rationalized to myself that the term "master" is the less
>> problematic of the two terms, as it is used in a lot of different
>> contexts (such as physical master keys, martial arts masters, master
>> plumbers, and master recordings of records).  But I don't know if that
>> rationalization is adequate; from recent discussion I know that git's
>> use of "master" for the initial default branch name has become a point
>> of contention.
>>
> I largely agree here, it's less problematic. I do think it'd be preferable
> to refer to the "master" server as e.g. "primary", but master key seems
> fine as it has an established unencumbered meaning.
The term "master" applies to the database not the server.   The question
is whether or not the answer to a query is definitive.  All of the KDCs
can serve data from the "master" database.   The client needs to know
that it should retry against another server when it can determine that
the database isn't a "master" as a noun; its "master" as an adjective.
Where the use of "master" indicates being an expert, principal or
instructor.

Heimdal's documentation should be rewritten to remove the master-slave
relationship.  If and when there is ever a volunteer to perform that
work along with all of the other changes that Heimdal's documentation
requires I will happily merge the pull request.

Jeffrey Altman




________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Replacing master/slave terminology

Nate Coraor
On Wed, Jun 10, 2020 at 8:01 PM Jeffrey Altman <[hidden email]>
wrote:

> For Heimdal, the term "slave" is part of the both the iprop process name
> and command line switches for the iprop_master.  Changing these could
> adversely impact end user deployments that are not expecting their
> configuration scripts and packaging to break.
>

People installing by hand aside, isn't this more of a vendor packaging
issue? They deal with changes like this pretty regularly.

Can the switch to iprop_master can be deprecated but left in place, and
ipropd-slave linked to ipropd-replica and similarly deprecated?


> As a real world example, in 2011 the IETF deprecated the use of AFSDB
> records in favor of SRV records for AFS services.  This was an official
> standardization action that took more than a year to complete.  It has
> been nearly a decade and by my most recent inventory nearly 2/3 of AFS
> cells are still configured with AFSDB records and only 40% have SRV
> records.  Approximately five percent support both.  As a result it has
> been impossible to even consider removing the support for AFSDB records
> and the additional delays that result from trying one and falling back
> to the other.
>

I'm not suggesting removing support, simply for providing a path forward.

The term "master" applies to the database not the server.   The question
> is whether or not the answer to a query is definitive.  All of the KDCs
> can serve data from the "master" database.   The client needs to know
> that it should retry against another server when it can determine that
> the database isn't a "master" as a noun; its "master" as an adjective.
> Where the use of "master" indicates being an expert, principal or
> instructor.
>

This seems like reasonable framing to me.


> Heimdal's documentation should be rewritten to remove the master-slave
> relationship.  If and when there is ever a volunteer to perform that
> work along with all of the other changes that Heimdal's documentation
> requires I will happily merge the pull request.
>

I'm glad to hear that these changes will be accepted. I'll have a look and
see what the scope would be.

Thanks,
--nate
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos