[CWG-Stewardship] FW: Responding to Olivier

Wed Oct 29 17:45:09 UTC 2014

Forwarding Becky's message below since it was sent to the "bounce" address
by mistake.

From:  "Burr, Becky" <Becky.Burr at neustar.biz>
Date:  Wednesday, October 29, 2014 1:38 PM
To:  "cwg-stewardship-bounces at icann.org" <cwg-stewardship-bounces at icann.org>
Subject:  Responding to Olivier

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 at neustar.biz
/ www.neustar.biz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20141029/c2c3736a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5097 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20141029/c2c3736a/smime-0001.p7s>