[CWG-Stewardship] Names Community Organising Outside ICANN

Thu Oct 23 16:21:23 UTC 2014

Please keep in mind that ccTLDs are direct consumers of IANA services.
Not all ccTLDs participate in the ccNSO, so we would probably look to
regional cc organizations and other mechanisms, along with the ccNSO, to
populate a User Council

J. Beckwith Burr
Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer
1775 Pennsylvania Avenue NW, Washington, DC 20006
Office: + 1.202.533.2932  Mobile:  +1.202.352.6367  /
becky.burr at neustar.biz / www.neustar.biz

On 10/23/14, 11:25 AM, "Fouad Bajwa" <fouadbajwa at gmail.com> wrote:

><html>
>There is a lot of sense in here.
>
>Its very close to what I personally feel that IANA at this stage
>should not evolve into a separate entity without a good deal of
>working that is not achievable in an open community process by
>September 2015 however if a clause for separability was developed and
>kept in the proposal and then later and somehow a consensus process or
>approach was to approve such, it can be considered.
>
>Lets strip it out of ICANN isn't workable and I would not support it.
>The proposal should show a way forward for the longterm and that
>should include a mechanism (however hard it may be). One fact remains,
>ICANN is a non-profit under US law. Putting IANA completely under it
>is again prone to law affects on ICANN and vice versa. That discussion
>has somehow disappeared to the ATRT process.
>
>For the IANA function transition in an open and inclusive manner, it
>does have to move out of under ICANN's complete remit, but how,
>remains the big question.
>
>On Thu, Oct 23, 2014 at 10:31 AM, Guru Acharya <gurcharya at gmail.com>
>wrote:
>> I forward below a vital discussion that is happening outside CWG but
>>relates
>> to the names proposal.
>>
>> I've added Avri's suggestion as Option 5 here:
>> 
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docu
>>ment_d_1B46mlsyZUFF4bZfeWgGCdqIQHCP2BMOy4KZU4RiRiE8_edit-3Fusp-3Dsharing&
>>d=AAICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WD
>>DkMr4k&m=mAM3fpCe8ntqOvhhLrNVhfECnWeKnvVY0waB0wsWNBM&s=gryS0O3RHxT2DFBtbF
>>3pj6kqXcgOMPGZI3YHiIZONQM&e=
>>
>> ---------- Forwarded message ----------
>> From: Avri Doria <avri at acm.org>
>> Date: Thu, Oct 23, 2014 at 9:07 AM
>> Subject: Re: [ianatransition] [] A thought re accountability...
>> To: ianatransition at icann.org
>>
>>
>> Hi,
>>
>> Well if the GNSO and ccNSO can't leave ICANN, maybe the IANA could
>>leave if
>> necessary.  Wasn't that always the point of the NTIA being able to
>>transfer
>> the contract?  So if we want to keep things similar, we need to
>>maintain the
>> ability for the contract to move from ICANN to another organization, or
>> perhaps to a standalone organization.  We need 'separability' of the
>>IANA
>> function to remain one of its attributes.
>>
>> Stability and security demand that it stay where it is for the moment.
>>But
>> I believe that one outcome of the transition should be that it remains
>>as
>> separable as it is now.  It  must be separable from ICANN if things go
>> badly.  Just as IETF can move its data to somewhere else it the
>>relationship
>> with ICANN turns sour, the GNSO and ccNSO should be able to move their
>>data
>> to somewhere else.  Personally I do not believe multiple little IANAs
>>is the
>> best solution so perhaps we need something similar to the ICG on a
>>periodic
>> basis (e.g. 5 years) to be created from the various parts of the
>>community
>> to review the performance, the audit reports, consultation based
>>evidence
>> &c. and to decide whether changes are required.  These changes could be
>> minor fixes or could be major and involve transfering the
>>responsibility.
>>
>> Such a mechanism based solution would be easier to craft than one that
>> invovles creating yet another permanent superstructure that serves the
>>same
>> set of stakeholders involved in the current operational communities.
>>The
>> idea that we would create an oversight for ICANN somewhat like ICANN
>>itself
>> reminds me of tortoises stacked on the backs of tortoises all the way
>>up as
>> we reach for true accountabity.  It would also not create a new
>>organization
>> with the risk that brings of recapitulating ICANNs all the way up.
>>
>> A separability mechanism gives the GNSO and ccNSO the same ability that
>>the
>> IETF and the RIRs have of finding another provider if necessary.  And
>> working together with the advice and participation of global
>>stakeholders, a
>> decision can be made periodically on whether it has become necessary to
>>do
>> so.  One thing we have to remember, it is not ICANN the corporation
>>that is
>> the operational policy community for names.  It is the GNSO and the
>>ccNSO
>> and the advising AC's that are.  Just as the ICG does not require the
>>ICANN
>> Board's approval before sending its decision to the NTIA, so to this
>> periodic review committee of IETF, RIRs, GNSO ccNSO and related policy
>> advice mechanisms from the I* ecosystem, like ISOC, ALAC, GAC, SSAC,
>>RSSAC,
>> & others, would not require ICANN Board approval to move the IANA
>>function.
>>
>> There may be some legal issues to be resolved in the creation of such a
>> mechanism, again the problem of how does one make ICANN corporate do
>>what
>> ICANN corporate doesn't want to do.  Perhaps the construction of an IANA
>> trust to hold the contract, could solve that problem.
>>
>> Just a thought.
>>
>> avri
>>
>>
>>
>> On 18-Oct-14 12:39, Milton L Mueller wrote:
>>
>> I'm not Jordan but will answer this anyway ;-)
>>
>> I would say it is _possible_.
>>
>> The problem is that moving GNSO and CCNSO out of ICANN at this point
>>would
>> involve such a complex set of organizational arrangements and such
>> destabilizing potential for power shifts among the stakeholder groups
>> involved that it could not be contemplated within anything like the time
>> frame we have.
>> Would it involve the creation of a new board? What would happen to GAC
>>and
>> ALAC? Just 2 examples of the kind of knotty questions that would have
>>to be
>> answered.
>>
>> --MM
>>
>> -----Original Message-----
>> On Oct 15, 2014, at 3:18 PM, Jordan Carter <jordan at internetnz.net.nz>
>> wrote:
>>
>> If we are going to have a successful transition, it's really important
>>for
>> the
>>
>> numbers and protocols folks to understand that:
>>
>> ...
>> b) the names people cannot copy number/protocol accountability
>> mechanisms because they aren't organised outside ICANN
>> c) it isn't possible for names to organise outside ICANN in the way
>> numbers/protocol people do
>>
>> Jordan -
>>
>>    Could you elaborate on why "c" isn't possible?
>>
>>
>>
>> -----Original Message-----
>> On Oct 15, 2014, at 3:18 PM, Jordan Carter <jordan at internetnz.net.nz>
>> wrote:
>>
>>
>> A thought that has been bubbling away here at ICANN LA this week for me:
>>
>> If we are going to have a successful transition, it's really important
>>for
>> the numbers and protocols folks to understand that:
>>
>> a) they have superior accountability situations to the names people
>>today
>> b) the names people cannot copy number/protocol accountability
>>mechanisms
>> because they aren't organised outside ICANN
>> c) it isn't possible for names to organise outside ICANN in the way
>> numbers/protocol people do
>> d) there may need to be structural changes or new bodies to provide a
>> workable settlement for names
>> e) without a workable settlement for names, there isn't going to be a
>> transition.
>>
>> I raise this now because both for numbers and protocols there's a clear
>> direction to try and rule out any institutional changes.
>>
>> I strongly caution against any part of the community being dogmatic
>>about
>> any of these, because it will a) attract some attention that'll risk the
>> whole transition process failing (esp. from governments), and b) means
>>that
>> a negotiated outcome is harder to achieve, also risking failure.
>>
>> Wonder how others feel about this.
>>
>> cheers
>> Jordan
>>
>>
>> _______________________________________________
>> ianatransition mailing list
>> ianatransition at icann.org
>> 
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman
>>_listinfo_ianatransition&d=AAICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X
>>_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=mAM3fpCe8ntqOvhhLrNVhfECnWeKnvVY0waB0ws
>>WNBM&s=-ge3EpigdzQz2oyM0oCQRck1D0kWadDR66UQiGsLMZ8&e=
>>
>>
>>
>> _______________________________________________
>> CWG-Stewardship mailing list
>> CWG-Stewardship at icann.org
>> 
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman
>>_listinfo_cwg-2Dstewardship&d=AAICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifz
>>m6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=mAM3fpCe8ntqOvhhLrNVhfECnWeKnvVY0waB
>>0wsWNBM&s=hCJS8R-BnYCY-3kP5ja_wUmQRYEOgQ2FiEhP2WUeKdY&e=
>>
>
>
>
>-- 
>Regards.
>--------------------------
>Fouad Bajwa
>ICT4D and Internet Governance Advisor
>My Blog: Internet's Governance:
>https://urldefense.proofpoint.com/v2/url?u=http-3A__internetsgovernance.bl
>ogspot.com_&d=AAICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDm
>rxdYahOP8WDDkMr4k&m=mAM3fpCe8ntqOvhhLrNVhfECnWeKnvVY0waB0wsWNBM&s=COUB1Cw3
>2UBGt1M1fKyEFHvNpYfxl2YIfS1VPPaoeo4&e=
>Follow my Tweets: 
>https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_fouadbajwa
>&d=AAICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WD
>DkMr4k&m=mAM3fpCe8ntqOvhhLrNVhfECnWeKnvVY0waB0wsWNBM&s=KxdplrL3PyD20Y0K-is
>7ywdUkgumbvdLll0WSmxGn_Y&e=
>_______________________________________________
>CWG-Stewardship mailing list
>CWG-Stewardship at icann.org
>https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_
>listinfo_cwg-2Dstewardship&d=AAICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6
>X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=mAM3fpCe8ntqOvhhLrNVhfECnWeKnvVY0waB0ws
>WNBM&s=hCJS8R-BnYCY-3kP5ja_wUmQRYEOgQ2FiEhP2WUeKdY&e= 