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

Sat Feb 15 23:32:25 UTC 2014

This formulation seems to be in a "flat" context while the Verising 
cooperative agreement and the IETF agreement are not neutral. ICANN 
can provide similar services to others.

At 20:15 15/02/2014, David Conrad wrote:
>On Feb 15, 2014, at 8:29 AM, Milton L Mueller 
><<mailto:mueller at syr.edu>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."?

Yes. This might be of interest for other non-IETF IANA style services.

>>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.

The cooperative argeement does not permit them for example to support 
an open TLD or an alternate root; This may limit the Verisign's 
capacity for innovation/experimentation (I remember the commitment of 
Verisign to substantially invest in R&D and did not see much of it.

>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

Paul Twomey planned a DNSSEC specialized agency. This could be a way 
to separate the risks. And a service  to TLDs?

>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
>
>I'm not sure what 4 means.

Actually is that not more "surety"? Including to be surety (trust?) 
that security will be included.

Best
M G 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140216/081a1da3/attachment.html>