On Friday, February 7, 2025 9:05:16 AM CET Bjørn Mork via bind-users wrote: > Personally I am mostly worried about the potentional number of technical > terms we have not yet identified as "bad". The set of words we may have > to replace in the future is virtually unlimited. Most colours are > obviously risky. So are any terms which could be used to describe a > person or body part. In any language if we're going to be translation > safe. > > Not sure where to draw the line. Are the 2024 rules final, or are we > going to continue this whack-a-mole game forever? > > > Bjørn
I think this is a very important question to raise. Where do we draw the line? Why were these changes made in the first place? And what's the purpose of context, if any? Earlier today I was playing around with an IDE44 to mSATA board for an old laptop of mine. It was supposed to replace the existing IDE44 to CF board that ran this laptop before. That last one had a jumper setting on it, that would determine whether it would be in master-slave or slave-master topology against another drive. In response to seeing that jumper, I could've jumped to the silly conclusion of slavery, or see it for what it really is: two drives that could be exactly the same, in a defined order. Context really matters here. The other day I had a conversation with ChatGPT, in a daily activity I like to think of as "interactive introspection". It's probably similar to what would normally be thought of as a diary. One of the subjects that were discussed, was the authority of lawmakers on technical matters, as opposed to the authority of technologists on lawmaking. One may well argue that neither deserves the authority to trespass on the other's field, without learning the precedent first. RFC 8499 in particular was made in 2019, during a social media frenzy. It would appear that it sought to appeal to the frenzy, more so than it sought to solve an actual problem. The perception of a solution is a powerful one. It is also entirely fake. During a debate I had on the DNSOP list at the time, Paul Vixie responded to me with an explanation as to what master/slave stood for when he assigned those terms. I'll quote it below. Capitalization is my own, otherwise it's quoted verbatim. > I introduced the master/slave terminology in RFC 2136, because I needed > names for the roles in an AXFR/IXFR transaction, and the zone transfer > hierarchy could be more than one layer deep, such that a server might > initiate some AXFR/IXFR's to the "primary master" but then respond to > AXFR/IXFR's from other servers. In retrospect I should have chosen the > terms, "transfer initiator" and "transfer responder". However, the > hydraulic brake and clutch systems in my car had "master cylinders" and > "slave cylinders", and so I did not think I was either inventing a new use > for the words "master" and "slave", or that my use of them for this purpose > would be controversial. I was naive, and I suggest that we revisit the > terminology we use in all our distributed systems, starting with DNS > transfer roles. What I find interesting about this, is the reasoning behind his decision at the time. Slavery was not something he appears to have been concerned with at the time, rather he repurposed terminology from his car's hydraulic system. If he was in the car modding scene at the time (which one may consider just as technically playful as DNS), who are we to judge it for anything other than that? What is, however, also worth considering is that at the time (1997), the world would not yet be aware of how profound the internet would be for rapid information exchange. That the extent to which we still held on to outdated beliefs was quite enormous. That enslavement and colonialism is a terrible thing to have happened. Granted, whether that discussion belongs in something so inherently technical as DNS, automotive hydraulics, or even IDE drives... I doubt it. Vicky (or Victoria, if I'm not allowed to use that name) told me at the time, that I should raise this concern in 2025, when ISC would deprecate the old terminology in their upstream distribution of BIND. The suggestion was made that this could be discussed if migration proves difficult. What an amusing twist of fate, that this thread now offers that opportunity. I think it's pretty self-evident that updating a config file is not a difficult thing to do. And in fact, I have already adopted the new terminology. I like that primary and secondary can expand into tertiary and even quaternary. That in today's world of cheap and abundant computing resources, having that many DNS servers is not just reasonable, but easy. But the question of what we call them should probably remain rooted in a technical discussion, one where the sociopolitical aspect is.. secondary. How ironic that this is probably the most suitable term here. Long story short, context matters. Paul Vixie made the context pretty clear, as an authoritative figure. Perhaps we were mistaken to tie slavery into this discussion in the first place. Or perhaps the designers at the time were mistaken to consider these terms so normal in the first place. Who knows. -- Met vriendelijke groet, Michael De Roover Mail: i...@nixmagic.com Web: michael.de.roover.eu.org -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
