[discuss] Some more legal tangles for ICANN

Mon Jun 30 16:07:43 UTC 2014

On Jun 30, 2014, at 5:23 AM, Nigel Roberts <nigel at roberts.co.uk> wrote:
> ICANN can only change root zone data in ONE root server - the one it operates.

Sort of.  Yes, ICANN can modify the contents of zone on the "L" root server.  However, if they do so, the modified zone will no longer validate, resulting in the response being dropped by about 16% of the Internet (today, likely more in the future).  

> It has no authority over the master root server, nor any of the others.

Right. The lawsuit is targeted at the wrong body.

> On 06/30/2014 11:19 AM, Norbert Bollow wrote:
>> Any judge can ask someone with a bit of knowledge of how the Internet
>> works about what it takes to transfer the “.ir TLD asset” to the
>> plaintiffs. This could plausibly result in a court order which would
>> give the plaintiffs in the action against Iran the power to direct
>> ICANN to change to root zone file in relation to .ir as they see fit,
>> similar to the owner to any .com 2LD has the power to get corresponding
>> updates made in the .com zone.

Not quite. In the .COM case, Verisign controls the zone file and has control over the authority servers.  In the root case, ICANN controls neither the zone file nor the authority servers (excepting "L" of course).

However, for sake of argument, ignore reality and assume a court order is issued that demands ICANN transfer .IR (and all appeals are exhausted). ICANN would presumably then create and submit the root zone change request to NTIA for authorization. Such a change request is obviously outside of policy, thus NTIA should reject it. A new court order (or lawsuit?) would likely be necessary, this one against the U. S. Dept. of Commerce, NTIA.  If we assume that succeeds, then presumably NTIA would direct Verisign to modify the root zone to update the glue records for .IR to point to the new servers. The root server operators (and others) would then be required to server the new zone. I have some skepticism that all the root server operators (and others) will actually do so. Far more likely in my opinion: a new root authority will be established, the root trust anchor will be updated to reflect that new authority, and the root server operators (and others) will pull the zone from that new authority.

The core problem here is an assumption of top-down control of the Internet.  Despite the cliche, in reality, authority really does derive from the bottom-up. In this case, authority rests with the resolver operators that configure the trust anchor and/or the root server operators (and others). ICANN, the root management partners, and the vast array of policies, processes, and systems that exist are merely an agreed upon convention that facilitates updating the root zone.

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140630/07ba758d/signature.asc>