[CWG-Stewardship] [IANA-issues] Fwd: Names Community vs the other two communities

Thu Oct 23 17:44:07 UTC 2014

Greg,

In what you suggested,

Can you clarify the rationale for transferring IANA to a ICANN subsidiary
and not to a new independent entity.

Is the rationale - continuity, ease and satisfaction with present IANA
services?
Or something else?

On Thu, Oct 23, 2014 at 10:55 PM, Guru Acharya <gurcharya at gmail.com> wrote:

> Greg,
>
> You suggest that IANA should be removed from ICANN and transferred to a
> new legal entity that is a wholly-owned subsidiary of ICANN. There can then
> be a SLA between ICANN and the subsidiary.
>
> I think I like this idea.
>
> But can you suggest a mechanism to ensure that the decision of changing
> the IANA operator from the subsidiary to a new entity in the future will
> rest with GNSO/CCSNO and not the ICANN board.
>
>
>
> On Thu, Oct 23, 2014 at 10:35 PM, Greg Shatan <gregshatanipc at gmail.com>
> wrote:
>
>> All,
>>
>> A few thoughts/suggestions in response to recent posts in this thread:
>>
>> 1.  *Make IANA a Subsidiary of ICANN*.  In order to promote structural
>> separation, and to allow for future separation of the IANA group from ICANN
>> should that become appropriate, IANA could become a wholly-owned subsidiary
>> of ICANN (rather than a department).  This would allow other entities to
>> contract directly with IANA, rather than contracting with ICANN for IANA
>> services.This would also make future separation easier (and should make the
>> threat of separation as an accountability mechanism more realistic).
>>
>> 2.  *All Stakeholder Groups should be part of the Entity/Group with
>> ICANN Oversight*.  Oversight of the IANA functions for the naming
>> community should not be left solely (or even primarily) to its direct
>> "customers."  An essential part of the multistakeholder construct is that
>> all Internet stakeholders (aka "the Global Multistakeholder Community") are
>> affected, directly or indirectly, by these matters.  This CWG is roughly
>> representative of those stakeholders.  Any group or entity designated or
>> created to hold steward/oversight responsibility should be similarly
>> representative.
>>
>> 3.  *An Unincorporated Association has Issues*.  It is true that the NFL
>> is an unincorporated association.  However, I believe that it uses
>> incorporated entities (e.g., NFL Media LLC, NFL Properties LLC, NFL
>> Enterprises LLC) or the the individual teams to enter into most (if not
>> all) contracts. (I believe that the income of the NFL itself (which
>> considers itself a trade association) is primarily dues from teams; all
>> other revenue flows elsewhere.)  Under US law, an unincorporated
>> association is not a legal entity apart from its individual members.  Thus,
>> unincorporated associations cannot enter into contracts unless the
>> unincorporated association's home State has specific enabling
>> unincorporated associations to enter into contracts.  (I don't know what
>> California law says on this matter, assuming one would want the
>> unincorporated association's "home" to be California.)  Also, individual
>> members of an unincorporated association have full personal liability for
>> the acts of the unincorporated association (in contrast to corporations and
>> other "limited liability" entities, which act as a shield against personal
>> liability under most circumstances)  I doubt that stakeholder groups or
>> representatives would want to assume personal liability for the acts of the
>> group.
>>
>> 4. *An Entity Immune from "Rogue" Litigation Attacks is also likely to
>> be Immune from Legitimate Litigation*. The issues of jurisdiction,
>> domicile, immunity, etc. are complex and beyond the scope of this email.
>> However, the idea that an entity can be immunized from rogue litigation
>> while still being subject to legitimate litigation is far-fetched.
>> Legitimate litigation is an important accountability mechanism (although a
>> relatively extreme one).  The threat of "rogue litigation" is overblown, in
>> my opinion, and is another "bogeyman" that should be avoided.  Most
>> litigation is not objectively frivolous or baseless; if it is, it will
>> likely be dismissed relatively quickly and there may be sanctions against
>> the plaintiffs and their counsel.  Furthermore, avoiding litigation is not
>> as easy as changing the state or country of incorporation -- there are
>> "long arm statutes" and many other ways of dragging defendants into court
>> as long as the entity or its activities have a reasonable nexus with the
>> location of the litigation.  If we are concerned about accountability, I
>> don't think we should be in the business of shielding entities from
>> litigation.
>>
>> Greg Shatan
>>
>> (Caveat:  Although I am a practicing attorney, I offer the above in my
>> personal capacity and it does not constitute legal advice.)
>>
>> On Thu, Oct 23, 2014 at 11:48 AM, Kris Seeburn <seeburn.k at gmail.com>
>> wrote:
>>
>>> Milton,
>>>
>>> Very much in agreement with you on this. I think in one of the threads
>>> it was also clear that coming back to the ccNSO, GNSO we are part of the
>>> ICANN entity itself and within the entity where ICANN does the naming.
>>> Obviously as one would say since ICANN has the required infrastructure to
>>> support the number resources where IANA comes in.
>>>
>>> IANA as much as sometimes Avri did mention is like we could call it a
>>> dept or the likes. But one thing important in this concept is that when it
>>> comes for the NRO - Numbering part the Policy is made from regional areas
>>> already and is brought in through the MoU and a converged decision. Somehow
>>> as i mentioned before it is slightly easier for them.
>>>
>>> Now coming down to the thinking process. From my RIR standpoint it was
>>> fine and still fine to have a contract - MoU for IANA to still be under
>>> ICANN to continue the management process. IETF is also another loose
>>> contract with ICANN for the IANA function. But IETF is also a core of the
>>> infrastructure of IANA. If they are not around things may crumble pretty
>>> much.
>>>
>>> From ALAC/NCUC the process is stalling as we seem to not formally
>>> realise that we are part of the beast - ICANN. The question is from the
>>> different SOs how do we ascertain the transparency and accountability
>>> process is maintained which means no government control and i think this
>>> can be achieved independently from having the GAC as part of the process
>>> and no direct government involvement.
>>>
>>> Perhaps one way to look at the problem is as much as we have setup this
>>> cross working group is a foresight answer to the problem already. Why not
>>> the CWG creates a council of membership from the different stakeholders in
>>> it and becomes the community that ensures the names part and maintain the
>>> accountability.
>>>
>>> As far as i remember these were the considerations:
>>>
>>> The considerations:
>>> (a) protection of the root zone from political or other improper
>>> interference;
>>> (b) integrity, stability, continuity, security and robustness of the
>>> administration of the root zone;
>>> (c) widespread [international] trust by Internet users in the
>>> administration of this function;
>>> (d) support of a single unified root zone; and
>>> (e) agreement regarding an accountability mechanism for this function
>>> that is broadly accepted as being in the global public interest.”
>>>
>>> As far as i remember these were the solutions characteristics:
>>>
>>> (a) offers a legal structure that is robust against rogue litigation
>>> attacks
>>> (b) is aligned with the Internet technical infrastructure in a way that
>>> supports innovative, technology based evolution of the DNS .
>>> (c) is an inclusive model
>>> (d) is a demonstrable improvement on current processes in this area
>>>
>>> If these are the core principles it should not take much time to
>>> accomplish a resolution. Legally stating can ccNSO, GNSO etc., create a
>>> legal, i am pretty much doubtful but we can create a council or something
>>> that can take the different SOs to be managing and ascertaining the same
>>> processes. IETF on the other hand is housed under ISOC. IETF would not be
>>> able to house us. We need to still bear in mind we are part of ICANN here.
>>> Unless we are looking at decoupling ourselves from ICANN which is not
>>> worth.
>>>
>>> We need to bear in mind IETF, IAB are closely housed into ISOC which is
>>> the entity /organisation that does the management / operational aspect.
>>>
>>> My two cents worth.
>>>
>>>
>>>
>>> On Oct 23, 2014, at 7:17 PM, Milton L Mueller <mueller at syr.edu> wrote:
>>>
>>>
>>>
>>> Fouad:
>>>
>>> By the “technical community proposals” I assume you mean the protocols
>>> community.
>>>
>>>
>>>
>>> What your argument misses is that IANA _*is*_ a separate organizational
>>> entity for both the numbers and protocols communities.
>>>
>>>
>>>
>>> The protocol community has an MoU with ICANN that authorizes ICANN to
>>> perform the IANA functions for them. That MoU can be revoked, and IETF can
>>> decide to use someone else. That is the perfect accountability mechanism.
>>> Now, tell me how the names community achieves that same wonderful state?
>>> There are two ways to do it: pull the IANA out of ICANN, or set up a new
>>> contracting authority to replace the NTIA, which could periodically award
>>> the contract to ICANN or to anyone else qualified.
>>>
>>>
>>>
>>> No one wants “the IANA technical and policy functions [might] fall into
>>> the hands and whims of governments.” That in fact is a requirement imposed
>>> on the transition by the NTIA. But we do need to make significant
>>> organizational changes if we are to meet the requirement of accountability.
>>> I think scare talk about take overs can divert our attention from needed
>>> reforms and I would resist that kind of talk.
>>>
>>>
>>>
>>> I don't think that IANA should be evolved as a separate entity at all
>>> and create new opportunities for bureaucracies for governments and industry
>>> control.
>>>
>>>
>>>
>>> The technical community proposals are highly reasonable to not make such
>>> a big fuss out of it and help IANA transition under a body that is somewhat
>>> messed up but can be improved in the long run however, ICANN would need
>>> some changes.
>>>
>>>
>>>
>>> The technical community has also shown its concern that it doesn't want
>>> the IANA technical and policy function to fall into the hands of the whims
>>> of governments because it functions to the technical community's needs
>>> adequately in its present environment and role.
>>>
>>>
>>>
>>> Your challenge and for the ICG is to propose that most transparent and
>>> accountable way forward that ensures an open and inclusive relationship
>>> with the Internet community treating stakeholders in their respective roles
>>> but not giving preference to one group over another another. I don't have
>>> to go through the Internet Governance ideals over and over again here.
>>>
>>>
>>>
>>> First ICANN Board control as the final word for IANA affairs would have
>>> to be reviewed and should be taken into a broader community review process.
>>> I do not trust the ICANN Board to be able to manage both ICANN and IANA in
>>> a transparent and accountable way, their progress over the years has had
>>> its own set of troubles already.
>>>
>>>
>>>
>>> The proposals are interesting but not the final word. The final word
>>> will remain with NTIA and thats my concern from a developing country member
>>> citizen perspective. I am going through a great deal of suggestions and
>>> proposals and all show a similar aspect, don't disturb the IANA technical
>>> function and the policies for IANA developed by the community have work so
>>> far but require more transparency, accountability and functional
>>> relationships with the community ensuring open and inclusive participation
>>> in its policy development processes.
>>>
>>>
>>>
>>> On Thu, Oct 23, 2014 at 7:27 PM, Seun Ojedeji <seun.ojedeji at gmail.com>
>>> wrote:
>>>
>>>  +1 Option 2 is preferred from my end also. However i also added Option
>>> 4 as a second preference just incase things get delayed with the
>>> accountability process.
>>>
>>> Cheers!
>>>
>>>
>>>
>>> On Thu, Oct 23, 2014 at 3:15 PM, Olivier MJ Crepin-Leblond <ocl at gih.com>
>>> wrote:
>>>
>>> Hello all,
>>>
>>> you might wish to see an expanded set of "Options", in a Google Doc
>>> which has been shared.
>>>
>>>
>>> https://docs.google.com/document/d/1B46mlsyZUFF4bZfeWgGCdqIQHCP2BMOy4KZU4RiRiE8/edit?usp=sharing
>>>
>>> So far, I note that the majority of our participants on the At-Large
>>> IANA Issues WG appears to prefer Option 2.
>>>
>>> Kind regards,
>>>
>>> Olivier
>>>
>>>
>>>
>>>  On 15/10/2014 22:55, Olivier MJ Crepin-Leblond wrote:
>>>
>>>  FYI
>>>
>>>
>>>
>>> -------- Forwarded Message --------
>>>
>>> *Subject: *
>>>
>>> [CWG-Stewardship] Names Community vs the other two communities
>>>
>>> *Date: *
>>>
>>> Thu, 16 Oct 2014 02:40:47 +0530
>>>
>>> *From: *
>>>
>>> Guru Acharya <gurcharya at gmail.com> <gurcharya at gmail.com>
>>>
>>> *To: *
>>>
>>> cwg-stewardship at icann.org
>>>
>>>
>>>
>>> How the names community approach will differ from the approach adopted
>>> by the numbers community and protocols community?
>>>
>>>
>>>
>>> Numbers Community: APNIC has reached consensus on its proposal.
>>> According to the proposal, IANA will continue to reside in ICANN. It
>>> proposes to replace NTIA oversight with a Service Level Agreement (SLA) and
>>> Affirmation of Commitment (AOC) between NRO and ICANN.
>>>
>>> www.slideshare.net/fullscreen/apnic/report-ianatransition/1
>>>
>>>
>>>
>>> Protocols Community: The IETF draft proposal suggests that no structural
>>> changes are required as a result of the transition. The MOU between ICANN
>>> and the IETF community will continue to govern the existing relationship.
>>> Again, IANA will continue to reside in ICANN.
>>>
>>> http://tools.ietf.org/html/draft-ietf-ianaplan-icg-response-00
>>>
>>>
>>>
>>> Therefore, neither the numbers community, nor the protocol community
>>> appear to be in the direction of suggesting a new MS Oversight Entity to
>>> replace NTIA and its oversight. Merely contracts between existing entities
>>> will be updated to replace NTIA oversight.
>>>
>>>
>>>
>>> Can the names community adopt a similar approach? Can a contractual
>>> agreement (SLA/AOC/MOU) between ICANN and GNSO/CCNSO be expected to replace
>>> NTIA oversight?
>>>
>>>
>>>
>>> Clearly NO! This approach can not be adopted by the names community
>>> because the names community resides within ICANN, which is also the IANA
>>> operator. Specifically, GNSO and CCNSO are essentially subsets of ICANN,
>>> and therefore a contractual agreement (SLA/AOC/MOU) between ICANN and
>>> GNSO/CCNSO can not be expected to replace NTIA oversight.
>>>
>>>
>>>
>>> Therefore, it is essential to either
>>>
>>>
>>>
>>> Option (i): create a new legal entity, which has a contractual oversight
>>> relationship with ICANN. This would be similar toÂ
>>> http://www.internetgovernance.org/2014/08/04/students-school-faculty-on-iana-transition-the-meissen-proposal/
>>>
>>>
>>>
>>> Option (ii): expect ICANN to self-regulate
>>>
>>>
>>>
>>> Option (iii): make a new legal entity comprising of CCNSO and GNSO that
>>> is structurally independent of ICANN and require that new entity to enter
>>> into a contractual oversight agreement (SLA/AOC/MOU) with ICANN.
>>>
>>>
>>>
>>> From the above three options, clearly option (ii) is not acceptable
>>> because of the lack of trust in the ICANN enhanced accountability process.
>>>
>>>
>>>
>>> I also feel that option (iii) is not feasible because the CCNSO and GNSO
>>> are heavily integrated with ICANN and structural separation of these two
>>> communities from ICANN will be in-feasible.
>>>
>>>
>>>
>>> Also, from the Jordan Carter document, the option on page 7 can be
>>> discarded, which makes ICANN the oversight body, as IANA will continue to
>>> reside in ICANN, as clearly suggested by the proposals of the protocols and
>>> numbers community.
>>>
>>>
>>>
>>> Therefore, option (i) is clearly the only option available with the
>>> names community.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Acharya
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>   _______________________________________________
>>>
>>> Iana-issues mailing list
>>>
>>> Iana-issues at atlarge-lists.icann.org
>>>
>>> https://mm.icann.org/mailman/listinfo/iana-issues
>>>
>>>
>>>
>>>  --
>>>
>>> Olivier MJ Crépin-Leblond, PhD
>>>
>>> http://www.gih.com/ocl.html
>>>
>>>
>>> _______________________________________________
>>> Iana-issues mailing list
>>> Iana-issues at atlarge-lists.icann.org
>>> https://mm.icann.org/mailman/listinfo/iana-issues
>>>
>>>
>>>
>>>
>>> --
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>> *Seun Ojedeji, Federal University Oye-Ekiti web:      *
>>> *http://www.fuoye.edu.ng <http://www.fuoye.edu.ng/> **Mobile:
>>> +2348035233535 <%2B2348035233535>*
>>> *alt email: <http://goog_1872880453/>seun.ojedeji at fuoye.edu.ng
>>> <seun.ojedeji at fuoye.edu.ng>*
>>>
>>> The key to understanding is humility - my view !
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Iana-issues mailing list
>>> Iana-issues at atlarge-lists.icann.org
>>> https://mm.icann.org/mailman/listinfo/iana-issues
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Regards.
>>> --------------------------
>>> Fouad Bajwa
>>> ICT4D and Internet Governance Advisor
>>> My Blog: Internet's Governance: http://internetsgovernance.blogspot.com/
>>> Follow my Tweets: http://twitter.com/fouadbajwa
>>>   _______________________________________________
>>> CWG-Stewardship mailing list
>>> CWG-Stewardship at icann.org
>>> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>>>
>>>
>>> Kris Seeburn
>>> seeburn.k at gmail.com
>>>
>>>    - www.linkedin.com/in/kseeburn/
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> CWG-Stewardship mailing list
>>> CWG-Stewardship at icann.org
>>> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>>>
>>>
>>
>> _______________________________________________
>> CWG-Stewardship mailing list
>> CWG-Stewardship at icann.org
>> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20141023/d342f7c3/attachment-0001.html>