<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=""><div class="">Bryan - </div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">One of the things that was clarified with the IANA Stewardship Transition is that ICANN has (at least) two distinct roles contained within it: one is coordination of the domain name community to develop Domain Name policy and the other is the IANA / Public Technical Identifiers (PTI) role serving as operator of the IANA functions (i.e. performing the administration of the various DNS, protocol registries, and the Internet numbers registries)</div><div class=""><br class=""></div><div class="">The IANA doesn’t set policy, but rather takes policy for each set of identifiers from the respective community: a) ICANN DNS Community for the DNS root zone, b) IETF for the protocol parameter registries, and c) the RIRs for the unicast IPv4, unicast IPv6, and ASN registries listed in IETF RFC 7249. David is definitely correct to say that determining what (if any) governance model should be utilized for the root server operators is a question outside the scope of the administrative/technical operations performed by the IANA/PTI, and rather a question that the various DNS stakeholders (DNS community, ICANN, IETF, and the Root Server Operators) must ponder. </div></blockquote><div class="">/John</div><div class=""><br class=""></div>On 26 Oct 2021, at 12:25 PM, Bryan Fields <<a href="mailto:Bryan@bryanfields.net" class="">Bryan@bryanfields.net</a>> wrote:<br class=""><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div class="">On 10/26/21 12:10 PM, David Conrad wrote:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Surely IANA has the power to compel a root server operator to abide by<br class="">policy or they lose the right to be a root server?<br class=""></blockquote>To compel? No. Not in the slightest. That is not how the root server system<br class="">works. This is a (very) common misconception.<br class=""></blockquote><br class="">Can you explain how it would work? Say you have a root server operator who<br class="">starts messing up, is there any ability to remove them?<br class=""><br class=""><blockquote type="cite" class="">There has been some effort to create a governance model for the root server<br class="">system (see<br class=""><a href="https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf" class="">https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf</a>) but I<br class="">believe it has gotten bogged down in the question of “what do you do when a<br class="">root server operator isn’t doing the job ‘right’ (whatever that means and<br class="">after figuring out who decides) but doesn’t want to give up being a root<br class="">server operator?”. <br class=""></blockquote><br class="">Seems like a good policy, 6.3 seems to cover how to fix technical issues with<br class="">a root operator.<br class=""><br class=""><blockquote type="cite" class="">It’s a hard question, but it isn't the folks at IANA who answer it.<br class=""></blockquote><br class="">Who does? Doesn't IANA designate root servers and the . zone?<br class=""><br class="">-- <br class="">Bryan Fields<br class=""><br class="">727-409-1194 - Voice<br class=""><a href="http://bryanfields.net" class="">http://bryanfields.net</a><br class=""></div></div></blockquote></div><br class=""></body></html>