<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Wow. This topic has generated a lot of comment. <div class=""><br class=""></div><div class="">We at ISC decided in 2017 to provide aliases for the master/slave terminology in BIND so users who don’t wish to use those terms don’t have to.  It was not a burden to make this change in the source code. <div class=""><br class=""></div><div class=""><div class="">Back when we made that initial change, I personally received several private emails from actual BIND users who had felt triggered, offended or otherwise distracted by the master/slave terminology, thanking us for making this change.  If even one or two users were upset by the old terms, that is enough, and surely there are more users who were impacted who didn’t speak up.  </div><div class=""><br class=""></div><div class="">We are now in the process of updating the terminology used in the BIND ARM. These edits are in review now (along with many other updates to the ARM.)<div class=""><br class=""></div></div><div class="">At the time we made the initial change we didn’t have a process for removing obsolete features so we just added an alias. Now that we do(1), we would like to implement that process to gradually deprecate the master/slave terms in favor of primary/secondary.  We would introduce a warning in 9.18, mark the old terms as deprecated in 9.20, and remove them in 9.21 (development branch). So, the master/slave terms will still work in the 9.20 Extended Support Version through its lifetime, which ends at the end of 2025. This constitutes an 8-year period for this change, which should be enough for even the most change-averse among us to adapt. </div><div class=""><br class=""></div><div class="">We are trying to ensure that this project is as inclusive as possible. BIND and the DNS are complicated enough without adding additional barriers. This seems like a reasonable accommodation. If this change (over the next 6 years) will cause you a signficant problem, please say so, but we don’t need to continue discussing whether it is worth the effort any more, because we are already convinced it is worth the effort on our part. </div><div class=""><br class=""></div><div class="">Vicky Risk</div><div class=""><div><br class=""></div><br class=""><div class="">
<div style="text-align: start; text-indent: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-align: start; text-indent: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Victoria Risk</div><div class="">Product Manager</div><div class="">Internet Systems Consortium</div><div class=""><a href="mailto:vicky@isc.org" class="">vicky@isc.org</a></div><div class=""><br class=""></div></div>(1) <a href="https://kb.isc.org/docs/policy-for-removing-namedconf-options" class="">https://kb.isc.org/docs/policy-for-removing-namedconf-options</a></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<br class=""></div></div></div></body></html>