Should ICANN attempt to mess with the distribution of the root zone, let
us just say that the results would not be pretty. There’s a balance of
terror here. ICANN carefully never does anything that would make the root
server operators say no, and the root server operators carefully avoid
putting ICANN in a position where they might have to do that.
When you say “ICANN” who, exactly, do you mean? ICANN the organization or ICANN the community? If the former, ICANN Org can’t do anything outside of ICANN community defined policy or process or risk all sorts of unpleasantness from internal policies to lawsuits to the ICANN Board being spilled. If you mean the latter, ICANN org must abide by the ICANN community’s demands or you get to the same point as previously mentioned. That’s the whole point behind the “Empowered Community."
I’m not guessing here, I go to ICANN meetings and talk to these people.
And I was one of the ICANN people involved in the negotiations with Verisign on the RZMA.
Last I knew, NTIA still believed that NTIA selects the root server operators.
I doubt even NTIA would ever have said this, and certainly not since the IANA Functions transition. This is simply not how the relationship between NTIA and ICANN operated (pre-transition, after transition it is even less).
Eventually the last person at NTIA who still knows what that means will retire, and then nobody in the USG will believe that they have responsibility. Then, ICANN lawyers will presumably start insinuating that, actually, ICANN can do what it wants there. Which they’ve already laid the groundwork for by failing to reassign the L-root nameserver for the last twenty-two years. Not a task that should take twenty-two years, in my opinion… CGI is perfectly capable, and there are no root servers administered in the southern hemisphere. State and Commerce were considering reassigning it as an apology for the Rousseff spying incident in 2013, but they didn’t quite get it together to act.
In any event, I think we agree that none of IANA, ICANN, and/or Verisign has the authority to remove one of the root operators, no matter how much someone might dislike their peering policies.
R's,
John
PS: Perhaps the GWG will eventually come up with a way to do that but I'm not holding my breath. It's been six years since RSSAC 037 and 038. I can't blame them for moving very slowly since it would be all too easy to come up with something worse than the current non-system
Suppose the community wanted to change this or make a formal policy on root
server hosting requirements. Where would this be done? Could a party submit
a proposal to ICANN via the policy development process? If not where should
the community start this?
Please note, I'm not taking a position, only asking where the community needs
to start.
It appears that Bryan Fields <nanog@nanog.org> said:
Suppose the community wanted to change this or make a formal policy on root
server hosting requirements. Where would this be done? Could a party submit
a proposal to ICANN via the policy development process? If not where should
the community start this?
The Governance Working Group that David mentioned has been grinding
along for the better part of a decade. It's quite a difficult problem.
The existing roots are doing a decent job, and any more formal
arrangement runs the risk of politically motivated "improvements".
People are worried about what happens if a root goes rogue or
disappears but unless the rogue operator were Verisign, which is
utterly implausible, the result would be not much. These days a lot of
web caches have their own copies of the root that they get directly
from ICANN or Verisign. (See RFC 8806. It's really easy.) For everyone
else, most clients now make DNSSEC queries and the root's signatures
expire after two weeks.
I would be a lot more worried about the other scenario David hinted
at, a future iteration of the US government tells ICANN or Verisign to
do something to the root zone, e.g., delete Iran or Russia or point
their name servers at something else.