The Board's take on the Mission Statement
I have run a comparison between the Mission Statement with respect to names, which has been on the table since January of this year, and the Board’s proposed substitute. In doing so, I have set aside totally the difficult wording issues relating to regulatory prohibition and contracting authority. I am also setting aside, for the moment, Alan G’s concern regarding the bottom–up policy development language (which I believe is addressed through the contracting language). By any measure, the changes are significant. Because the fundamental role of the IRP is to ensure that ICANN stays within its Mission, the changes in the Mission statement directly impact the effectiveness of the “crown jewels” of this accountability exercise. I have asked Bruce to explain what is encompassed by "the allocation and assignment of names in the root zone” that is not covered by “coordination of the development and implantation of policies.” I encourage each of you to study the side-by-side comparison attached to determine for yourself whether the Board’s approach is consistent with the goals of clarifying ICANN’s limited Mission. [cid:50016878-9AD1-4B24-93CE-645E1C14EDEF] J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: +1.202.533.2932 Mobile: +1.202.352.6367 / neustar.biz<http://www.neustar.biz>
On Dec 16, 2015 17:00, "Burr, Becky" <Becky.Burr@neustar.biz> wrote:
I have asked Bruce to explain what is encompassed by "the allocation
and assignment of names in the root zone” that is not covered by “coordination of the development and implantation of policies.”
SO(Not Bruce): The former is an action item in relation to RZ, the later is means to the former. We may be concerned if just the former is preferred but from your pasted table, I see that both was accommodated. I hope no one would argue that ICANN performs 2 main roles in relation to names; 1. Coordinate development and implementation of policies 2. Allocate names to the root zone So I don't see anything wrong in trying to reflect its actual role if indeed the goal is to ensure clarity on role. Regards
I encourage each of you to study the side-by-side comparison attached to determine for yourself whether the Board’s approach is consistent with the goals of clarifying ICANN’s limited Mission.
J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: +1.202.533.2932 Mobile: +1.202.352.6367 / neustar.biz
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
My question, Seun, is why that is not already covered by implementation of policy. I surely do not have an objection to ICANN allocating and assigning names in the root zone consistent with applicable policy (e.g., New gTLD PDP, RFC 1591 in the case of ccTLDs), but absent that caveat, the addition seems potentially broad. J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: +1.202.533.2932 Mobile: +1.202.352.6367 / neustar.biz<http://www.neustar.biz> From: Seun Ojedeji <seun.ojedeji@gmail.com<mailto:seun.ojedeji@gmail.com>> Date: Wednesday, December 16, 2015 at 11:26 AM To: Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>> Cc: Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: Re: [CCWG-ACCT] The Board's take on the Mission Statement On Dec 16, 2015 17:00, "Burr, Becky" <Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>> wrote:
I have asked Bruce to explain what is encompassed by "the allocation and assignment of names in the root zone” that is not covered by “coordination of the development and implantation of policies.”
SO(Not Bruce): The former is an action item in relation to RZ, the later is means to the former. We may be concerned if just the former is preferred but from your pasted table, I see that both was accommodated. I hope no one would argue that ICANN performs 2 main roles in relation to names; 1. Coordinate development and implementation of policies 2. Allocate names to the root zone So I don't see anything wrong in trying to reflect its actual role if indeed the goal is to ensure clarity on role. Regards
I encourage each of you to study the side-by-side comparison attached to determine for yourself whether the Board’s approach is consistent with the goals of clarifying ICANN’s limited Mission.
J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: +1.202.533.2932 Mobile: +1.202.352.6367 / neustar.biz<http://neustar.biz>
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_accountability-2Dcross-2Dcommunity&d=CwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=I_lsQXHH-_-YpVvnJPiJR-So7R07mgx9CAvYeXCUPlg&s=Ghv7wcAWeQryJQcT-w63p2pW38WmDtFSBwUET-1SVg4&e=>
Okay I see the point, so it's really not about asking why role 2 (as I listed) is not covered in policy implementation because they are 2 distinct roles. It's more about asking why the dependencies are not evident in the current wording of the 2 roles. Regards My question, Seun, is why that is not already covered by implementation of policy. I surely do not have an objection to ICANN allocating and assigning names in the root zone consistent with applicable policy (e.g., New gTLD PDP, RFC 1591 in the case of ccTLDs), but absent that caveat, the addition seems potentially broad. *J. Beckwith Burr* *Neustar, Inc.* / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 *Office:* +1.202.533.2932 *Mobile:* +1.202.352.6367 */* *neustar.biz* <http://www.neustar.biz> From: Seun Ojedeji <seun.ojedeji@gmail.com> Date: Wednesday, December 16, 2015 at 11:26 AM To: Becky Burr <becky.burr@neustar.biz> Cc: Accountability Community <accountability-cross-community@icann.org> Subject: Re: [CCWG-ACCT] The Board's take on the Mission Statement On Dec 16, 2015 17:00, "Burr, Becky" <Becky.Burr@neustar.biz> wrote:
I have asked Bruce to explain what is encompassed by "the allocation
and assignment of names in the root zone” that is not covered by “coordination of the development and implantation of policies.”
SO(Not Bruce): The former is an action item in relation to RZ, the later is means to the former. We may be concerned if just the former is preferred but from your pasted table, I see that both was accommodated. I hope no one would argue that ICANN performs 2 main roles in relation to names; 1. Coordinate development and implementation of policies 2. Allocate names to the root zone So I don't see anything wrong in trying to reflect its actual role if indeed the goal is to ensure clarity on role. Regards
I encourage each of you to study the side-by-side comparison attached to determine for yourself whether the Board’s approach is consistent with the goals of clarifying ICANN’s limited Mission.
J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: +1.202.533.2932 Mobile: +1.202.352.6367 / neustar.biz
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li...>
Dear Becky Thank you very much for the comparative works I have noted that a major part as contained in CCWG bullets are proposed to be removed. These are important points and must be retained Kavouss 2015-12-16 18:27 GMT+01:00 Seun Ojedeji <seun.ojedeji@gmail.com>:
Okay I see the point, so it's really not about asking why role 2 (as I listed) is not covered in policy implementation because they are 2 distinct roles. It's more about asking why the dependencies are not evident in the current wording of the 2 roles.
Regards My question, Seun, is why that is not already covered by implementation of policy. I surely do not have an objection to ICANN allocating and assigning names in the root zone consistent with applicable policy (e.g., New gTLD PDP, RFC 1591 in the case of ccTLDs), but absent that caveat, the addition seems potentially broad.
*J. Beckwith Burr* *Neustar, Inc.* / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 *Office:* +1.202.533.2932 *Mobile:* +1.202.352.6367 */* *neustar.biz* <http://www.neustar.biz>
From: Seun Ojedeji <seun.ojedeji@gmail.com> Date: Wednesday, December 16, 2015 at 11:26 AM To: Becky Burr <becky.burr@neustar.biz> Cc: Accountability Community <accountability-cross-community@icann.org> Subject: Re: [CCWG-ACCT] The Board's take on the Mission Statement
On Dec 16, 2015 17:00, "Burr, Becky" <Becky.Burr@neustar.biz> wrote:
I have asked Bruce to explain what is encompassed by "the allocation
and assignment of names in the root zone” that is not covered by “coordination of the development and implantation of policies.”
SO(Not Bruce): The former is an action item in relation to RZ, the later is means to the former. We may be concerned if just the former is preferred but from your pasted table, I see that both was accommodated.
I hope no one would argue that ICANN performs 2 main roles in relation to names; 1. Coordinate development and implementation of policies 2. Allocate names to the root zone
So I don't see anything wrong in trying to reflect its actual role if indeed the goal is to ensure clarity on role.
Regards
I encourage each of you to study the side-by-side comparison attached to determine for yourself whether the Board’s approach is consistent with the goals of clarifying ICANN’s limited Mission.
J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: +1.202.533.2932 Mobile: +1.202.352.6367 / neustar.biz
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li...>
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Hello Becky, The addition of "allocation and assignment of names" was intended to capture the role of putting names in the root zone including new gTLDs and IDN-ccTLDs." I accept that this could be considered as part of "implementation of policies" = but it was trying to be more specific. If you are concerned about the language you could reword like: "coordinate the development and implementation of polices (including the allocation and assignment of names in the root zone as a result of those policies). " Speaking personally I have no issue with also including the last two paragraphs in your note below which is really a limitation on what policies can be created and how they should be created. This text is really lifted from the registry and registrar agreements so ICANN has already committed to that. It is not something that we as a board directly discussed. Regards, Bruce Tonkin From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Burr, Becky Sent: Thursday, 17 December 2015 3:00 AM To: Accountability Community <accountability-cross-community@icann.org> Subject: [CCWG-ACCT] The Board's take on the Mission Statement I have run a comparison between the Mission Statement with respect to names, which has been on the table since January of this year, and the Board's proposed substitute. In doing so, I have set aside totally the difficult wording issues relating to regulatory prohibition and contracting authority. I am also setting aside, for the moment, Alan G's concern regarding the bottom-up policy development language (which I believe is addressed through the contracting language). By any measure, the changes are significant. Because the fundamental role of the IRP is to ensure that ICANN stays within its Mission, the changes in the Mission statement directly impact the effectiveness of the "crown jewels" of this accountability exercise. I have asked Bruce to explain what is encompassed by "the allocation and assignment of names in the root zone" that is not covered by "coordination of the development and implantation of policies." I encourage each of you to study the side-by-side comparison attached to determine for yourself whether the Board's approach is consistent with the goals of clarifying ICANN's limited Mission. [cid:image001.png@01D13907.5FF1EE20] J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: +1.202.533.2932 Mobile: +1.202.352.6367 / neustar.biz<http://www.neustar.biz>
On 2015-12-17 09:13, Bruce Tonkin wrote:
Speaking personally I have no issue with also including the last two paragraphs in your note below which is really a limitation on what policies can be created and how they should be created. This text is really lifted from the registry and registrar agreements so ICANN has already committed to that. It is not something that we as a board directly discussed.
I must say I find it somewhat shocking that the Board returned to us a counter-proposal that deletes such an important element without even directly discussing the deletion. Here in the CCWG we engage in a kind of Kremlinology, poring over the details of Board statements to try and figure out their inner-meaning and exactly what the Board wants or will accept. If such a deletion is driven not by a desire to avoid that text for a motivation at which we must guess, but instead by mere inadvertence or thoughtlessness, I am much less inclined to give supervening weight to the Board's input. Malcolm.
Regards,
Bruce Tonkin
FROM: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] ON BEHALF OF Burr, Becky SENT: Thursday, 17 December 2015 3:00 AM TO: Accountability Community <accountability-cross-community@icann.org> SUBJECT: [CCWG-ACCT] The Board's take on the Mission Statement
I have run a comparison between the Mission Statement with respect to names, which has been on the table since January of this year, and the Board's proposed substitute. In doing so, I have set aside totally the difficult wording issues relating to regulatory prohibition and contracting authority. I am also setting aside, for the moment, Alan G's concern regarding the bottom-up policy development language (which I believe is addressed through the contracting language). By any measure, the changes are significant. Because the fundamental role of the IRP is to ensure that ICANN stays within its Mission, the changes in the Mission statement directly impact the effectiveness of the "crown jewels" of this accountability exercise.
I have asked Bruce to explain what is encompassed by "the allocation and assignment of names in the root zone" that is not covered by "coordination of the development and implantation of policies."
I encourage each of you to study the side-by-side comparison attached to determine for yourself whether the Board's approach is consistent with the goals of clarifying ICANN's limited Mission.
J. BECKWITH BURR NEUSTAR, INC. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 OFFICE: +1.202.533.2932 MOBILE: +1.202.352.6367 / NEUSTAR.BIZ [1]
Links: ------ [1] http://www.neustar.biz
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
-- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd 21-27 St Thomas Street, London SE1 9RY Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA
The addition of "allocation and assignment of names" was intended to capture the role of putting names in the root zone including new gTLDs and IDN-ccTLDs." I accept that this could be considered as part of "implementation of policies" = but it was trying to be more specific. MM: But in fact, that is no longer an essential or exclusive part of ICANN's mission. Names are put into the root zone by the IANA functions operator. ICANN may or may not be the IANA functions operator for names in the future. Many of the changes in the mission statement called for by the IAB and ISOC were predicated on the fact that ICANN is not presumed to be the IFO.
Which is why it is part of the current scop of responsibilities that can change over time, and not part of the mission statement that should be much more stable. Regards, Bruce Tonkin From: Mueller, Milton L [mailto:milton@gatech.edu] Sent: Friday, 18 December 2015 7:35 AM To: Bruce Tonkin <Bruce.Tonkin@melbourneit.com.au>; Accountability Community <accountability-cross-community@icann.org> Subject: RE: The Board's take on the Mission Statement The addition of "allocation and assignment of names" was intended to capture the role of putting names in the root zone including new gTLDs and IDN-ccTLDs." I accept that this could be considered as part of "implementation of policies" = but it was trying to be more specific. MM: But in fact, that is no longer an essential or exclusive part of ICANN's mission. Names are put into the root zone by the IANA functions operator. ICANN may or may not be the IANA functions operator for names in the future. Many of the changes in the mission statement called for by the IAB and ISOC were predicated on the fact that ICANN is not presumed to be the IFO.
On 17 Dec 2015, at 20:48, Bruce Tonkin <Bruce.Tonkin@melbourneit.com.au> wrote:
Which is why it is part of the current scop of responsibilities that can change over time, and not part of the mission statement that should be much more stable.
Is this meant as confirmation that the things the Board wants to designate as "Scope of Responsibilities" rather than "Mission" it would not want to have the status of "Fundamental Bylaws"?
Regards, Bruce Tonkin
From: Mueller, Milton L [mailto:milton@gatech.edu] Sent: Friday, 18 December 2015 7:35 AM To: Bruce Tonkin <Bruce.Tonkin@melbourneit.com.au>; Accountability Community <accountability-cross-community@icann.org> Subject: RE: The Board's take on the Mission Statement
The addition of “allocation and assignment of names” was intended to capture the role of putting names in the root zone including new gTLDs and IDN-ccTLDs.”
I accept that this could be considered as part of “implementation of policies” = but it was trying to be more specific.
MM: But in fact, that is no longer an essential or exclusive part of ICANN’s mission. Names are put into the root zone by the IANA functions operator. ICANN may or may not be the IANA functions operator for names in the future. Many of the changes in the mission statement called for by the IAB and ISOC were predicated on the fact that ICANN is not presumed to be the IFO.
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Malcolm, No. We have no problem with having the Scope of Responsibilities be fundamental bylaws, and that obviously means we expect the Scope of Responsibilities to be fairly stable. Changes to the Scope of Responsibilities should require careful deliberation and considered action by the community as well as the Board. The Mission Statement should be even more stable and hardly ever require amendment. Steve On Dec 17, 2015, at 5:39 PM, Malcolm Hutty <malcolm@linx.net> wrote:
On 17 Dec 2015, at 20:48, Bruce Tonkin <Bruce.Tonkin@melbourneit.com.au> wrote:
Which is why it is part of the current scop of responsibilities that can change over time, and not part of the mission statement that should be much more stable.
Is this meant as confirmation that the things the Board wants to designate as "Scope of Responsibilities" rather than "Mission" it would not want to have the status of "Fundamental Bylaws"?
Regards, Bruce Tonkin
From: Mueller, Milton L [mailto:milton@gatech.edu] Sent: Friday, 18 December 2015 7:35 AM To: Bruce Tonkin <Bruce.Tonkin@melbourneit.com.au>; Accountability Community <accountability-cross-community@icann.org> Subject: RE: The Board's take on the Mission Statement
The addition of “allocation and assignment of names” was intended to capture the role of putting names in the root zone including new gTLDs and IDN-ccTLDs.”
I accept that this could be considered as part of “implementation of policies” = but it was trying to be more specific.
MM: But in fact, that is no longer an essential or exclusive part of ICANN’s mission. Names are put into the root zone by the IANA functions operator. ICANN may or may not be the IANA functions operator for names in the future. Many of the changes in the mission statement called for by the IAB and ISOC were predicated on the fact that ICANN is not presumed to be the IFO.
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
On 17 Dec 2015, at 22:44, Steve Crocker <steve@shinkuro.com> wrote:
Malcolm,
No. We have no problem with having the Scope of Responsibilities be fundamental bylaws, and that obviously means we expect the Scope of Responsibilities to be fairly stable. Changes to the Scope of Responsibilities should require careful deliberation and considered action by the community as well as the Board. The Mission Statement should be even more stable and hardly ever require amendment.
Steve
Thank you, Steve.
No. We have no problem with having the Scope of Responsibilities be fundamental bylaws, MM: As noted in my previous message, I do have a problem if the scope includes non-core, nonexclusive things that ICANN does. and that obviously means we expect the Scope of Responsibilities to be fairly stable. Changes to the Scope of Responsibilities should require careful deliberation and considered action by the community as well as the Board. The Mission Statement should be even more stable and hardly ever require amendment. MM: For ICANN to include its role as IFO as a fundamental bylaw is a backdoor way of resisting and denying one of the most critical reforms of the IANA transition, namely the legal and structural separation of IFO from ICANN and the principle of separability. Sorry, Steve, that isn't going to happen. Besides, to wrest IANA away from ICANN requires a massively complex process that certainly already qualifies as "careful deliberation and considered action."
On Dec 18, 2015 3:15 AM, "Mueller, Milton L" <milton@gatech.edu> wrote:
No. We have no problem with having the Scope of Responsibilities be
fundamental bylaws,
MM: As noted in my previous message, I do have a problem if the scope
includes non-core, nonexclusive things that ICANN does.
SO: +1 to this, so it's a matter of checking if the text in the scope is indeed out of remit of ICANN's actual role and responsibilities. Nevermind that this is a repetition of what I had earlier mentioned.
and that obviously means we expect the Scope of Responsibilities to be
fairly stable. Changes to the Scope of Responsibilities should require careful deliberation and considered action by the community as well as the Board. The Mission Statement should be even more stable and hardly ever require amendment.
MM: For ICANN to include its role as IFO as a fundamental bylaw is a
backdoor way of resisting and denying one of the most critical reforms of the IANA transition, namely the legal and structural separation of IFO from ICANN and the principle of separability. Sorry, Steve, that isn’t going to happen. Besides, to wrest IANA away from ICANN requires a massively complex process that certainly already qualifies as “careful deliberation and considered action.”
SO: Okay this seem to be becoming wired to me as I no longer understand the intent here, are you saying that ICANN would seize to be the IFO(logically) post-transition? If the intent is to somehow recognise the subsidiary of ICANN (PTI) as the IFO in the fundamental bylaw then I agree otherwise I think having things embedded in fundamental bylaw is most appropriate security because these in itself is a literally fundamental issues of the organisation structure and should be treated as such. Regards
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Let's not forgot what ICANN's Articles of Incorporation (a more foundational and fundamental document than any Bylaw) say in Section 3: "the Corporation shall, except as limited by Article 5 hereof, pursue the charitable and public purposes of lessening the burdens of government and promoting the global public interest in the operational stability of the Internet by (i) coordinating the assignment of Internet technical parameters as needed to maintain universal connectivity on the Internet; (ii) performing and overseeing functions related to the coordination of the Internet Protocol ("IP") address space; (iii) performing and overseeing functions related to the coordination of the Internet domain name system (" DNS"), including the development of policies for determining the circumstances under which new top-level domains are added to the DNS root system; (iv) overseeing operation of the authoritative Internet DNS root server system...." If my recollection is correct, neither the CWG or the CCWG has proposed changing the Articles of Incorporation. This is a statement of ICANN's purposes, until these are no longer ICANN's purposes. Also, let's not forget that PTI is a "controlled affiliate" of ICANN -- a single member corporation in which ICANN is the sole member (i.e., a *de facto* wholly-owned subsidary of ICANN) -- and will be treated as such until a "separation" decision is made. PTI isolates the IANA functions from ICANN, structurally and legally, in order to enhance separability and accountability. It overstates the case to say that the "Post-Transition IANA" is separated from ICANN. That term should be reserved for the time when ICANN is no longer the "parent" of PTI. Greg On Fri, Dec 18, 2015 at 12:05 AM, Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
On Dec 18, 2015 3:15 AM, "Mueller, Milton L" <milton@gatech.edu> wrote:
No. We have no problem with having the Scope of Responsibilities be
fundamental bylaws,
MM: As noted in my previous message, I do have a problem if the scope
includes non-core, nonexclusive things that ICANN does.
SO: +1 to this, so it's a matter of checking if the text in the scope is indeed out of remit of ICANN's actual role and responsibilities. Nevermind that this is a repetition of what I had earlier mentioned.
and that obviously means we expect the Scope of Responsibilities to be
fairly stable. Changes to the Scope of Responsibilities should require careful deliberation and considered action by the community as well as the Board. The Mission Statement should be even more stable and hardly ever require amendment.
MM: For ICANN to include its role as IFO as a fundamental bylaw is a
backdoor way of resisting and denying one of the most critical reforms of the IANA transition, namely the legal and structural separation of IFO from ICANN and the principle of separability. Sorry, Steve, that isn’t going to happen. Besides, to wrest IANA away from ICANN requires a massively complex process that certainly already qualifies as “careful deliberation and considered action.”
SO: Okay this seem to be becoming wired to me as I no longer understand the intent here, are you saying that ICANN would seize to be the IFO(logically) post-transition? If the intent is to somehow recognise the subsidiary of ICANN (PTI) as the IFO in the fundamental bylaw then I agree otherwise I think having things embedded in fundamental bylaw is most appropriate security because these in itself is a literally fundamental issues of the organisation structure and should be treated as such.
Regards
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
On Dec 18, 2015 7:27 AM, "Greg Shatan" <gregshatanipc@gmail.com> wrote:
. It overstates the case to say that the "Post-Transition IANA" is
separated from ICANN. That term should be reserved for the time when ICANN is no longer the "parent" of PTI.
SO: FWIW my +1 to the above statement as it's inline with my understanding as well. That said, I expect that legal wordings will be in place to ensure that IANA functions operation does not unilaterally get moved by ICANN from PTI to another department within ICANN. If that is what Milton is trying to say then I agree to that intent(even though it's outrageous scenario) and I believe that should be a fundamental bylaw text. Regards
Greg
On Fri, Dec 18, 2015 at 12:05 AM, Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
On Dec 18, 2015 3:15 AM, "Mueller, Milton L" <milton@gatech.edu> wrote:
No. We have no problem with having the Scope of Responsibilities be
fundamental bylaws,
MM: As noted in my previous message, I do have a problem if the scope
includes non-core, nonexclusive things that ICANN does.
SO: +1 to this, so it's a matter of checking if the text in the scope is indeed out of remit of ICANN's actual role and responsibilities. Nevermind that this is a repetition of what I had earlier mentioned.
and that obviously means we expect the Scope of Responsibilities to be
fairly stable. Changes to the Scope of Responsibilities should require careful deliberation and considered action by the community as well as the Board. The Mission Statement should be even more stable and hardly ever require amendment.
MM: For ICANN to include its role as IFO as a fundamental bylaw is a
backdoor way of resisting and denying one of the most critical reforms of the IANA transition, namely the legal and structural separation of IFO from ICANN and the principle of separability. Sorry, Steve, that isn’t going to happen. Besides, to wrest IANA away from ICANN requires a massively complex process that certainly already qualifies as “careful deliberation and considered action.”
SO: Okay this seem to be becoming wired to me as I no longer understand the intent here, are you saying that ICANN would seize to be the IFO(logically) post-transition? If the intent is to somehow recognise the subsidiary of ICANN (PTI) as the IFO in the fundamental bylaw then I agree otherwise I think having things embedded in fundamental bylaw is most appropriate security because these in itself is a literally fundamental issues of the organisation structure and should be treated as such.
Regards
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Dear All, Never ever at any organisation the " Mission 2 is replaced by" Scope of responsibility" they are entirely two different things One is at the top of Goals below that is GOAL, OBJECTIVES AND .... We should not contradict someting which is agreed globally Kavouss 2015-12-18 9:35 GMT+01:00 Seun Ojedeji <seun.ojedeji@gmail.com>:
On Dec 18, 2015 7:27 AM, "Greg Shatan" <gregshatanipc@gmail.com> wrote:
. It overstates the case to say that the "Post-Transition IANA" is
separated from ICANN. That term should be reserved for the time when ICANN is no longer the "parent" of PTI.
SO: FWIW my +1 to the above statement as it's inline with my understanding as well. That said, I expect that legal wordings will be in place to ensure that IANA functions operation does not unilaterally get moved by ICANN from PTI to another department within ICANN. If that is what Milton is trying to say then I agree to that intent(even though it's outrageous scenario) and I believe that should be a fundamental bylaw text.
Regards
Greg
On Fri, Dec 18, 2015 at 12:05 AM, Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
On Dec 18, 2015 3:15 AM, "Mueller, Milton L" <milton@gatech.edu> wrote:
No. We have no problem with having the Scope of Responsibilities be
fundamental bylaws,
MM: As noted in my previous message, I do have a problem if the scope
includes non-core, nonexclusive things that ICANN does.
SO: +1 to this, so it's a matter of checking if the text in the scope is indeed out of remit of ICANN's actual role and responsibilities. Nevermind that this is a repetition of what I had earlier mentioned.
and that obviously means we expect the Scope of Responsibilities to
be fairly stable. Changes to the Scope of Responsibilities should require careful deliberation and considered action by the community as well as the Board. The Mission Statement should be even more stable and hardly ever require amendment.
MM: For ICANN to include its role as IFO as a fundamental bylaw is a
backdoor way of resisting and denying one of the most critical reforms of the IANA transition, namely the legal and structural separation of IFO from ICANN and the principle of separability. Sorry, Steve, that isn’t going to happen. Besides, to wrest IANA away from ICANN requires a massively complex process that certainly already qualifies as “careful deliberation and considered action.”
SO: Okay this seem to be becoming wired to me as I no longer understand the intent here, are you saying that ICANN would seize to be the IFO(logically) post-transition? If the intent is to somehow recognise the subsidiary of ICANN (PTI) as the IFO in the fundamental bylaw then I agree otherwise I think having things embedded in fundamental bylaw is most appropriate security because these in itself is a literally fundamental issues of the organisation structure and should be treated as such.
Regards
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Hello Kavouss,
Never ever at any organisation the " Mission 2 is replaced by" Scope of responsibility" they are entirely two different things
The mission is not being replaced by a Scope of Responsibility. The Board is actually using a standard definition of mission. From: https://en.wikipedia.org/wiki/Mission_statement “A mission statement is a statement which is used as a way of communicating the purpose of the organization. Although most of the time it will remain the same for a long period of time, it is not uncommon for organizations to update their mission statement and generally happens when an organization evolves. Mission statements are normally short and simple statements which outline what the organization's purpose is and are related to the specific sector an organization operates in.” The CCWG draft mission does not meet that standard. The Board’s suggested mission statement does meet that standard. That is why we have extracted the Scope of Responsibilities – that defines ICANN’s current scope within the broader longer term mission. The Scope of Responsibilities are still fundamental bylaws that cannot be changed without community approval. We have no objection to appropriate language in our bylaws that set out the rules of the organization. A mission though should be short and simple. Regards, Bruce Tonkin
On 18/12/2015 10:48, Bruce Tonkin wrote:
Hello Kavouss,
Never ever at any organisation the " Mission 2 is replaced by" Scope of responsibility" they are entirely two different things
The mission is not being replaced by a Scope of Responsibility.
The Board is actually using a standard definition of mission.
From: https://en.wikipedia.org/wiki/Mission_statement
“A mission statement is a statement which is used as a way of communicating the purpose of the organization. Although most of the time it will remain the same for a long period of time, it is not uncommon for organizations to update their mission statement and generally happens when an organization evolves. Mission statements are normally short and simple statements which outline what the organization's purpose is and are related to the specific sector an organization operates in.”
The CCWG draft mission does not meet that standard.
No. Not that there's any particular reason why it should be necessary to meet the Wikipedia description for a typical mission statement; ICANN is quite an atypical corporation. I do agree that it does look unusual though. The way we are using the Mission, however, reads to me more like the "Objects" clause for a Memorandum of Association of a corporation intended to have a limited purpose (such as a certain non-profits, and unlike a normal commercial for-profit corporation). I would't be greatly surprised if when this goes to lawyers they advise that this whole section should be moved there, instead of being in the Bylaws.
The Scope of Responsibilities are still fundamental bylaws that cannot be changed without community approval.
We have no objection to appropriate language in our bylaws that set out the rules of the organization. A mission though should be short and simple.
We are using the "Mission" as a governance tool. I can see why you might wish to use the term "Mission" as part of a communications tool, and create another term, such as "Scope of Responsibilities" to perform the governance function. So long as the governance effect is the same, I'm OK with that. But the text included in the "Scope" must have exactly the same weight and effect as if it were included in the "Mission"; otherwise you could argue that there was a an inconsistency or mismatch between the Mission and Scope, and that the Mission must take precedence; this must be made impossible. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd Monument Place, 24 Monument Street, London EC3R 8AJ Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA
None of this matter particularly. The substantive issues are far more important than fussing with labels - unless the fussing is an attempt to undermine the limits on ICANN¹s remit - wether it is called ³mission² or ³scope" J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: +1.202.533.2932 Mobile: +1.202.352.6367 / neustar.biz <http://www.neustar.biz> On 12/18/15, 5:48 AM, "Bruce Tonkin" <Bruce.Tonkin@melbourneit.com.au> wrote:
Hello Kavouss,
Never ever at any organisation the " Mission 2 is replaced by" Scope of responsibility" they are entirely two different things
The mission is not being replaced by a Scope of Responsibility.
The Board is actually using a standard definition of mission.
From: https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki _Mission-5Fstatement&d=CwIGaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRla q8Mo8TjDmrxdYahOP8WDDkMr4k&m=D8THnALA5tbmsPuth6vWOlL9CV8-PV9NEogKyC0OL-Y&s =NGcNwew3b3C2Cm4jR6e8Nu-CuKMulTyRSP27wPAbbQQ&e=
³A mission statement is a statement which is used as a way of communicating the purpose of the organization. Although most of the time it will remain the same for a long period of time, it is not uncommon for organizations to update their mission statement and generally happens when an organization evolves. Mission statements are normally short and simple statements which outline what the organization's purpose is and are related to the specific sector an organization operates in.²
The CCWG draft mission does not meet that standard.
The Board¹s suggested mission statement does meet that standard.
That is why we have extracted the Scope of Responsibilities that defines ICANN¹s current scope within the broader longer term mission.
The Scope of Responsibilities are still fundamental bylaws that cannot be changed without community approval.
We have no objection to appropriate language in our bylaws that set out the rules of the organization. A mission though should be short and simple.
Regards,
Bruce Tonkin
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_ listinfo_accountability-2Dcross-2Dcommunity&d=CwIGaQ&c=MOptNlVtIETeDALC_lU Lrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=D8THnALA5tbmsPuth6vWOl L9CV8-PV9NEogKyC0OL-Y&s=gvunmVRQ162HyOumpVgGFGMALffJltLoAazJkhg3Qps&e=
Meh. I don't understand the mission and scope - which will become fundamental bylaws - as something that describe various things that ICANN does. I understand it as the core responsibilities. I don't understand why anyone would want "things that ICANN does now but may not do in the future" as a fundamental bylaw. From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Bruce Tonkin Sent: Thursday, December 17, 2015 3:49 PM To: Mueller, Milton L <milton@gatech.edu>; Accountability Community <accountability-cross-community@icann.org> Subject: Re: [CCWG-ACCT] The Board's take on the Mission Statement Which is why it is part of the current scop of responsibilities that can change over time, and not part of the mission statement that should be much more stable. Regards, Bruce Tonkin From: Mueller, Milton L [mailto:milton@gatech.edu] Sent: Friday, 18 December 2015 7:35 AM To: Bruce Tonkin <Bruce.Tonkin@melbourneit.com.au<mailto:Bruce.Tonkin@melbourneit.com.au>>; Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: RE: The Board's take on the Mission Statement The addition of "allocation and assignment of names" was intended to capture the role of putting names in the root zone including new gTLDs and IDN-ccTLDs." I accept that this could be considered as part of "implementation of policies" = but it was trying to be more specific. MM: But in fact, that is no longer an essential or exclusive part of ICANN's mission. Names are put into the root zone by the IANA functions operator. ICANN may or may not be the IANA functions operator for names in the future. Many of the changes in the mission statement called for by the IAB and ISOC were predicated on the fact that ICANN is not presumed to be the IFO.
participants (8)
-
Bruce Tonkin -
Burr, Becky -
Greg Shatan -
Kavouss Arasteh -
Malcolm Hutty -
Mueller, Milton L -
Seun Ojedeji -
Steve Crocker