[governance] DMP} Statement on Process and Objectives for the Global Multistakeholder Meeting on the Future of Internet Governance

[David Conrad]

Hi,

On Dec 8, 2013, at 8:26 PM, McTim <dogwallah at gmail.com> wrote:
> "The USA has never used this technical possibility to remove a country
> from the Internet (US DOC authorizes ICANN via an IANA contract, to
> manage the root zone).[1]"
> 
> Can you explain how the US could do this as a "technical possibilty".
> AFAIK, they only ascertain if the change was done according to IANA
> procedure.  They don't have control over the zone itself.

I gather the theory is that some part of the US Government would issue some sort of legally binding directive outside of the normal IANA root zone management function. Realistically, I'd imagine that directive would be applied to Verisign, not ICANN since Verisign is the only organization that has the technical capability to change the root zone unilaterally. Of course, it remains unclear whether the root server operators would accept such a change, but I gather we're talking symbology and theory here.

> When you wrote "Such an ICANN+ would both host the root server, and
> manage the root database."

I'm not sure what "host the root server" means here.

> Did you mean that they would be the rootzone admin and the database
> manager?  They already host a rootserver (L) and are (via IANA
> function) the DB manager.

There might be a bit of confusion here.  To be explicit in the roles:

- ICANN, as the IANA function operator, validates (in terms of syntax, semantics, and that the request can from an authorized party, i.e., the TLD administrator) root zone change requests and submits those validated requests for authorization to NTIA.  ICANN is _not_ the database manager.

- US Dept. of Commerce, NTIA authorizes those change requests, verifying ICANN has performed the IANA root zone management function appropriately.  Once authorized, the change request is released to Verisign for implementation.

- Verisign, under a cooperative agreement with NTIA, acts as the root zone maintainer.  Verisign accepts the NTIA-authorized root zone change request, implements that change request in the root zone by updating the root zone database, resigns the root zone with the DNSSEC zone signing key (which has been signed by the key signing key maintained by ICANN), and then places the changed and newly signed root zone onto a distribution server, notifying (via the DNS protocol) that a new zone is available.

- The 12 root server operators, either due to the notification sent by Verisign or because of timers built into the root zone, automatically pull the new root zone from the distribution server and place it on their servers (which, in most cases, actually a constellation of instances all over the planet).  For example, ICANN, as one of the 12 root server operators, pulls the root zone from the distribution master server and then pushes it out to the 146 sites (300+ machines last I heard) that respond to DNS queries sent to the "L" root server address.

I hope this clarifies.

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://lists.igcaucus.org/pipermail/governance/attachments/20131208/b3a6d7d6/attachment.sig>
-------------- next part --------------
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.igcaucus.org
To be removed from the list, visit:
     http://www.igcaucus.org/unsubscribing

For all other list information and functions, see:
     http://lists.igcaucus.org/info/governance
To edit your profile and to find the IGC's charter, see:
     http://www.igcaucus.org/

Translate this email: http://translate.google.com/translate_t