[discuss] discuss Digest, Vol 4, Issue 148
Phil Corwin
psc at vlaw-dc.com
Sun Mar 16 22:08:09 UTC 2014
Milton:
I'm with you on this separation necessity. Take yes for an answer.
Not sure I am with you on the transfer of functions to a registry constituted DNSA, but I'm open to all options at this point in time.
Best, Philip
Message: 2
Date: Sun, 16 Mar 2014 21:12:47 +0000
From: Milton L Mueller <mueller at syr.edu>
To: Phil Corwin <psc at vlaw-dc.com>, "discuss at 1net.org"
<discuss at 1net.org>
Subject: Re: [discuss] discuss Digest, Vol 4, Issue 145
Message-ID: <6862c8b5cd6b4557a7c0f462fa518e41 at EX13-MBX-13.ad.syr.edu>
Content-Type: text/plain; charset="us-ascii"
Phil:
-----Original Message-----
>But what legal regime would you replace US law with? If there is no
>applicable body of law for ICANN then it is above the law and
>litigation- proof, and as a party interacting with private sector
>registries and registrars the potential for litigation enforces one type of accountability.
>Likewise, those contracted parties must know what body of law will
>interpret and enforce those contracts.
This is why IGP proposed to separate broader reforms of ICANN's incorporation and its policy making process from the globalization of the technical-clerical IANA functions. They are very distinct problems. Replacement of US law (if that is deemed advisable) might even require a new international treaty instrument.
It is relatively easy for us to let the IANA contract expire and pull the DNS-related IANA functions out of ICANN and into a new entity. Much harder to reincorporate ICANN and reform its policy making process. Try to do those two things together, and you either enter a morass of interdependent changes, or you just hand everything to ICANN without any accountability.
Philip S. Corwin, Founding Principal
Virtualaw LLC
1155 F Street, NW
Suite 1050
Washington, DC 20004
202-559-8597/Direct
202-559-8750/Fax
202-255-6172/cell
Twitter: @VlawDC
"Luck is the residue of design" -- Branch Rickey
-----Original Message-----
From: discuss-bounces at 1net.org [mailto:discuss-bounces at 1net.org] On Behalf Of discuss-request at 1net.org
Sent: Sunday, March 16, 2014 5:32 PM
To: discuss at 1net.org
Subject: discuss Digest, Vol 4, Issue 148
Send discuss mailing list submissions to
discuss at 1net.org
To subscribe or unsubscribe via the World Wide Web, visit
http://1net-mail.1net.org/mailman/listinfo/discuss
or, via email, send a message with subject or body 'help' to
discuss-request at 1net.org
You can reach the person managing the list at
discuss-owner at 1net.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of discuss digest..."
Today's Topics:
1. Re: discuss Digest, Vol 4, Issue 145 (Steve Crocker)
2. Re: discuss Digest, Vol 4, Issue 145 (Milton L Mueller)
3. Re: [governance] U.S. to Give Up Oversight of Web
Policymaking Body (Milton L Mueller)
4. Re: discuss Digest, Vol 4, Issue 145 (Avri Doria)
----------------------------------------------------------------------
Message: 1
Date: Sun, 16 Mar 2014 16:56:05 -0400
From: Steve Crocker <steve at shinkuro.com>
To: Avri Doria <avri at acm.org>
Cc: "discuss at 1net.org" <discuss at 1net.org>
Subject: Re: [discuss] discuss Digest, Vol 4, Issue 145
Message-ID: <243997DD-C9F3-4BB5-A21C-668E47492595 at shinkuro.com>
Content-Type: text/plain; charset=windows-1252
On Mar 16, 2014, at 4:45 PM, Avri Doria <avri at acm.org> wrote:
> As for IANA, I favor a mesh of MOUs with the clients (ICANN, IETF, Root Server Operators, RIRs, ...) and Host country agreements with several nations known for protecting data rights, with oversight by a Multistakeholder panel of IANA Stewards.
Avri,
You?re specifying a solution. What?s the problem?
Steve
------------------------------
Message: 2
Date: Sun, 16 Mar 2014 21:12:47 +0000
From: Milton L Mueller <mueller at syr.edu>
To: Phil Corwin <psc at vlaw-dc.com>, "discuss at 1net.org"
<discuss at 1net.org>
Subject: Re: [discuss] discuss Digest, Vol 4, Issue 145
Message-ID: <6862c8b5cd6b4557a7c0f462fa518e41 at EX13-MBX-13.ad.syr.edu>
Content-Type: text/plain; charset="us-ascii"
Phil:
-----Original Message-----
>But what legal regime would you replace US law with? If there is no
>applicable body of law for ICANN then it is above the law and
>litigation- proof, and as a party interacting with private sector
>registries and registrars the potential for litigation enforces one type of accountability.
>Likewise, those contracted parties must know what body of law will
>interpret and enforce those contracts.
This is why IGP proposed to separate broader reforms of ICANN's incorporation and its policy making process from the globalization of the technical-clerical IANA functions. They are very distinct problems. Replacement of US law (if that is deemed advisable) might even require a new international treaty instrument.
It is relatively easy for us to let the IANA contract expire and pull the DNS-related IANA functions out of ICANN and into a new entity. Much harder to reincorporate ICANN and reform its policy making process. Try to do those two things together, and you either enter a morass of interdependent changes, or you just hand everything to ICANN without any accountability.
------------------------------
Message: 3
Date: Sun, 16 Mar 2014 21:26:29 +0000
From: Milton L Mueller <mueller at syr.edu>
To: Steve Crocker <steve at shinkuro.com>, Avri Doria <avri at acm.org>
Cc: "discuss at 1net.org List" <discuss at 1net.org>
Subject: Re: [discuss] [governance] U.S. to Give Up Oversight of Web
Policymaking Body
Message-ID: <6681eee8069b45f3ad9dc6a6ea0e02aa at EX13-MBX-13.ad.syr.edu>
Content-Type: text/plain; charset="us-ascii"
Steve
Based on what you write below, I still see a clear distinction between the policy decisions, and their later implementation by the IANA. Of course the policy and the implementation are interdependent. But none of your examples undercut the argument for structural separation.
IPv6 addresses: RSSAC and SSAC are obviously on the ICANN, policy side of the equation. If they recommend adding v6 addresses to the glue records, IANA implements.
IDNs: Obviously, like any new TLD addition whether to authorize them or not was a policy decision, albeit dependent on prior standardization work by the IETF and tests.
DNSSEC: You ask "Should the root be signed? If so, how? What should the rules be for assuring trust in the process? How often should the root key be changed?" - These all seem to be policy decisions to me.
I would note that separating IANA implementation from policy seems a lot less intricate and complicated to me than the separation of registry and registrar functions, which was done 15 years ago with huge economic and technical consequences.
When you talk about "complete separation of policy and administration" I wonder whether you have an unrealistic notion of separation in mind, which is not what anyone advocates. It doesn't mean a lack of communication, for example. It is more like a clear division of labor or function. Sure, there are bound to be some grey areas, but that shouldn't be used to rationalize complete integration of the two.
Also, you ask for example of where the current configuration has failed to operate properly. But this misses the point: under the current configuration, you are _contractually obligated_ to run the IANA functions in a way that meets standards. Once that USG contract goes away, what is the guarantee that this will continue to happen?
From: discuss-bounces at 1net.org [mailto:discuss-bounces at 1net.org] On Behalf Of Steve Crocker
Sent: Sunday, March 16, 2014 4:29 PM
To: Avri Doria
Cc: discuss at 1net.org List
Subject: Re: [discuss] [governance] U.S. to Give Up Oversight of Web Policymaking Body
Avri,
On Mar 16, 2014, at 2:53 PM, Avri Doria <avri at acm.org<mailto:avri at acm.org>> wrote:
Hi,
One of those principles for me would be:
- Strict functional separation of the policy making and administration
This is not as simple as it might seem. It depends on exactly what you mean by "policy." I expect your focus, along with many others, is the decisions related to delegation and re-delegation, i.e. which names are added to the root zone who is allowed to operate them. Perhaps "policy" also includes various issues related to public interest, compliance, etc. For all of these, I would agree strongly that we do not want to burden the IANA group or the operation of the IANA function with those sorts of issues.
On the other hand, here are some other things that have been treated as policy issues in the past that are intimately related to the operation of the IANA function.
* DNSSEC. Should the root be signed? If so, how? What should the rules be for assuring trust in the process? How often should the root key be changed? Etc.
Quite obviously we've gotten past the first few questions, but there was a lengthy period several years ago where the answers to these questions were stuck in limbo. Even now, there are important questions about the frequency of key rollover, etc. that are not yet reduced to standard practice.
* IPv6 addresses for root servers. Should IPv6 addresses be included as glue records for the root servers?
Again, we are now well past this question, but there was a surprisingly long period where several of the root servers were accessible via IPv6 addresses but those addresses were not in the root zone. Worse yet, there was no process in place for figuring out whether it was ok to add them and what the issues might be. (Eventually RSSAC and SSAC did an ad hoc study to provide advice to IANA to get it done. (See SSAC reports SAC 018 and supporting reports SAC 016 and SAC 017.)
* IDN TLDs. Are IDNs ok as top level domains?
It took a long time to work through these issues. Along the way, eleven names in various scripts were added to the root zone for testing and evaluation.
Each of the items in the list above has a required policy development and policy decisions. Equally, each is so intimately tied to the operation of the IANA function that it is impossible and ill-advised to insist there be a complete separate between "policy" and "administration." Going forward, I think we need to be careful to fit the solution to the problems. The IANA function is critical to the operation of the Internet. As technology changes, the details of its operation must change too. From my perspective, there will be a mix of policy, technical, administrative and resource issues involved in these changes. We need a system that is transparent and accountable. We also need a system that is efficient and effective.
I think that many, myself included, do not see how being part of ICANN and strict functionally separation are possible within ICANN's current configuration.
Can you identify specific instances where the current configuration has failed to operate properly and where the failure is due to lack of strict functional separation? (Also, I think there's been pretty strong separation in place for a long time, so I'm not sure how much more separation you have in mind.
This may also be a big part of the expectations of global stakeholders.
There is also the issue of ICANN being subject to US law. This remains a problem if ICANN plans to keep the administrative function after transition.
The question has already been asked and I'll ask again. What is the specific problem about being subject to US law? As a general matter, rule of law is usually considered one of the U.S.'s very strongest qualities.
Thanks,
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140316/00a847c1/attachment-0001.html>
------------------------------
Message: 4
Date: Sun, 16 Mar 2014 17:32:15 -0400
From: Avri Doria <avri at acm.org>
To: "discuss at 1net.org" <discuss at 1net.org>
Subject: Re: [discuss] discuss Digest, Vol 4, Issue 145
Message-ID: <5326185F.1040707 at acm.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Hi,
On 16-Mar-14 16:56, Steve Crocker wrote:
>
> On Mar 16, 2014, at 4:45 PM, Avri Doria <avri at acm.org> wrote:
>
>> As for IANA, I favor a mesh of MOUs with the clients (ICANN, IETF,
>> Root Server Operators, RIRs, ...) and Host country agreements with
>> several nations known for protecting data rights, with oversight by a
>> Multistakeholder panel of IANA Stewards.
>
> Avri,
>
> You?re specifying a solution.
Yes, i was asked for a possible solution so I gave one. The answer was given more to show that a solution was possible, than to start working on solutions prematurely.
I had previously, as you requested, stated a principle. As far as I could tell, the question stemmed from thinking about the principle I offered and what it might mean in real life.
I understand you do not agree with this principle. Nonetheless I persist in believing it is a principle worthy of extended discussion but the wider community.
> What?s the problem?
The problem is that strict functional separation cannot be done in ICANN as currently constituted. It is contrary to its organizational structure and to the philosophy of integrating policy with implementation, which I also support.
So if you accept the principle of strict functional separation, between policy and administration of the critical IANA resource, we have an implementation problem.
For you list of issues, it looks like we have some work to do on defining processes for dealing with such issues while maintining a strict wall between ICANN's policy machinations and the operation of IANA.
>> There is also the issue of ICANN being subject to US law. This
>> remains a problem if ICANN plans to keep the administrative function
>> after transition.
>
> The question has already been asked and I?ll ask again. What is the
> specific problem about being subject to US law? As a general matter,
> rule of law is usually considered one of the U.S.?s very strongest
> qualities.
>
This has been answered many times by many people, but I will answer yet again. US law on occasion restricts who a company does business with.
Losing NTIA oversight does not change that. IANA should not be subject to such vagaries of national law.
Beyond that, US law allows infractions of rights against the privacy etc of data and pervasive monitoring that may not be appropriate for the future of IANA and which are not consistent with other rule of law jurisdictions.
avri
------------------------------
_______________________________________________
discuss mailing list
discuss at 1net.org
http://1net-mail1net.org/mailman/listinfo/discuss
End of discuss Digest, Vol 4, Issue 148
***************************************
More information about the discuss
mailing list