[CCWG-Accountability] CCWG-Accountability work team 2: draft 5.1

Carrie Devorah carriedev at gmail.com
Tue Dec 30 16:55:30 UTC 2014


I agree Kavouss. Part of that decision process must be aware that for every
good there is a bad so what is built in now before there is bad makes that
a wise approach.

As with all contracts, what is being crafted is the Divorce before the
marriage or in other terms, the pre-nup.  Best to cover the bad stuff now
rather than assume it can never happen

Carrie Devorah

On Tue, Dec 30, 2014 at 11:11 AM, Kavouss Arasteh <kavouss.arasteh at gmail.com
> wrote:

> The issue is not about the individuals designated after transition.
> The issue is how and who designate these members
> What are the principles to be used in their désignations
> More importantly should they be nominated and then designated or
> They should be suggested and elected or
> There should be an open candidatships filling certain conditions and
> qualifications
> Then who and how the designation and or election is to be carried out .
> Individuals which are not designated and/ or elected by public Global
> Multistakeholders or their lega représentatives ) could not be held
> accountable to that entity.
> Regards
> Kavouss
>
> 2014-12-30 15:39 GMT+01:00 Carrie <carriedev at gmail.com>:
>
>> The BOARD talked about is this Board. Congress asks 'what happens when
>> this Board is replaced with other members unknown today?
>>
>> Sent from my iPhone
>>
>> On Dec 30, 2014, at 9:11 AM, Kavouss Arasteh <kavouss.arasteh at gmail.com>
>> wrote:
>>
>> Dear All,
>>  I  ALSO think Avri is right – the solution set is binary. * If the
>> Board/ICANN will accept in WS1 ** a proposl for a strong contractual
>> boundary on what they may do along with an external mechanism that can be
>> invoked by the community to police that boundary, then most of the other
>> accountability can be in WS2. *
>>
>>
>>
>>  COMMENT FROM KAVOUSS
>>
>> This has exactly been proposed by CWG in their outcome draft to which the
>> Board disagreed in its recent publication for public comments and I have
>> surprised to read that and thus asked to discuss that  matter in the agenda
>> of this evening ,30 December CALL
>>
>> *But my current understanding is that the Board/ICANN will not accept
>> such a proposal – indeed when I last spoke of it to a Board member, I was
>> told it was “unnecessary.” *
>>
>> COMMENT FROM KAVOUSS
>>
>> I do not understand why the Board will not accept that .They have told in
>> their views for public comment that " it is duplication of work " does it
>> means that any mechanism to properly address the replacement of NTIA for
>> IANA functions are duplication of work?
>> Does it mean that if no replacement is proposed and the function trusted
>> to ICANN without a clear responsibility and transparaency in an
>> acciountable manner it is not duplication ?
>> Are we exchanging  NTIA by ICANN ?
>> Under the current practice, at least ICANN is accountable to NTIA .
>> After the transition ICANN WOULD BE ACCOUNTABLE TO WHICH ENTITY?
>> This is a core issue and must be fully examined and resolved
>> Kavouss
>>
>>
>>
>> 2014-12-30 14:16 GMT+01:00 Paul Rosenzweig <
>> paul.rosenzweig at redbranchconsulting.com>:
>>
>>> Bruce
>>>
>>> Regarding your last below re: the seeking of consensus before spending
>>> on broadband, I think we have a fundamental disagreement.  Even if the
>>> entire community were to want to do that, ICANN would be the wrong
>>> mechanism for achieving that goal -- for much the same reason that we don't
>>> ask a Department of Education to manage the health care system in a
>>> country.  Both are important "good governance" functions but for reasons of
>>> expertise, focus and management we don't accept that.  For that reason I
>>> see it as essential to prevent as far as is practicable ICANN from straying
>>> beyond the IANA mission.  "Even the best intentions oft lead men astray."
>>>
>>> Paul
>>>
>>> **NOTE:  OUR NEW ADDRESS -- EFFECTIVE 12/15/14 ***
>>> 509 C St. NE
>>> Washington, DC 20002
>>>
>>> Paul Rosenzweig
>>> paul.rosenzweig at redbranchconsulting.com
>>> O: +1 (202) 547-0660
>>> M: +1 (202) 329-9650
>>> Skype: +1 (202) 738-1739 or paul.rosenzweig1066
>>> Link to my PGP Key
>>>
>>> -----Original Message-----
>>> From: Bruce Tonkin [mailto:Bruce.Tonkin at melbourneit.com.au]
>>> Sent: Tuesday, December 30, 2014 1:17 AM
>>> To: accountability-cross-community at icann.org
>>> Subject: Re: [CCWG-Accountability] CCWG-Accountability work team 2:
>>> draft 5.1
>>>
>>> Hello Paul,
>>>
>>>
>>> >>  I think Avri is exactly right – the solution set is binary.  If the
>>> >> Board/ICANN will accept in WS1 a proposl for a strong contractual
>>> boundary on what they may do along with an external mechanism that can be
>>> invoked by the community to police that boundary, then most of the other
>>> accountability can be in WS2.  But my current understanding is that the
>>> Board/ICANN will not accept such a proposal – indeed when I last spoke of
>>> it to a Board member, I was told it was “unnecessary.”
>>>
>>>
>>> I don’t think you should make that assumption yet.     There is a
>>> difference between the Board’s views in forming a new entity (Contract
>>> Co.)  to replace the NTIA, and the aboard agreeing to terms in contracts
>>> with the users of the IANA functions that may limit what it can do.
>>> There are already requirements on ICANN in the gTLD registry agreement for
>>> example:
>>>
>>> From:
>>> http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-09jan14-en.htm
>>>
>>> "Article 3 "COVENANTS OF ICANN"
>>>
>>>  ICANN covenants and agrees with Registry Operator as follows:
>>>
>>>       3.1           Open and Transparent. Consistent with ICANN’s
>>> expressed mission and core values, ICANN shall operate in an open and
>>> transparent manner.
>>>
>>>       3.2           Equitable Treatment.  ICANN shall not apply
>>> standards, policies, procedures or practices arbitrarily, unjustifiably, or
>>> inequitably and shall not single out Registry Operator for disparate
>>> treatment unless justified by substantial and reasonable cause.
>>>
>>>       3.3           TLD Nameservers.  ICANN will use commercially
>>> reasonable efforts to ensure that any changes to the TLD nameserver
>>> designations submitted to ICANN by Registry Operator (in a format and with
>>> required technical elements specified by ICANN at
>>> http://www.iana.org/domains/root/ will be implemented by ICANN within
>>> seven (7) calendar days or as promptly as feasible following technical
>>> verifications.
>>>
>>>       3.4           Root-zone Information Publication.  ICANN’s
>>> publication of root-zone contact information for the TLD will include
>>> Registry Operator and its administrative and technical contacts.  Any
>>> request to modify the contact information for the Registry Operator must be
>>> made in the format specified from time to time by ICANN at
>>> http://www.iana.org/domains/root/.
>>>
>>>       3.5           Authoritative Root Database.  To the extent that
>>> ICANN is authorized to set policy with regard to an authoritative root
>>> server system (the “Authoritative Root Server System”), ICANN shall use
>>> commercially reasonable efforts to (a) ensure that the authoritative root
>>> will point to the top-level domain nameservers designated by Registry
>>> Operator for the TLD, (b) maintain a stable, secure, and authoritative
>>> publicly available database of relevant information about the TLD, in
>>> accordance with ICANN publicly available policies and procedures, and (c)
>>> coordinate the Authoritative Root Server System so that it is operated and
>>> maintained in a stable and secure manner; provided, that ICANN shall not be
>>> in breach of this Agreement and ICANN shall have no liability in the event
>>> that any third party (including any governmental entity or internet service
>>> provider) blocks or restricts access to the TLD in any jurisdiction."
>>>
>>> As a result of recommendations from this working group - additional text
>>> could be  made part of the standard gTLD registry and registrar agreements.
>>>
>>>
>>> >>  And we have seen that ICANN sometimes has ambitions to do more than
>>> IANA – witness the proposal to spend money on broadband expansion.
>>>
>>> Yes - I believe that statement was a possible area of spending noted by
>>> the CEO.   I note however that it is  not part of any approved budget, and
>>> the Board would be seeking a consensus of the ICANN community before it
>>> authorised such expenditure from any auction proceeds.
>>>
>>> Regards,
>>> Bruce Tonkin
>>>
>>> _______________________________________________
>>> Accountability-Cross-Community mailing list
>>> Accountability-Cross-Community at icann.org
>>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>>
>>> _______________________________________________
>>> Accountability-Cross-Community mailing list
>>> Accountability-Cross-Community at icann.org
>>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>>
>>
>> _______________________________________________
>> Accountability-Cross-Community mailing list
>> Accountability-Cross-Community at icann.org
>> https://mm.icann.org/mailman/listinfo/accountability-cross-community
>>
>>
>


-- 
Sincerely
CARRIE Devorah
 562 688 2883



DISCLAIMER :
With the continuing crossing and interfacing of platforms both on & off
line both with & without our knowledge nor approval to note nothing sent
over the Internet anymore is ever private nor should be presumed to be so.
If it is that much of a secret, say nothing. If you must? Take a lesson
from our military- hand write the note, chew then swallow
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20141230/eef269b7/attachment.html>


More information about the Accountability-Cross-Community mailing list