On Oct 29, 2014, at 10:39 AM, Burr, Becky <Becky.Burr@neustar.biz> wrote:

Root Zone File Change Request Management— The Contractor shall receive and process root zone file change 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.

This third sentence here is probably misplaced. While true, I presume you are talking here about root zone change requests (i.e., name server changes, delegation signer changes, or glue changes), not adding a new TLD (which is discussed under delegation/redelegation). To be explicit, the board does NOT direct IANA staff to do name server, delegation signer, and/or glue changes but does confirm staff has followed documented policy in the cases of delegations and re-delegations and directs staff to go ahead.

And yes, policy is not in 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.

Agreed that there is no policy role. However, a slight ambiguity/complication here: not just ICANN's orders. Whois, the protocol, is defined by the IETF and the data schema associated with registration data is somewhat entangled with IETF requirements. For example, there is a requirement implicit in the new RDAP protocol (likely to eventually replace the Whois protocol) that the registration data include a pointer to the RDAP server. I believe the IETF will be instructing IANA (in the "IANA Considerations" section of the RDAP specification RFCs) to do whatever is necessary for that pointer is kept with the registration data.

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.

True.

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

Agreed that this is not policy and it is probably worth pointing out this has been done (as much as software is ever 'done').

Root Domain Name System Security Extensions (DNSSEC) Key Management—The Contractor shall be responsible for the management of the root zone Key Signing 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.

It is true that IANA simply (for some value of the variable 'simply' :)) administers the policy, however the statement of DNSSEC policy (known as the DNSSEC Practice Statement or DPS) was a joint effort between ICANN staff and Verisign, with significant input from the community, designed to meet the requirements specified by NTIA (the actual DPS is at https://www.iana.org/dnssec/icann-dps.txt).

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.

True.

Perform Administrative Functions Associated With Root Zone Management. Facilitate and coordinate the root zone of the domain name system, and maintain 24 hour-a-day/7 days-a-week operational coverage.

I would agree that this is not policy (if that was your intent).

Hope this helps.

Regards,

-drc