Olivier,

Thanks for this input.  I’d like to take a step back so that we are all on the same page.  I hope everyone with take the time to review this post.  I think we are making this work unnecessarily complicated.

Under the straw man I’ve suggested the “Council” or “Body” or whatever it is called is responsible for negotiating and interacting with IANA on technical issues.  As defined by the IANA functions contract, IANA’s naming-related tasks include the following:

Root ZoneFile Change Request Management—The Contractor shall receive and process root zone filechange requests for TLDs as expeditiously as possible.  This does not include a policy role at all.  A new TLD is entered into the root only after the ICANN Board directs IANA to do that.  Policy remains in ICANN, not the IANA function.

Root Zone “WHOIS” Change Request and Database Management –The Contractor shall maintain, update, and make publicly accessible a Root Zone “WHOIS” database with current and verified contact information for all TLD registry operators.  Again, this involves no policy role.  ICANN makes policy on WHOIS, not IANA.  IANA just follows ICANN’s orders.

Delegation and Redelegation of Generic TLDs and Country Code TLDs.  Again, the role is administrative and not policy making.  IANA adds or removes a TLD from the root only at the direction of the ICANN Board.  It is responsible for documenting that the action was consistent with established ICANN policy, but has no role in formulating that policy.

Root ZoneAutomation--The Contractor shall work with NTIAand the Root Zone Maintainer, and collaborate with all interested and affected parties to deploy afully automated root zone managements system.  This is an administrative/operations task, not a policy task.

Root Domain Name System Security Extensions (DNSSEC) KeyManagement—The Contractor shall beresponsible forthe management ofthe root zone KeySigning Key (KSK), including generation, publication, and use for signing the Root Key set.  Again, DNSSEC policy is set by ICANN, informed by all stakeholders, the SSAC, etc.  IANA simply administers the ICANN policy.

Customer Service Complaint Resolution Process (CSCRP)—The Contractor shall work with NTIA and collaborate with all interested and affected parties to establish and implement a process for IANA function customers to submit complaints for timely resolution that follows industry best practice a and includes a reasonable time frame for resolution.  This relates to complaints about IANA doing its technical job in a timely and competent fashion, not policy, which remains with ICANN.

Perform Administrative Functions Associated WithRoot Zone Management.  Facilitate andcoordinate the root zoneof the domain name system, andmaintain24hour-a-day/7days-a-weekoperationalcoverage.

I would agree with you that a conflict of interest could emerge if IANA was developing policies for the registries, but that is not what’s being proposed.  Rather, all policy work would remain with ICANN subject to multi-stakeholder processes – just as it is now.   What conflict of interest arises in this situation?  Registries will be in the best position to know whether or not IANA is processing name server changes in a timely fashion.  Registries are harmed if it takes forever to do that.  To the limited extent this kind of thing might impact end users, registries have all of the necessary incentives to get it fixed.  In the early years of ICANN, when IANA was performing very poorly, registries were unhappy, but most of the rest of the ICANN community was not impacted in any way.  Today, the ICANN board - NOT IANA - promises stakeholders that IANA will do its work in accordance with ICANN policy.  If it doesn't, I am going to look to the ICANN Board and not the IANA staff for redress.   

I don’t see a conflict of interest in registries performing an oversight role with respect to IANA’s purely technical and operational functions.  Remember, the IANA function contract specifies that IANA’s role is technical and operational, not policy development.  If IANA does something that is inconsistent with ICANN policy, I want the ICANN Board to be accountable.   

Again, to be clear, I am not unalterably opposed to having other parts of the community participate, but I don’t understand why they would want to.

Becky

J. Beckwith Burr

Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer

1775 Pennsylvania Avenue NW, Washington, DC 20006

Office: + 1.202.533.2932  Mobile:  +1.202.352.6367  / becky.burr@neustar.biz / www.neustar.biz