[discuss] A final revision of Problem Statement No. 1?

[David Conrad]

Hi,

A few suggestions/observations:

On Feb 15, 2014, at 8:29 AM, Milton L Mueller <mueller at syr.edu> wrote:
> Appendix 1: Problem Statement from the 1net list
>  
> 1. The Internet Assigned Names and Numbers Authority (IANA) has as one of its functions the administration of changes in the Internet DNS root zone file.

The changes IANA staff perform are more than simply proposing edits to the DNS root zone (as something of an aside, I'd note that the implementation of the root zone does not have to be a file: that's just an implementation choice).  IANA staff also modifies the root zone registration (aka "Whois") database, a task that does not involve Verisign but does involve NTIA (for authorization).

Perhaps "... administration of changes in the Internet's DNS root zone and associated registration databases."?

> The team that performs the IANA functions is employed by ICANN, the Internet Corporation for Assigned Names and Numbers.
> 
> 2. ICANN has a zero-cost contract with the US government to perform the IANA functions. The US government approves all changes made to the root zone.  Another contractor to the US government, Verisign, operates the

The term "operates" here is odd -- the root zone is just data; it doesn't operate.  A better term might be "maintains".  

> authoritative root zone file and its contract requires it to implement changes approved by the US government.

It's more accurate to say "cooperative agreement" instead of "contract", although I'm not sure what the differences actually are.

Also, it is worth noting that "implement" is actually 3 separable tasks:

a) edit the root zone data
b) DNSSEC-sign the root zone data
c) make the edited and DNSSEC-signed data available for the root servers to serve

As I've mentioned in the past, having all three of these tasks performed by a single entity is (IMHO) a vulnerability/bug that has bitten us before.

I might suggest: "... file and its cooperative agreement requires it to edit, DNSSEC-sign, and distribute the resulting zone data as approved by the US government."

> 3. It has been a requirement for the contractor providing the IANA function to be incorporated, maintain a physical address, and perform the IANA functions in the US, resulting in the provision of the IANA function being subject to

Nit: "functions", not "function" (last reference to IANA in the sentence).

> US law and political influence.
> 
> 4. Objections have been raised to US government involvement in this process on several grounds, including

"regarding US" instead of "to US"?

> exclusivity and concerns of trust. Objections have also been raised to movement of the function to various intergovernmental organizations.

"regarding movement" instead of "to movement"?

> 5. Acceptable solutions for assignment of the IANA root zone function should meet several criteria: (1) protection of root zone management from political or other improper interference; (2) integrity, stability, continuity, security and robustness of the administration of the root zone; (3) widespread trust by Internet users in the administration of this function; (4) support of a globally interoperable root zone; and (5) agreement regarding an accountability mechanism for this function. 

I'm not sure what 4 means.

If the goal here is to be comprehensive regarding criteria, it might be worthwhile to be a bit more specific about the term "security".  That term is often defined to be "confidentiality, integrity, and authentication" (aka "CIA", but that acronym may be unfortunate here :)) but often also includes "access control", "nonrepudiation", "availability", and "privacy".  IANA staff (at least in the past, I suspect now as well) are required to abide to varying degree to all of these in the performance of their jobs.  Then there are infrastructure related concerns, e.g., "stability" and "resiliency" (perhaps covered by "robustness" above) and policy related concerns, e.g., "transparency", "openness", "auditability", "responsiveness", "improvability", and "efficiency" in addition to "accountability".  I'm probably missing a few.

> 6. A number of potential solutions have been proposed; however, there has been no consensus on any of them.

Yea verily.

Regards,
-drc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140215/8cbd4b15/attachment.html>
-------------- 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/20140215/8cbd4b15/signature.asc>