[discuss] Possible approaches to solving "problem no. 1"

[Ian Peter]

Hi George,

one question is the general accountability of ICANN which Marilyn Cade 
referred to under a separate post. From this outsiders point of view that is 
the main accountability issue. This is a separate question to internalising 
the former IANA functions, but maybe one which needs to be addressed in 
parallel or as a condition imposed (by say USG)  for acceptance of the 
changes proposed.

the second question  is whether any specific accountability measures are 
needed for the former IANA functions. I suspect not if the first question is 
addressed properly. But if GAC insists on a special role here it would have 
to be looked at. However, by the time a detailed process is considered they 
might be happy without it. As to accountability for these specific functions 
(or a subset of them) to some body outside of ICANN, I would avoid it if 
possible. It would only be a consideration IMHO if governments insisted on 
it, and then Jovan's model becomes a good option.  But I really don't see 
this as necessary unless it becomes politically necessary.

re timing - just to remind everyone of the EU's demand/suggestion for a 
timeframe for all of this. I think an important consideration. This cannot 
be allowed to drag on forever to appease those who really don't want things 
to change at all.

One last point on some postings elsewhere which suggest legislative action 
might be needed for a change in US role in authorisation of IANA functions. 
But if IANA ceases to exist as part of the process improvement suggested in 
this area, this would probably overcome that need?


Ian Peter

-----Original Message----- 
From: George Sadowsky
Sent: Tuesday, February 18, 2014 12:22 AM
To: Peter Ian
Cc: discuss at 1net.org List
Subject: Re: [discuss] Possible approaches to solving "problem no. 1"

All,

If we want to move forward from Ian Peter’s conclusion below, the 
accountability framework for ICANN becomes crucial, which is why I quoted 
earlier from Jovan’s two diplomacy-based options.  ICANN can internalize 
IANA without a problem, but then how is ICANN made accountable in a manner 
that both leaves the degrees of freedom it needs to operate effectively and 
ensures effective global oversight over its activities?

George

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

On Feb 17, 2014, at 12:36 AM, Ian Peter <ian.peter at ianpeter.com> wrote:

> Folks,
>
> Much though this is interesting I wonder if it is a priority to work on 
> this amount of detail at this point of time?
>
> If we are to achieve something through 1net and the presence here of many 
> stakeholder groups, I think we will have to concentrate on high level 
> statement of directions, some high level principles, and an agreed message 
> that is also likely to be broadly supported by governmental stakeholders. 
> This is not the forum for detailed technical process evolution.
>
> I think that statement that we need would be along the lines of a 
> recommendation that the previous IANA processes be internalised within 
> ICANN.  ICANN (not 1net, or it would never get done) would be asked to 
> come up with a set of procedures and processes in consultation with 
> stakeholders.
>
> I don't think any of the processes are rocket science. They are  no more 
> difficult than the sorts of processes that banks, hospitals, and many 
> businesses manage on a daily basis, with high levels of  checks and 
> balances to ensure integrity and security of outputs. It's not going to be 
> difficult to write such processes once there is a clear direction.
>
> The reasons why this is "problem no 1" are not technical. They are 
> political, in that the current antiquated arrangements seeing a unilateral 
> authorisation role for USA is unacceptable to almost all stakeholders and 
> has to be replaced. A multilateral solution (such as ITU management) is 
> also unacceptable to a number of key stakeholders. There we are left with 
> no choice but to internalise the previous IANA processes within ICANN - 
> definitely the preferred direction in discussions here thus far -or face 
> the consequences of multiple roots and a fragmented internet. We really do 
> have to act on this and devote our energies towards a political solution 
> which I believe is now achievable.
>
> It's a multistakeholder solution, which is the buzzword for EU, USA, many 
> other governments, and 1net. If we can't do this we might as well throw 
> multistakeholder out the window.
>
> Ian Peter
>
> -----Original Message----- From: Steve Crocker
> Sent: Monday, February 17, 2014 12:59 PM
> To: Keith Davidson
> Cc: discuss at 1net.org
> Subject: Re: [discuss] Possible approaches to solving "problem no. 1"
>
> The new ccTLD path applied only to existing countries and territories.  I 
> think Oceania would have to get an entry in ISO 3166-1 first.
>
> Steve
>
>
> On Feb 16, 2014, at 8:56 PM, Keith Davidson <keith at internetnz.net.nz> 
> wrote:
>
>> On 17/02/2014 2:47 p.m., Steve Crocker wrote:
>>>> Actually the discussion does raise some interesting aspects, 
>>>> particularly in the new gTLD environment. There are a good many new 
>>>> gTLDs that are more aligned in principles to ccTLDs than to the legacy 
>>>> gTLDs - especially country, city and territory names, and also some 
>>>> local non-ASCII language gTLDs. Sovereign rights issues arise somewhat 
>>>> similarly as they do to ccTLDs, as do serving the local Internet 
>>>> community. The US Government "control" via the IANA contract should 
>>>> arguably be trumped by the greater rights of sovereignty and servicing 
>>>> the local community.
>>>>
>>>> I wonder if ICANN would give any consideration to applications made for 
>>>> gTLDs under the auspices of RFC1591, rather than the new gTLD processes 
>>>> that have evolved since ICANN was created? Wouldn't there be greater 
>>>> vibrancy and diversity under the more simple framework created by 
>>>> RFC1591? Is ICANNs role to generate stock standard outputs, or to 
>>>> encourage real diversity?
>>>
>>> Several years ago I tried to stimulate some discussion along a similar 
>>> line.  The political/contractual distinction between ccTLDs and gTLDs 
>>> turned out to be so dominant that it was impossible to draw the lines 
>>> any other way.
>>>
>>> I think the only way to accomplish what you have in mind is to to work 
>>> within the ICANN framework to bring RFC 1591 ideas into to the GNSO 
>>> policy framework.  I have no idea whether this might be feasible.
>>>
>>> Meanwhile, additional ccTLDs have been created for IDN-ccTLDs.  That's 
>>> probably not exactly what you have in mind, but it touches on your idea.
>>
>> Agreed, that the IDN ccTLDs created on the fasttrack were subject to the 
>> RFC1591 requirements only, considerably simpler / cheaper / quicker than 
>> the ICANN gTLD process. Which does prove that ICANN can accept new 
>> non-ISO-3166 ccTLD applications (and RFC1591 determined that the ISO-3166 
>> list was the one to be used for delegations of ccTLDs). Which leads the 
>> way to the interesting possibility that aspiring gTLDs could use RFC1591 
>> instead of the ICANN gTLD process - which might be relevant to 
>> territories, regions or sub-regions that are not recognised on ISO-3166. 
>> For example, the Oceania region might apply for .oceania...
>>
>> Cheers
>>
>> Keith
>
>
> _______________________________________________
> discuss mailing list
> discuss at 1net.org
> http://1net-mail.1net.org/mailman/listinfo/discuss
>
> _______________________________________________
> discuss mailing list
> discuss at 1net.org
> http://1net-mail.1net.org/mailman/listinfo/discuss