From alissa at cooperw.in Mon May 2 23:01:18 2016 From: alissa at cooperw.in (Alissa Cooper) Date: Mon, 2 May 2016 16:01:18 -0700 Subject: [Internal-cg] bylaws feedback In-Reply-To: References: <79AB2AAA-ECED-4A05-A437-16F100D664EE@cooperw.in> <6170505D-57EB-4017-A9B6-68D37E9EF4EF@cooperw.in> <5978117D-AD72-4C5B-80D2-24CAED51A922@LStAmour.org> <648952D9-5962-4E6D-8271-55AE178F9113@cooperw.in> Message-ID: <7CCC84D4-1E20-41B8-8F41-4D06A9291F82@cooperw.in> I’ve put together an initial draft comment below, using Lynn’s email as the base. Please send feedback/edits. I am a little leery of raising the issue Milton points out below about RA/RAA renewals, since that is more a question about what was discussed and agreed in the CCWG proposal and how paragraph 147 of the CCWG proposal is being interpreted, as compared to the other arguments which are about whole new provisions that were added without reference to any proposal text or community discussion. I tried to remain non-commital on this point in the text below. — The ICG appreciates the opportunity to comment on the draft ICANN Bylaws. The ICG previously communicated concerns about Section 1.1(d)(ii) to the Bylaws drafting group [1]. However, these concerns were not addressed in the draft Bylaws that were posted for public comment. Section 1.1(d) "grandfathers" a number of agreements into the Bylaws in order to prevent parties from challenging those agreements on the basis that they violate the ICANN Mission statement. Under Section 1.1(d)(ii), (A) applies to RA/RAA agreements; (B)-(D) apply to agreements between ICANN and the NRO, ASO, IETF, RZM, and PTI; and (E) applies to ICANN's Five-Year Strategic Plan and Five-Year Operating Plan. (F) applies the grandfathering to renewals of the agreements appearing in (B)-(D). The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. Regards, Alissa Cooper on behalf of the ICG [1] http://mm.icann.org/pipermail/cwg-stewardship/2016-April/004877.html > On Apr 30, 2016, at 8:16 AM, Mueller, Milton L wrote: > > Ok, I have had time to read the transcript. I am even more strongly committed to developing a comment as ICG. > > Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that allows all of the work that was done to more precisely define the mission statement of ICANN in these bylaws ...to be completely contravened by whatever gets written into the ICANN PTI contract Because what this is says is that no one in the future will ever be able to challenge that contract on the basis that it contravenes the mission.” > > [and, I might add, the RZM contract, and renewals of registry contracts]. > > The only answer I saw to this was that we don’t need to worry about it because the PTI contract will be put up for public comment. > > Alissa also made the point: > "this memo ... seems to imply that ... the most important thing out of all of this is that ICANN can continue to perform the IANA function. And I think what we all learned in (unintelligible) in terms of what the ICG proposal says is that in fact that is not the most important thing. The most important thing is that the IANA functions can continue to be performed by some operator who’s capable of performing them according to the service level agreements that the community ...has. And those two things are not the same. And I certainly –I will put my IETF hat on here for a second and say that I think from an IETF perspective the important thing is that a protocol parameters functions can continue to be performed, not that they can only continue to be performed by ICANN." > > I don't think this argument of Alissa was ever answered. It seems like there could be ways of drafting these sections that do not commit us to a specific contract but makes it clear that performance of the IANA functions is not challengable as a mission violation so long as the community actually wants ICANN to perform those functions. > > Indeed, I am having trouble understanding the threat that these sections are supposed to avoid. > > However, the most dangerous mission-limitation-busting potential is in the renewals section (F). This is problematic partly because the CCWG never agreed to exempt renewals. We agreed to grandfather existing agreements, for the sake of stability. But the assumption was that if anything in these existing agreements contravened the new mission limitations, that they COULD be challenged during a renewal process. A contract renewal with a registry could include all kinds of regulatory measures that exceed the mission, and if these measures are framed as a "renewal of an existing agreement" then ICANN could in principle get away with anything. > > So I hope we are able to make it clear to ICANN and the CCWG that these provisions need to be changed.. > >   <> > From: Alissa Cooper [mailto:alissa at cooperw.in ] > Sent: Friday, April 29, 2016 3:00 PM > To: Mueller, Milton L > > Cc: Lynn St.Amour >; IANA etc etcCoordination Group > > Subject: Re: [Internal-cg] bylaws feedback > > For folks following this issue, it is definitely worth reading the transcript or listening to the recording of the last CCWG call: https://community.icann.org/pages/viewpage.action?pageId=58730392 > > The more that I have thought about this, it has become clear to me that the core issue here is that there is a portion of bylaws section 1.1(d) that is not called for either by our proposal or by the CCWG proposal, as Lynn says. Had the content of 1.1(d)(ii)(B-E) been discussed as part of the transition proposal development, I think the concerns being raised now would have been raised then, and the whole community would have had time to sort them out. (I note that there was an extended discussion about RA/RAA agreements in the CCWG and that did result in text in its proposal in paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not extend to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been created out of whole cloth by the bylaws drafting team, and that was not within their remit in my opinion. The Bylaws are just supposed to implement the proposals. > > I think there are substantive issues too, but from an ICG perspective we may or may not want to focus on those. > > I would support sending a comment. We sent a message early on during the bylaws drafting and received no response, and the call to discuss this didn’t even occur until after the bylaws were put out for public comment. > > Alissa > > > On Apr 29, 2016, at 11:17 AM, Mueller, Milton L > wrote: > > I support what you are saying. I take it you are not satisfied with the lawyers' explanation? I was not able to attend the 0:400 call a few days ago so was not able to question them about it or hear their answers. > > --MM > > > -----Original Message----- > From: Lynn St.Amour [mailto:Lynn at LStAmour.org ] > Sent: Friday, April 29, 2016 1:55 PM > To: Alissa Cooper >; Mueller, Milton L > >; IANA etc etcCoordination Group cg at ianacg.org > > Subject: Re: [Internal-cg] bylaws feedback > > Hi Alissa, Milton, all, > > I would like to come back to this subject. Specifically, I would like to propose > that the ICG send in a statement to the By-laws comment period. > > Alissa commented on a specific concern (see thread below) and I also believe > the ICG should be concerned about the overreach in the draft bylaws. > > My main concerns are: > > - the fact that these draft by-laws, through the grand-fathering provisions, > allow external agreements to define ICANN's Mission which seems like a bad > idea for many reasons. Further, this contradicts the desires of the community > (or is a run around the community - intentional or not) who worked hard to > clarify and correctly state ICANN’s mission throughout the IANA Transition > process (paragraphs 140-144 of the CCWG-Accountability proposal). > > - the ICG process was fashioned to ensure that the transition plans reflected > the consensus of the Internet community. And, it was to respect the roles and > responsibilities of the OCs in defining their own transition plans. The ICG and > the CCWG reports define those wishes, and any changes to the bylaws were to > be to implement those wishes, nothing more. Yet provisions in sections > 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- > Accountability proposals, and so there has not been appropriate community > involvement or review for those changes. Note: these sections affect much > of the Internet community, as they apply to agreements between ICANN and > the ASO, NRO, IETF, Root Zone Maintainer, and PTI. > > For transparency: the IAB/IETF are also concerned about the overreach and > are drafting their own comments, and as an IAB appointee to the ICG, I am > part of that review as well. > > If there is support for the ICG sending in a comment, I would be happy to work > with Alissa and others to draft something for ICG review. > > Regards, > Lynn > > > > On Apr 12, 2016, at 3:15 PM, Alissa Cooper > wrote: > > From the minutes it looks like this was discussed on the CCWG call and there > will be follow-up. > > > > On Apr 12, 2016, at 8:39 AM, Mueller, Milton L > > wrote: > > > I sent it yesterday but there has been no response at all. > > > > -----Original Message----- > From: Alissa Cooper [mailto:alissa at cooperw.in ] > Sent: Monday, April 11, 2016 4:54 PM > To: Mueller, Milton L > > Cc: IANA etc etcCoordination Group > > Subject: Re: [Internal-cg] bylaws feedback > > I think that would be fine. > > Thanks, > Alissa > > > On Apr 11, 2016, at 1:04 PM, Mueller, Milton L > > wrote: > > > Alissa > If you don't mind I will just forward your message to the bylaws > and CWG > lists. > > If there is some other way you want me to do this, please let me know. > > --MM > > > -----Original Message----- > From: Internal-cg [mailto:internal-cg-bounces at ianacg.org ] On > Behalf Of Alissa Cooper > Sent: Monday, April 11, 2016 1:49 PM > To: IANA etc etcCoordination Group > > Subject: [Internal-cg] bylaws feedback > > I have looked a bit at the draft bylaws and I’d like to ask > Kavouss and Milton to bring the following issue back to the bylaws > drafting group: > > > Section 1.1(d)(ii) incorporates by reference a number of documents > external to the bylaws as a means to prevent challenges on the > basis that those documents conflict with or violate the bylaws. In > particular, bullet (D) applies this provision to "the IANA Naming > Function Contract between ICANN and PTI effective [October 1, 2016]." > > Given the ICG's historical encouragement of the community to meet > timelines necessary for a successful transition, I find this > provision to be extremely problematic. It incorporates a reference > to a document that does not exist yet and that is unlikely to be > completed by the time the bylaws are supposed to be done (early > June). In fact, it is not even clear at this point whether the new > ICANN affiliate to be setup will be name "PTI" or have some other > name. I don't understand how anyone can reason about whether > 1.1(d)(ii) is an acceptable bylaws provision if it references a > document that has not been written. (This also applies to (B) and > (C) since it could apply to future documents that haven’t been > written > yet.) > > Furthermore, I question whether it is a sound decision to > essentially allow for documents external to the bylaws to be able > to modify the bylaws (under (F)). This section would make more > sense if it was entirely internally specified, without the > references to external documents. At a minimum, I think we should > recommend that (D) be > removed. > > > Thanks, > Alissa > _______________________________________________ > Internal-cg mailing list > Internal-cg at mm.ianacg.org > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From housley at vigilsec.com Tue May 3 13:38:36 2016 From: housley at vigilsec.com (Russ Housley) Date: Tue, 3 May 2016 09:38:36 -0400 Subject: [Internal-cg] bylaws feedback In-Reply-To: <7CCC84D4-1E20-41B8-8F41-4D06A9291F82@cooperw.in> References: <79AB2AAA-ECED-4A05-A437-16F100D664EE@cooperw.in> <6170505D-57EB-4017-A9B6-68D37E9EF4EF@cooperw.in> <5978117D-AD72-4C5B-80D2-24CAED51A922@LStAmour.org> <648952D9-5962-4E6D-8271-55AE178F9113@cooperw.in> <7CCC84D4-1E20-41B8-8F41-4D06A9291F82@cooperw.in> Message-ID: This look very good to me. Russ On May 2, 2016, at 7:01 PM, Alissa Cooper wrote: > I’ve put together an initial draft comment below, using Lynn’s email as the base. Please send feedback/edits. > > I am a little leery of raising the issue Milton points out below about RA/RAA renewals, since that is more a question about what was discussed and agreed in the CCWG proposal and how paragraph 147 of the CCWG proposal is being interpreted, as compared to the other arguments which are about whole new provisions that were added without reference to any proposal text or community discussion. I tried to remain non-commital on this point in the text below. > > — > > The ICG appreciates the opportunity to comment on the draft ICANN Bylaws. > > The ICG previously communicated concerns about Section 1.1(d)(ii) to the Bylaws drafting group [1]. However, these concerns were not addressed in the draft Bylaws that were posted for public comment. > > Section 1.1(d) "grandfathers" a number of agreements into the Bylaws in order to prevent parties from challenging those agreements on the basis that they violate the ICANN Mission statement. Under Section 1.1(d)(ii), (A) applies to RA/RAA agreements; (B)-(D) apply to agreements between ICANN and the NRO, ASO, IETF, RZM, and PTI; and (E) applies to ICANN's Five-Year Strategic Plan and Five-Year Operating Plan. (F) applies the grandfathering to renewals of the agreements appearing in (B)-(D). > > The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. > > Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). > > The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. > > Regards, > > Alissa Cooper on behalf of the ICG > > > [1] http://mm.icann.org/pipermail/cwg-stewardship/2016-April/004877.html > > >> On Apr 30, 2016, at 8:16 AM, Mueller, Milton L wrote: >> >> Ok, I have had time to read the transcript. I am even more strongly committed to developing a comment as ICG. >> >> Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that allows all of the work that was done to more precisely define the mission statement of ICANN in these bylaws ...to be completely contravened by whatever gets written into the ICANN PTI contract Because what this is says is that no one in the future will ever be able to challenge that contract on the basis that it contravenes the mission.” >> >> [and, I might add, the RZM contract, and renewals of registry contracts]. >> >> The only answer I saw to this was that we don’t need to worry about it because the PTI contract will be put up for public comment. >> >> Alissa also made the point: >> "this memo ... seems to imply that ... the most important thing out of all of this is that ICANN can continue to perform the IANA function. And I think what we all learned in (unintelligible) in terms of what the ICG proposal says is that in fact that is not the most important thing. The most important thing is that the IANA functions can continue to be performed by some operator who’s capable of performing them according to the service level agreements that the community ...has. And those two things are not the same. And I certainly –I will put my IETF hat on here for a second and say that I think from an IETF perspective the important thing is that a protocol parameters functions can continue to be performed, not that they can only continue to be performed by ICANN." >> >> I don't think this argument of Alissa was ever answered. It seems like there could be ways of drafting these sections that do not commit us to a specific contract but makes it clear that performance of the IANA functions is not challengable as a mission violation so long as the community actually wants ICANN to perform those functions. >> >> Indeed, I am having trouble understanding the threat that these sections are supposed to avoid. >> >> However, the most dangerous mission-limitation-busting potential is in the renewals section (F). This is problematic partly because the CCWG never agreed to exempt renewals. We agreed to grandfather existing agreements, for the sake of stability. But the assumption was that if anything in these existing agreements contravened the new mission limitations, that they COULD be challenged during a renewal process. A contract renewal with a registry could include all kinds of regulatory measures that exceed the mission, and if these measures are framed as a "renewal of an existing agreement" then ICANN could in principle get away with anything. >> >> So I hope we are able to make it clear to ICANN and the CCWG that these provisions need to be changed.. >> >> >> From: Alissa Cooper [mailto:alissa at cooperw.in] >> Sent: Friday, April 29, 2016 3:00 PM >> To: Mueller, Milton L >> Cc: Lynn St.Amour ; IANA etc etcCoordination Group >> Subject: Re: [Internal-cg] bylaws feedback >> >> For folks following this issue, it is definitely worth reading the transcript or listening to the recording of the last CCWG call: https://community.icann.org/pages/viewpage.action?pageId=58730392 >> >> The more that I have thought about this, it has become clear to me that the core issue here is that there is a portion of bylaws section 1.1(d) that is not called for either by our proposal or by the CCWG proposal, as Lynn says. Had the content of 1.1(d)(ii)(B-E) been discussed as part of the transition proposal development, I think the concerns being raised now would have been raised then, and the whole community would have had time to sort them out. (I note that there was an extended discussion about RA/RAA agreements in the CCWG and that did result in text in its proposal in paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not extend to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been created out of whole cloth by the bylaws drafting team, and that was not within their remit in my opinion. The Bylaws are just supposed to implement the proposals. >> >> I think there are substantive issues too, but from an ICG perspective we may or may not want to focus on those. >> >> I would support sending a comment. We sent a message early on during the bylaws drafting and received no response, and the call to discuss this didn’t even occur until after the bylaws were put out for public comment. >> >> Alissa >> >> >> On Apr 29, 2016, at 11:17 AM, Mueller, Milton L wrote: >> >> I support what you are saying. I take it you are not satisfied with the lawyers' explanation? I was not able to attend the 0:400 call a few days ago so was not able to question them about it or hear their answers. >> >> --MM >> >> >> -----Original Message----- >> From: Lynn St.Amour [mailto:Lynn at LStAmour.org] >> Sent: Friday, April 29, 2016 1:55 PM >> To: Alissa Cooper ; Mueller, Milton L >> ; IANA etc etcCoordination Group > cg at ianacg.org> >> Subject: Re: [Internal-cg] bylaws feedback >> >> Hi Alissa, Milton, all, >> >> I would like to come back to this subject. Specifically, I would like to propose >> that the ICG send in a statement to the By-laws comment period. >> >> Alissa commented on a specific concern (see thread below) and I also believe >> the ICG should be concerned about the overreach in the draft bylaws. >> >> My main concerns are: >> >> - the fact that these draft by-laws, through the grand-fathering provisions, >> allow external agreements to define ICANN's Mission which seems like a bad >> idea for many reasons. Further, this contradicts the desires of the community >> (or is a run around the community - intentional or not) who worked hard to >> clarify and correctly state ICANN’s mission throughout the IANA Transition >> process (paragraphs 140-144 of the CCWG-Accountability proposal). >> >> - the ICG process was fashioned to ensure that the transition plans reflected >> the consensus of the Internet community. And, it was to respect the roles and >> responsibilities of the OCs in defining their own transition plans. The ICG and >> the CCWG reports define those wishes, and any changes to the bylaws were to >> be to implement those wishes, nothing more. Yet provisions in sections >> 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- >> Accountability proposals, and so there has not been appropriate community >> involvement or review for those changes. Note: these sections affect much >> of the Internet community, as they apply to agreements between ICANN and >> the ASO, NRO, IETF, Root Zone Maintainer, and PTI. >> >> For transparency: the IAB/IETF are also concerned about the overreach and >> are drafting their own comments, and as an IAB appointee to the ICG, I am >> part of that review as well. >> >> If there is support for the ICG sending in a comment, I would be happy to work >> with Alissa and others to draft something for ICG review. >> >> Regards, >> Lynn >> >> >> >> On Apr 12, 2016, at 3:15 PM, Alissa Cooper wrote: >> >> From the minutes it looks like this was discussed on the CCWG call and there >> will be follow-up. >> >> >> >> On Apr 12, 2016, at 8:39 AM, Mueller, Milton L >> wrote: >> >> >> I sent it yesterday but there has been no response at all. >> >> >> >> -----Original Message----- >> From: Alissa Cooper [mailto:alissa at cooperw.in] >> Sent: Monday, April 11, 2016 4:54 PM >> To: Mueller, Milton L >> Cc: IANA etc etcCoordination Group >> Subject: Re: [Internal-cg] bylaws feedback >> >> I think that would be fine. >> >> Thanks, >> Alissa >> >> >> On Apr 11, 2016, at 1:04 PM, Mueller, Milton L >> wrote: >> >> >> Alissa >> If you don't mind I will just forward your message to the bylaws >> and CWG >> lists. >> >> If there is some other way you want me to do this, please let me know. >> >> --MM >> >> >> -----Original Message----- >> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On >> Behalf Of Alissa Cooper >> Sent: Monday, April 11, 2016 1:49 PM >> To: IANA etc etcCoordination Group >> Subject: [Internal-cg] bylaws feedback >> >> I have looked a bit at the draft bylaws and I’d like to ask >> Kavouss and Milton to bring the following issue back to the bylaws >> drafting group: >> >> >> Section 1.1(d)(ii) incorporates by reference a number of documents >> external to the bylaws as a means to prevent challenges on the >> basis that those documents conflict with or violate the bylaws. In >> particular, bullet (D) applies this provision to "the IANA Naming >> Function Contract between ICANN and PTI effective [October 1, 2016]." >> >> Given the ICG's historical encouragement of the community to meet >> timelines necessary for a successful transition, I find this >> provision to be extremely problematic. It incorporates a reference >> to a document that does not exist yet and that is unlikely to be >> completed by the time the bylaws are supposed to be done (early >> June). In fact, it is not even clear at this point whether the new >> ICANN affiliate to be setup will be name "PTI" or have some other >> name. I don't understand how anyone can reason about whether >> 1.1(d)(ii) is an acceptable bylaws provision if it references a >> document that has not been written. (This also applies to (B) and >> (C) since it could apply to future documents that haven’t been >> written >> yet.) >> >> Furthermore, I question whether it is a sound decision to >> essentially allow for documents external to the bylaws to be able >> to modify the bylaws (under (F)). This section would make more >> sense if it was entirely internally specified, without the >> references to external documents. At a minimum, I think we should >> recommend that (D) be >> removed. >> >> >> Thanks, >> Alissa >> _______________________________________________ >> Internal-cg mailing list >> Internal-cg at mm.ianacg.org >> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org > > _______________________________________________ > Internal-cg mailing list > Internal-cg at mm.ianacg.org > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From kavouss.arasteh at gmail.com Tue May 3 14:42:11 2016 From: kavouss.arasteh at gmail.com (Kavouss Arasteh) Date: Tue, 3 May 2016 16:42:11 +0200 Subject: [Internal-cg] bylaws feedback In-Reply-To: <7CCC84D4-1E20-41B8-8F41-4D06A9291F82@cooperw.in> References: <79AB2AAA-ECED-4A05-A437-16F100D664EE@cooperw.in> <6170505D-57EB-4017-A9B6-68D37E9EF4EF@cooperw.in> <5978117D-AD72-4C5B-80D2-24CAED51A922@LStAmour.org> <648952D9-5962-4E6D-8271-55AE178F9113@cooperw.in> <7CCC84D4-1E20-41B8-8F41-4D06A9291F82@cooperw.in> Message-ID: Dear Alissa Thank you and thanks Milton for your comprehensive analysis. What you said is absolutely right Apparently sections 1.1(d) (ii) (A) which was agreed by CCWG had been extrapolated to other sections. I have raised the issue in several messages repeatedly saying that it is not legally appropriate to provide a Blanket agreement for those areas that the contents and conditions yet to be discussed and negotiated. I have no problem that you send your comment to co- chairs and I will make follow up action in any future opportunity to see what we can do. Regards Kavousd Sent from my iPhone > On 3 May 2016, at 01:01, Alissa Cooper wrote: > > I’ve put together an initial draft comment below, using Lynn’s email as the base. Please send feedback/edits. > > I am a little leery of raising the issue Milton points out below about RA/RAA renewals, since that is more a question about what was discussed and agreed in the CCWG proposal and how paragraph 147 of the CCWG proposal is being interpreted, as compared to the other arguments which are about whole new provisions that were added without reference to any proposal text or community discussion. I tried to remain non-commital on this point in the text below. > > — > > The ICG appreciates the opportunity to comment on the draft ICANN Bylaws. > > The ICG previously communicated concerns about Section 1.1(d)(ii) to the Bylaws drafting group [1]. However, these concerns were not addressed in the draft Bylaws that were posted for public comment. > > Section 1.1(d) "grandfathers" a number of agreements into the Bylaws in order to prevent parties from challenging those agreements on the basis that they violate the ICANN Mission statement. Under Section 1.1(d)(ii), (A) applies to RA/RAA agreements; (B)-(D) apply to agreements between ICANN and the NRO, ASO, IETF, RZM, and PTI; and (E) applies to ICANN's Five-Year Strategic Plan and Five-Year Operating Plan. (F) applies the grandfathering to renewals of the agreements appearing in (B)-(D). > > The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. > > Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). > > The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. > > Regards, > > Alissa Cooper on behalf of the ICG > > > [1] http://mm.icann.org/pipermail/cwg-stewardship/2016-April/004877.html > > >> On Apr 30, 2016, at 8:16 AM, Mueller, Milton L wrote: >> >> Ok, I have had time to read the transcript. I am even more strongly committed to developing a comment as ICG. >> >> Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that allows all of the work that was done to more precisely define the mission statement of ICANN in these bylaws ...to be completely contravened by whatever gets written into the ICANN PTI contract Because what this is says is that no one in the future will ever be able to challenge that contract on the basis that it contravenes the mission.” >> >> [and, I might add, the RZM contract, and renewals of registry contracts]. >> >> The only answer I saw to this was that we don’t need to worry about it because the PTI contract will be put up for public comment. >> >> Alissa also made the point: >> "this memo ... seems to imply that ... the most important thing out of all of this is that ICANN can continue to perform the IANA function. And I think what we all learned in (unintelligible) in terms of what the ICG proposal says is that in fact that is not the most important thing. The most important thing is that the IANA functions can continue to be performed by some operator who’s capable of performing them according to the service level agreements that the community ...has. And those two things are not the same. And I certainly –I will put my IETF hat on here for a second and say that I think from an IETF perspective the important thing is that a protocol parameters functions can continue to be performed, not that they can only continue to be performed by ICANN." >> >> I don't think this argument of Alissa was ever answered. It seems like there could be ways of drafting these sections that do not commit us to a specific contract but makes it clear that performance of the IANA functions is not challengable as a mission violation so long as the community actually wants ICANN to perform those functions. >> >> Indeed, I am having trouble understanding the threat that these sections are supposed to avoid. >> >> However, the most dangerous mission-limitation-busting potential is in the renewals section (F). This is problematic partly because the CCWG never agreed to exempt renewals. We agreed to grandfather existing agreements, for the sake of stability. But the assumption was that if anything in these existing agreements contravened the new mission limitations, that they COULD be challenged during a renewal process. A contract renewal with a registry could include all kinds of regulatory measures that exceed the mission, and if these measures are framed as a "renewal of an existing agreement" then ICANN could in principle get away with anything. >> >> So I hope we are able to make it clear to ICANN and the CCWG that these provisions need to be changed.. >> >> >> From: Alissa Cooper [mailto:alissa at cooperw.in] >> Sent: Friday, April 29, 2016 3:00 PM >> To: Mueller, Milton L >> Cc: Lynn St.Amour ; IANA etc etcCoordination Group >> Subject: Re: [Internal-cg] bylaws feedback >> >> For folks following this issue, it is definitely worth reading the transcript or listening to the recording of the last CCWG call: https://community.icann.org/pages/viewpage.action?pageId=58730392 >> >> The more that I have thought about this, it has become clear to me that the core issue here is that there is a portion of bylaws section 1.1(d) that is not called for either by our proposal or by the CCWG proposal, as Lynn says. Had the content of 1.1(d)(ii)(B-E) been discussed as part of the transition proposal development, I think the concerns being raised now would have been raised then, and the whole community would have had time to sort them out. (I note that there was an extended discussion about RA/RAA agreements in the CCWG and that did result in text in its proposal in paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not extend to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been created out of whole cloth by the bylaws drafting team, and that was not within their remit in my opinion. The Bylaws are just supposed to implement the proposals. >> >> I think there are substantive issues too, but from an ICG perspective we may or may not want to focus on those. >> >> I would support sending a comment. We sent a message early on during the bylaws drafting and received no response, and the call to discuss this didn’t even occur until after the bylaws were put out for public comment. >> >> Alissa >> >> >> On Apr 29, 2016, at 11:17 AM, Mueller, Milton L wrote: >> >> I support what you are saying. I take it you are not satisfied with the lawyers' explanation? I was not able to attend the 0:400 call a few days ago so was not able to question them about it or hear their answers. >> >> --MM >> >> >> -----Original Message----- >> From: Lynn St.Amour [mailto:Lynn at LStAmour.org] >> Sent: Friday, April 29, 2016 1:55 PM >> To: Alissa Cooper ; Mueller, Milton L >> ; IANA etc etcCoordination Group > cg at ianacg.org> >> Subject: Re: [Internal-cg] bylaws feedback >> >> Hi Alissa, Milton, all, >> >> I would like to come back to this subject. Specifically, I would like to propose >> that the ICG send in a statement to the By-laws comment period. >> >> Alissa commented on a specific concern (see thread below) and I also believe >> the ICG should be concerned about the overreach in the draft bylaws. >> >> My main concerns are: >> >> - the fact that these draft by-laws, through the grand-fathering provisions, >> allow external agreements to define ICANN's Mission which seems like a bad >> idea for many reasons. Further, this contradicts the desires of the community >> (or is a run around the community - intentional or not) who worked hard to >> clarify and correctly state ICANN’s mission throughout the IANA Transition >> process (paragraphs 140-144 of the CCWG-Accountability proposal). >> >> - the ICG process was fashioned to ensure that the transition plans reflected >> the consensus of the Internet community. And, it was to respect the roles and >> responsibilities of the OCs in defining their own transition plans. The ICG and >> the CCWG reports define those wishes, and any changes to the bylaws were to >> be to implement those wishes, nothing more. Yet provisions in sections >> 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- >> Accountability proposals, and so there has not been appropriate community >> involvement or review for those changes. Note: these sections affect much >> of the Internet community, as they apply to agreements between ICANN and >> the ASO, NRO, IETF, Root Zone Maintainer, and PTI. >> >> For transparency: the IAB/IETF are also concerned about the overreach and >> are drafting their own comments, and as an IAB appointee to the ICG, I am >> part of that review as well. >> >> If there is support for the ICG sending in a comment, I would be happy to work >> with Alissa and others to draft something for ICG review. >> >> Regards, >> Lynn >> >> >> >> On Apr 12, 2016, at 3:15 PM, Alissa Cooper wrote: >> >> From the minutes it looks like this was discussed on the CCWG call and there >> will be follow-up. >> >> >> >> On Apr 12, 2016, at 8:39 AM, Mueller, Milton L >> wrote: >> >> >> I sent it yesterday but there has been no response at all. >> >> >> >> -----Original Message----- >> From: Alissa Cooper [mailto:alissa at cooperw.in] >> Sent: Monday, April 11, 2016 4:54 PM >> To: Mueller, Milton L >> Cc: IANA etc etcCoordination Group >> Subject: Re: [Internal-cg] bylaws feedback >> >> I think that would be fine. >> >> Thanks, >> Alissa >> >> >> On Apr 11, 2016, at 1:04 PM, Mueller, Milton L >> wrote: >> >> >> Alissa >> If you don't mind I will just forward your message to the bylaws >> and CWG >> lists. >> >> If there is some other way you want me to do this, please let me know. >> >> --MM >> >> >> -----Original Message----- >> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On >> Behalf Of Alissa Cooper >> Sent: Monday, April 11, 2016 1:49 PM >> To: IANA etc etcCoordination Group >> Subject: [Internal-cg] bylaws feedback >> >> I have looked a bit at the draft bylaws and I’d like to ask >> Kavouss and Milton to bring the following issue back to the bylaws >> drafting group: >> >> >> Section 1.1(d)(ii) incorporates by reference a number of documents >> external to the bylaws as a means to prevent challenges on the >> basis that those documents conflict with or violate the bylaws. In >> particular, bullet (D) applies this provision to "the IANA Naming >> Function Contract between ICANN and PTI effective [October 1, 2016]." >> >> Given the ICG's historical encouragement of the community to meet >> timelines necessary for a successful transition, I find this >> provision to be extremely problematic. It incorporates a reference >> to a document that does not exist yet and that is unlikely to be >> completed by the time the bylaws are supposed to be done (early >> June). In fact, it is not even clear at this point whether the new >> ICANN affiliate to be setup will be name "PTI" or have some other >> name. I don't understand how anyone can reason about whether >> 1.1(d)(ii) is an acceptable bylaws provision if it references a >> document that has not been written. (This also applies to (B) and >> (C) since it could apply to future documents that haven’t been >> written >> yet.) >> >> Furthermore, I question whether it is a sound decision to >> essentially allow for documents external to the bylaws to be able >> to modify the bylaws (under (F)). This section would make more >> sense if it was entirely internally specified, without the >> references to external documents. At a minimum, I think we should >> recommend that (D) be >> removed. >> >> >> Thanks, >> Alissa >> _______________________________________________ >> Internal-cg mailing list >> Internal-cg at mm.ianacg.org >> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org > > _______________________________________________ > Internal-cg mailing list > Internal-cg at mm.ianacg.org > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From kavouss.arasteh at gmail.com Tue May 3 14:44:04 2016 From: kavouss.arasteh at gmail.com (Kavouss Arasteh) Date: Tue, 3 May 2016 16:44:04 +0200 Subject: [Internal-cg] bylaws feedback In-Reply-To: <2C426BBC-C2F6-4E29-82DF-C118B52FAC82@frobbit.se> References: <79AB2AAA-ECED-4A05-A437-16F100D664EE@cooperw.in> <6170505D-57EB-4017-A9B6-68D37E9EF4EF@cooperw.in> <5978117D-AD72-4C5B-80D2-24CAED51A922@LStAmour.org> <648952D9-5962-4E6D-8271-55AE178F9113@cooperw.in> <2C426BBC-C2F6-4E29-82DF-C118B52FAC82@frobbit.se> Message-ID: <0A01869B-2C76-4B1D-8A77-A0336A4F0527@gmail.com> Patrik While I agree with your argument but having provisions in Bylaws could prevail in drafting PTI agreement. Kavousd Sent from my iPhone > On 30 Apr 2016, at 19:20, Patrik Fältström wrote: > >> On 30 Apr 2016, at 17:16, Mueller, Milton L wrote: >> >> The only answer I saw to this was that we don’t need to worry about it because the PTI contract will be put up for public comment. > > A public comment period should not be The Mechanism that is used to ensure the proposal stays within the realm of the documents produced. The process followed to create the bylaws must include validation mechanisms to minimize deviation. > > Patrik > _______________________________________________ > Internal-cg mailing list > Internal-cg at mm.ianacg.org > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org From Lynn at LStAmour.org Tue May 3 16:21:51 2016 From: Lynn at LStAmour.org (Lynn St.Amour) Date: Tue, 3 May 2016 12:21:51 -0400 Subject: [Internal-cg] bylaws feedback In-Reply-To: <7CCC84D4-1E20-41B8-8F41-4D06A9291F82@cooperw.in> References: <79AB2AAA-ECED-4A05-A437-16F100D664EE@cooperw.in> <6170505D-57EB-4017-A9B6-68D37E9EF4EF@cooperw.in> <5978117D-AD72-4C5B-80D2-24CAED51A922@LStAmour.org> <648952D9-5962-4E6D-8271-55AE178F9113@cooperw.in> <7CCC84D4-1E20-41B8-8F41-4D06A9291F82@cooperw.in> Message-ID: <61396F92-40E7-4CC8-95E7-17EAC4900B49@LStAmour.org> Hi Alissa, I support this draft and strongly support sending the letter. It is important that the wishes of the community and the Operating Communities be respected. In my experience, it is also unusual for a Mission statement to be so referenced and so legally encumbered. Best, Lynn PS. Would be really good to hear from other ICG members, as well. > On May 2, 2016, at 7:01 PM, Alissa Cooper wrote: > > I’ve put together an initial draft comment below, using Lynn’s email as the base. Please send feedback/edits. > > I am a little leery of raising the issue Milton points out below about RA/RAA renewals, since that is more a question about what was discussed and agreed in the CCWG proposal and how paragraph 147 of the CCWG proposal is being interpreted, as compared to the other arguments which are about whole new provisions that were added without reference to any proposal text or community discussion. I tried to remain non-commital on this point in the text below. > > — > > The ICG appreciates the opportunity to comment on the draft ICANN Bylaws. > > The ICG previously communicated concerns about Section 1.1(d)(ii) to the Bylaws drafting group [1]. However, these concerns were not addressed in the draft Bylaws that were posted for public comment. > > Section 1.1(d) "grandfathers" a number of agreements into the Bylaws in order to prevent parties from challenging those agreements on the basis that they violate the ICANN Mission statement. Under Section 1.1(d)(ii), (A) applies to RA/RAA agreements; (B)-(D) apply to agreements between ICANN and the NRO, ASO, IETF, RZM, and PTI; and (E) applies to ICANN's Five-Year Strategic Plan and Five-Year Operating Plan. (F) applies the grandfathering to renewals of the agreements appearing in (B)-(D). > > The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. > > Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). > > The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. > > Regards, > > Alissa Cooper on behalf of the ICG > > > [1] http://mm.icann.org/pipermail/cwg-stewardship/2016-April/004877.html > > >> On Apr 30, 2016, at 8:16 AM, Mueller, Milton L wrote: >> >> Ok, I have had time to read the transcript. I am even more strongly committed to developing a comment as ICG. >> >> Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that allows all of the work that was done to more precisely define the mission statement of ICANN in these bylaws ...to be completely contravened by whatever gets written into the ICANN PTI contract Because what this is says is that no one in the future will ever be able to challenge that contract on the basis that it contravenes the mission.” >> >> [and, I might add, the RZM contract, and renewals of registry contracts]. >> >> The only answer I saw to this was that we don’t need to worry about it because the PTI contract will be put up for public comment. >> >> Alissa also made the point: >> "this memo ... seems to imply that ... the most important thing out of all of this is that ICANN can continue to perform the IANA function. And I think what we all learned in (unintelligible) in terms of what the ICG proposal says is that in fact that is not the most important thing. The most important thing is that the IANA functions can continue to be performed by some operator who’s capable of performing them according to the service level agreements that the community ...has. And those two things are not the same. And I certainly –I will put my IETF hat on here for a second and say that I think from an IETF perspective the important thing is that a protocol parameters functions can continue to be performed, not that they can only continue to be performed by ICANN." >> >> I don't think this argument of Alissa was ever answered. It seems like there could be ways of drafting these sections that do not commit us to a specific contract but makes it clear that performance of the IANA functions is not challengable as a mission violation so long as the community actually wants ICANN to perform those functions. >> >> Indeed, I am having trouble understanding the threat that these sections are supposed to avoid. >> >> However, the most dangerous mission-limitation-busting potential is in the renewals section (F). This is problematic partly because the CCWG never agreed to exempt renewals. We agreed to grandfather existing agreements, for the sake of stability. But the assumption was that if anything in these existing agreements contravened the new mission limitations, that they COULD be challenged during a renewal process. A contract renewal with a registry could include all kinds of regulatory measures that exceed the mission, and if these measures are framed as a "renewal of an existing agreement" then ICANN could in principle get away with anything. >> >> So I hope we are able to make it clear to ICANN and the CCWG that these provisions need to be changed.. >> >> >> From: Alissa Cooper [mailto:alissa at cooperw.in] >> Sent: Friday, April 29, 2016 3:00 PM >> To: Mueller, Milton L >> Cc: Lynn St.Amour ; IANA etc etcCoordination Group >> Subject: Re: [Internal-cg] bylaws feedback >> >> For folks following this issue, it is definitely worth reading the transcript or listening to the recording of the last CCWG call: https://community.icann.org/pages/viewpage.action?pageId=58730392 >> >> The more that I have thought about this, it has become clear to me that the core issue here is that there is a portion of bylaws section 1.1(d) that is not called for either by our proposal or by the CCWG proposal, as Lynn says. Had the content of 1.1(d)(ii)(B-E) been discussed as part of the transition proposal development, I think the concerns being raised now would have been raised then, and the whole community would have had time to sort them out. (I note that there was an extended discussion about RA/RAA agreements in the CCWG and that did result in text in its proposal in paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not extend to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been created out of whole cloth by the bylaws drafting team, and that was not within their remit in my opinion. The Bylaws are just supposed to implement the proposals. >> >> I think there are substantive issues too, but from an ICG perspective we may or may not want to focus on those. >> >> I would support sending a comment. We sent a message early on during the bylaws drafting and received no response, and the call to discuss this didn’t even occur until after the bylaws were put out for public comment. >> >> Alissa >> >> >> On Apr 29, 2016, at 11:17 AM, Mueller, Milton L wrote: >> >> I support what you are saying. I take it you are not satisfied with the lawyers' explanation? I was not able to attend the 0:400 call a few days ago so was not able to question them about it or hear their answers. >> >> --MM >> >> >> -----Original Message----- >> From: Lynn St.Amour [mailto:Lynn at LStAmour.org] >> Sent: Friday, April 29, 2016 1:55 PM >> To: Alissa Cooper ; Mueller, Milton L >> ; IANA etc etcCoordination Group > cg at ianacg.org> >> Subject: Re: [Internal-cg] bylaws feedback >> >> Hi Alissa, Milton, all, >> >> I would like to come back to this subject. Specifically, I would like to propose >> that the ICG send in a statement to the By-laws comment period. >> >> Alissa commented on a specific concern (see thread below) and I also believe >> the ICG should be concerned about the overreach in the draft bylaws. >> >> My main concerns are: >> >> - the fact that these draft by-laws, through the grand-fathering provisions, >> allow external agreements to define ICANN's Mission which seems like a bad >> idea for many reasons. Further, this contradicts the desires of the community >> (or is a run around the community - intentional or not) who worked hard to >> clarify and correctly state ICANN’s mission throughout the IANA Transition >> process (paragraphs 140-144 of the CCWG-Accountability proposal). >> >> - the ICG process was fashioned to ensure that the transition plans reflected >> the consensus of the Internet community. And, it was to respect the roles and >> responsibilities of the OCs in defining their own transition plans. The ICG and >> the CCWG reports define those wishes, and any changes to the bylaws were to >> be to implement those wishes, nothing more. Yet provisions in sections >> 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- >> Accountability proposals, and so there has not been appropriate community >> involvement or review for those changes. Note: these sections affect much >> of the Internet community, as they apply to agreements between ICANN and >> the ASO, NRO, IETF, Root Zone Maintainer, and PTI. >> >> For transparency: the IAB/IETF are also concerned about the overreach and >> are drafting their own comments, and as an IAB appointee to the ICG, I am >> part of that review as well. >> >> If there is support for the ICG sending in a comment, I would be happy to work >> with Alissa and others to draft something for ICG review. >> >> Regards, >> Lynn >> >> >> >> On Apr 12, 2016, at 3:15 PM, Alissa Cooper wrote: >> >> From the minutes it looks like this was discussed on the CCWG call and there >> will be follow-up. >> >> >> >> On Apr 12, 2016, at 8:39 AM, Mueller, Milton L >> wrote: >> >> >> I sent it yesterday but there has been no response at all. >> >> >> >> -----Original Message----- >> From: Alissa Cooper [mailto:alissa at cooperw.in] >> Sent: Monday, April 11, 2016 4:54 PM >> To: Mueller, Milton L >> Cc: IANA etc etcCoordination Group >> Subject: Re: [Internal-cg] bylaws feedback >> >> I think that would be fine. >> >> Thanks, >> Alissa >> >> >> On Apr 11, 2016, at 1:04 PM, Mueller, Milton L >> wrote: >> >> >> Alissa >> If you don't mind I will just forward your message to the bylaws >> and CWG >> lists. >> >> If there is some other way you want me to do this, please let me know. >> >> --MM >> >> >> -----Original Message----- >> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On >> Behalf Of Alissa Cooper >> Sent: Monday, April 11, 2016 1:49 PM >> To: IANA etc etcCoordination Group >> Subject: [Internal-cg] bylaws feedback >> >> I have looked a bit at the draft bylaws and I’d like to ask >> Kavouss and Milton to bring the following issue back to the bylaws >> drafting group: >> >> >> Section 1.1(d)(ii) incorporates by reference a number of documents >> external to the bylaws as a means to prevent challenges on the >> basis that those documents conflict with or violate the bylaws. In >> particular, bullet (D) applies this provision to "the IANA Naming >> Function Contract between ICANN and PTI effective [October 1, 2016]." >> >> Given the ICG's historical encouragement of the community to meet >> timelines necessary for a successful transition, I find this >> provision to be extremely problematic. It incorporates a reference >> to a document that does not exist yet and that is unlikely to be >> completed by the time the bylaws are supposed to be done (early >> June). In fact, it is not even clear at this point whether the new >> ICANN affiliate to be setup will be name "PTI" or have some other >> name. I don't understand how anyone can reason about whether >> 1.1(d)(ii) is an acceptable bylaws provision if it references a >> document that has not been written. (This also applies to (B) and >> (C) since it could apply to future documents that haven’t been >> written >> yet.) >> >> Furthermore, I question whether it is a sound decision to >> essentially allow for documents external to the bylaws to be able >> to modify the bylaws (under (F)). This section would make more >> sense if it was entirely internally specified, without the >> references to external documents. At a minimum, I think we should >> recommend that (D) be >> removed. >> >> >> Thanks, >> Alissa >> _______________________________________________ >> Internal-cg mailing list >> Internal-cg at mm.ianacg.org >> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org > > _______________________________________________ > Internal-cg mailing list > Internal-cg at mm.ianacg.org > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org From milton at gatech.edu Tue May 3 16:59:42 2016 From: milton at gatech.edu (Mueller, Milton L) Date: Tue, 3 May 2016 16:59:42 +0000 Subject: [Internal-cg] bylaws feedback In-Reply-To: <7CCC84D4-1E20-41B8-8F41-4D06A9291F82@cooperw.in> References: <79AB2AAA-ECED-4A05-A437-16F100D664EE@cooperw.in> <6170505D-57EB-4017-A9B6-68D37E9EF4EF@cooperw.in> <5978117D-AD72-4C5B-80D2-24CAED51A922@LStAmour.org> <648952D9-5962-4E6D-8271-55AE178F9113@cooperw.in> <7CCC84D4-1E20-41B8-8F41-4D06A9291F82@cooperw.in> Message-ID: (F) applies the grandfathering to renewals of the agreements appearing in (B)-(D). MM: not correct: (F) applies the grandfathering to renewals of A – D. It reads: “(F) any renewals of agreements described in subsections (A)-(D) pursuant to their terms and conditions for renewal.” As I said in my initial comment, renewals of RA and RAA agreements are the most susceptible to bypassing mission limitations, because ICANN has the most expansive powers over names and the names community, unlike numbers and protocols, has not created a viable mechanism for changing the IFO. Picture this scenario: ICANN adds a highly regulatory requirement to the .com contract renewal; requiring it to pre-screen content in all .com second-level registrations. We might say, “this obviously violates the prohibition of content regulation in the mission statement,” but ICANN legal replies: “oh no, this is a renewal of the com agreement and therefore it is exempt from any such challenge.” If someone can show me that I am wrong legally about this possibility I’d be happy to drop it. But I haven’t seen any convincing arguments as to how this would not be possible. Therefore it would be extremely difficult for me to sign on to this statement if it does not mention the RA/RAA renewals problem and I frankly think we’d be missing the boat in a big way. --MM The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. Regards, Alissa Cooper on behalf of the ICG [1] http://mm.icann.org/pipermail/cwg-stewardship/2016-April/004877.html On Apr 30, 2016, at 8:16 AM, Mueller, Milton L > wrote: Ok, I have had time to read the transcript. I am even more strongly committed to developing a comment as ICG. Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that allows all of the work that was done to more precisely define the mission statement of ICANN in these bylaws ...to be completely contravened by whatever gets written into the ICANN PTI contract Because what this is says is that no one in the future will ever be able to challenge that contract on the basis that it contravenes the mission.” [and, I might add, the RZM contract, and renewals of registry contracts]. The only answer I saw to this was that we don’t need to worry about it because the PTI contract will be put up for public comment. Alissa also made the point: "this memo ... seems to imply that ... the most important thing out of all of this is that ICANN can continue to perform the IANA function. And I think what we all learned in (unintelligible) in terms of what the ICG proposal says is that in fact that is not the most important thing. The most important thing is that the IANA functions can continue to be performed by some operator who’s capable of performing them according to the service level agreements that the community ...has. And those two things are not the same. And I certainly –I will put my IETF hat on here for a second and say that I think from an IETF perspective the important thing is that a protocol parameters functions can continue to be performed, not that they can only continue to be performed by ICANN." I don't think this argument of Alissa was ever answered. It seems like there could be ways of drafting these sections that do not commit us to a specific contract but makes it clear that performance of the IANA functions is not challengable as a mission violation so long as the community actually wants ICANN to perform those functions. Indeed, I am having trouble understanding the threat that these sections are supposed to avoid. However, the most dangerous mission-limitation-busting potential is in the renewals section (F). This is problematic partly because the CCWG never agreed to exempt renewals. We agreed to grandfather existing agreements, for the sake of stability. But the assumption was that if anything in these existing agreements contravened the new mission limitations, that they COULD be challenged during a renewal process. A contract renewal with a registry could include all kinds of regulatory measures that exceed the mission, and if these measures are framed as a "renewal of an existing agreement" then ICANN could in principle get away with anything. So I hope we are able to make it clear to ICANN and the CCWG that these provisions need to be changed.. From: Alissa Cooper [mailto:alissa at cooperw.in] Sent: Friday, April 29, 2016 3:00 PM To: Mueller, Milton L > Cc: Lynn St.Amour >; IANA etc etcCoordination Group > Subject: Re: [Internal-cg] bylaws feedback For folks following this issue, it is definitely worth reading the transcript or listening to the recording of the last CCWG call: https://community.icann.org/pages/viewpage.action?pageId=58730392 The more that I have thought about this, it has become clear to me that the core issue here is that there is a portion of bylaws section 1.1(d) that is not called for either by our proposal or by the CCWG proposal, as Lynn says. Had the content of 1.1(d)(ii)(B-E) been discussed as part of the transition proposal development, I think the concerns being raised now would have been raised then, and the whole community would have had time to sort them out. (I note that there was an extended discussion about RA/RAA agreements in the CCWG and that did result in text in its proposal in paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not extend to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been created out of whole cloth by the bylaws drafting team, and that was not within their remit in my opinion. The Bylaws are just supposed to implement the proposals. I think there are substantive issues too, but from an ICG perspective we may or may not want to focus on those. I would support sending a comment. We sent a message early on during the bylaws drafting and received no response, and the call to discuss this didn’t even occur until after the bylaws were put out for public comment. Alissa On Apr 29, 2016, at 11:17 AM, Mueller, Milton L > wrote: I support what you are saying. I take it you are not satisfied with the lawyers' explanation? I was not able to attend the 0:400 call a few days ago so was not able to question them about it or hear their answers. --MM -----Original Message----- From: Lynn St.Amour [mailto:Lynn at LStAmour.org] Sent: Friday, April 29, 2016 1:55 PM To: Alissa Cooper >; Mueller, Milton L >; IANA etc etcCoordination Group > Subject: Re: [Internal-cg] bylaws feedback Hi Alissa, Milton, all, I would like to come back to this subject. Specifically, I would like to propose that the ICG send in a statement to the By-laws comment period. Alissa commented on a specific concern (see thread below) and I also believe the ICG should be concerned about the overreach in the draft bylaws. My main concerns are: - the fact that these draft by-laws, through the grand-fathering provisions, allow external agreements to define ICANN's Mission which seems like a bad idea for many reasons. Further, this contradicts the desires of the community (or is a run around the community - intentional or not) who worked hard to clarify and correctly state ICANN’s mission throughout the IANA Transition process (paragraphs 140-144 of the CCWG-Accountability proposal). - the ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community. And, it was to respect the roles and responsibilities of the OCs in defining their own transition plans. The ICG and the CCWG reports define those wishes, and any changes to the bylaws were to be to implement those wishes, nothing more. Yet provisions in sections 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- Accountability proposals, and so there has not been appropriate community involvement or review for those changes. Note: these sections affect much of the Internet community, as they apply to agreements between ICANN and the ASO, NRO, IETF, Root Zone Maintainer, and PTI. For transparency: the IAB/IETF are also concerned about the overreach and are drafting their own comments, and as an IAB appointee to the ICG, I am part of that review as well. If there is support for the ICG sending in a comment, I would be happy to work with Alissa and others to draft something for ICG review. Regards, Lynn On Apr 12, 2016, at 3:15 PM, Alissa Cooper > wrote: From the minutes it looks like this was discussed on the CCWG call and there will be follow-up. On Apr 12, 2016, at 8:39 AM, Mueller, Milton L > wrote: I sent it yesterday but there has been no response at all. -----Original Message----- From: Alissa Cooper [mailto:alissa at cooperw.in] Sent: Monday, April 11, 2016 4:54 PM To: Mueller, Milton L > Cc: IANA etc etcCoordination Group > Subject: Re: [Internal-cg] bylaws feedback I think that would be fine. Thanks, Alissa On Apr 11, 2016, at 1:04 PM, Mueller, Milton L > wrote: Alissa If you don't mind I will just forward your message to the bylaws and CWG lists. If there is some other way you want me to do this, please let me know. --MM -----Original Message----- From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of Alissa Cooper Sent: Monday, April 11, 2016 1:49 PM To: IANA etc etcCoordination Group > Subject: [Internal-cg] bylaws feedback I have looked a bit at the draft bylaws and I’d like to ask Kavouss and Milton to bring the following issue back to the bylaws drafting group: Section 1.1(d)(ii) incorporates by reference a number of documents external to the bylaws as a means to prevent challenges on the basis that those documents conflict with or violate the bylaws. In particular, bullet (D) applies this provision to "the IANA Naming Function Contract between ICANN and PTI effective [October 1, 2016]." Given the ICG's historical encouragement of the community to meet timelines necessary for a successful transition, I find this provision to be extremely problematic. It incorporates a reference to a document that does not exist yet and that is unlikely to be completed by the time the bylaws are supposed to be done (early June). In fact, it is not even clear at this point whether the new ICANN affiliate to be setup will be name "PTI" or have some other name. I don't understand how anyone can reason about whether 1.1(d)(ii) is an acceptable bylaws provision if it references a document that has not been written. (This also applies to (B) and (C) since it could apply to future documents that haven’t been written yet.) Furthermore, I question whether it is a sound decision to essentially allow for documents external to the bylaws to be able to modify the bylaws (under (F)). This section would make more sense if it was entirely internally specified, without the references to external documents. At a minimum, I think we should recommend that (D) be removed. Thanks, Alissa _______________________________________________ Internal-cg mailing list Internal-cg at mm.ianacg.org http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseph.alhadeff at oracle.com Tue May 3 17:05:37 2016 From: joseph.alhadeff at oracle.com (joseph.alhadeff) Date: Tue, 03 May 2016 10:05:37 -0700 Subject: [Internal-cg] bylaws feedback Message-ID: I am in general support of the letter.  I think we could be a bit tighter on how these changes to mission and u drafted documents may result in actions/circumstances inconsistent with the community consensus reached in the transition proposals... Joe Sent via the Samsung GALAXY S® 5, an AT&T 4G LTE smartphone -------- Original message -------- From: "Lynn St.Amour" Date: 5/3/2016 9:21 AM (GMT-08:00) To: Alissa Cooper Cc: IANA Stewardship Transition Coordination Group Subject: Re: [Internal-cg] bylaws feedback Hi Alissa, I support this draft and strongly support sending the letter.   It is important that the wishes of the community and the Operating Communities be respected. In my experience, it is also unusual for a Mission statement to be so referenced and so legally encumbered.   Best, Lynn PS.  Would be really good to hear from other ICG members, as well. > On May 2, 2016, at 7:01 PM, Alissa Cooper wrote: > > I’ve put together an initial draft comment below, using Lynn’s email as the base. Please send feedback/edits. > > I am a little leery of raising the issue Milton points out below about RA/RAA renewals, since that is more a question about what was discussed and agreed in the CCWG proposal and how paragraph 147 of the CCWG proposal is being interpreted, as compared to the other arguments which are about whole new provisions that were added without reference to any proposal text or community discussion. I tried to remain non-commital on this point in the text below. > > — > > The ICG appreciates the opportunity to comment on the draft ICANN Bylaws. > > The ICG previously communicated concerns about Section 1.1(d)(ii) to the Bylaws drafting group [1]. However, these concerns were not addressed in the draft Bylaws that were posted for public comment. > > Section 1.1(d) "grandfathers" a number of agreements into the Bylaws in order to prevent parties from challenging those agreements on the basis that they violate the ICANN Mission statement. Under Section 1.1(d)(ii), (A) applies to RA/RAA agreements; (B)-(D) apply to agreements between ICANN and the NRO, ASO, IETF, RZM, and PTI; and (E) applies to ICANN's Five-Year Strategic Plan and Five-Year Operating Plan. (F) applies the grandfathering to renewals of the agreements appearing in (B)-(D). > > The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more.  Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. > > Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). > > The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. > > Regards, > > Alissa Cooper on behalf of the ICG > > > [1] http://mm.icann.org/pipermail/cwg-stewardship/2016-April/004877.html > > >> On Apr 30, 2016, at 8:16 AM, Mueller, Milton L wrote: >> >> Ok, I have had time to read the transcript. I am even more strongly committed to developing a comment as ICG. >>  >> Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that allows all of the work that was done to more precisely define the mission statement of ICANN in these bylaws ...to be completely contravened by whatever gets written into the ICANN PTI contract Because what this is says is that no one in the future will ever be able to challenge that contract on the basis that it contravenes the mission.” >>  >> [and, I might add, the RZM contract, and renewals of registry contracts]. >>  >> The only answer I saw to this was that we don’t need to worry about it because the PTI contract will be put up for public comment. >>  >> Alissa also made the point: >> "this memo ... seems to imply that ... the most important thing out of all of this is that ICANN can continue to perform the IANA function. And I think what we all learned in (unintelligible) in terms of what the ICG proposal says is that in fact that is not the most important thing. The most important thing is that the IANA functions can continue to be performed by some operator who’s capable of performing them according to the service level agreements that the community ...has. And those two things are not the same. And I certainly –I will put my IETF hat on here for a second and say that I think from an IETF perspective the important thing is that a protocol parameters functions can continue to be performed, not that they can only continue to be performed by ICANN." >>  >> I don't think this argument of Alissa was ever answered. It seems like there could be ways of drafting these sections that do not commit us to a specific contract but makes it clear that performance of the IANA functions is not challengable as a mission violation so long as the community actually wants ICANN to perform those functions. >>  >> Indeed, I am having trouble understanding the threat that these sections are supposed to avoid. >>  >> However, the most dangerous mission-limitation-busting potential is in the renewals section (F). This is problematic partly because the CCWG never agreed to exempt renewals. We agreed to grandfather existing agreements, for the sake of stability. But the assumption was that if anything in these existing agreements contravened the new mission limitations, that they COULD be challenged during a renewal process. A contract renewal with a registry could include all kinds of regulatory measures that exceed the mission, and if these measures are framed as a "renewal of an existing agreement" then ICANN could in principle get away with anything. >>  >> So I hope we are able to make it clear to ICANN and the CCWG that these provisions need to be changed.. >>  >>  >> From: Alissa Cooper [mailto:alissa at cooperw.in] >> Sent: Friday, April 29, 2016 3:00 PM >> To: Mueller, Milton L >> Cc: Lynn St.Amour ; IANA etc etcCoordination Group >> Subject: Re: [Internal-cg] bylaws feedback >>  >> For folks following this issue, it is definitely worth reading the transcript or listening to the recording of the last CCWG call: https://community.icann.org/pages/viewpage.action?pageId=58730392 >>  >> The more that I have thought about this, it has become clear to me that the core issue here is that there is a portion of bylaws section 1.1(d) that is not called for either by our proposal or by the CCWG proposal, as Lynn says. Had the content of 1.1(d)(ii)(B-E) been discussed as part of the transition proposal development, I think the concerns being raised now would have been raised then, and the whole community would have had time to sort them out. (I note that there was an extended discussion about RA/RAA agreements in the CCWG and that did result in text in its proposal in paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not extend to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been created out of whole cloth by the bylaws drafting team, and that was not within their remit in my opinion. The Bylaws are just supposed to implement the proposals. >>  >> I think there are substantive issues too, but from an ICG perspective we may or may not want to focus on those. >>  >> I would support sending a comment. We sent a message early on during the bylaws drafting and received no response, and the call to discuss this didn’t even occur until after the bylaws were put out for public comment. >>  >> Alissa >>  >>  >> On Apr 29, 2016, at 11:17 AM, Mueller, Milton L wrote: >>  >> I support what you are saying. I take it you are not satisfied with the lawyers' explanation? I was not able to attend the 0:400 call a few days ago so was not able to question them about it or hear their answers. >> >> --MM >> >> >> -----Original Message----- >> From: Lynn St.Amour [mailto:Lynn at LStAmour.org] >> Sent: Friday, April 29, 2016 1:55 PM >> To: Alissa Cooper ; Mueller, Milton L >> ; IANA etc etcCoordination Group > cg at ianacg.org> >> Subject: Re: [Internal-cg] bylaws feedback >> >> Hi Alissa, Milton, all, >> >> I would like to come back to this subject.  Specifically, I would like to propose >> that the ICG send in a statement to the By-laws comment period. >> >> Alissa commented on a specific concern (see thread below) and I also believe >> the ICG should be concerned about the overreach in the draft bylaws. >> >> My main concerns are: >> >> - the fact that these draft by-laws, through the grand-fathering provisions, >> allow external agreements to define ICANN's Mission which seems like a bad >> idea for many reasons.  Further, this contradicts the desires of the community >> (or is a run around the community - intentional or not) who worked hard to >> clarify and correctly state ICANN’s mission throughout the IANA Transition >> process (paragraphs 140-144 of the CCWG-Accountability proposal). >> >> - the ICG process was fashioned to ensure that the transition plans reflected >> the consensus of the Internet community.  And, it was to respect the roles and >> responsibilities of the OCs in defining their own transition plans.  The ICG and >> the CCWG reports define those wishes, and any changes to the bylaws were to >> be to implement those wishes, nothing more.  Yet provisions in sections >> 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- >> Accountability proposals, and so there has not been appropriate community >> involvement or review for those changes.   Note: these sections affect much >> of the Internet community, as they apply to agreements between ICANN and >> the ASO, NRO, IETF, Root Zone Maintainer, and PTI. >> >> For transparency: the IAB/IETF are also concerned about the overreach and >> are drafting their own comments, and as an IAB appointee to the ICG, I am >> part of that review as well. >> >> If there is support for the ICG sending in a comment, I would be happy to work >> with Alissa and others to draft something for ICG review. >> >> Regards, >> Lynn >> >> >> >> On Apr 12, 2016, at 3:15 PM, Alissa Cooper wrote: >> >> From the minutes it looks like this was discussed on the CCWG call and there >> will be follow-up. >> >> >> >> On Apr 12, 2016, at 8:39 AM, Mueller, Milton L >> wrote: >> >> >> I sent it yesterday but there has been no response at all. >> >> >> >> -----Original Message----- >> From: Alissa Cooper [mailto:alissa at cooperw.in] >> Sent: Monday, April 11, 2016 4:54 PM >> To: Mueller, Milton L >> Cc: IANA etc etcCoordination Group >> Subject: Re: [Internal-cg] bylaws feedback >> >> I think that would be fine. >> >> Thanks, >> Alissa >> >> >> On Apr 11, 2016, at 1:04 PM, Mueller, Milton L >> wrote: >> >> >> Alissa >> If you don't mind I will just forward your message to the bylaws >> and CWG >> lists. >> >> If there is some other way you want me to do this, please let me know. >> >> --MM >> >> >> -----Original Message----- >> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On >> Behalf Of Alissa Cooper >> Sent: Monday, April 11, 2016 1:49 PM >> To: IANA etc etcCoordination Group >> Subject: [Internal-cg] bylaws feedback >> >> I have looked a bit at the draft bylaws and I’d like to ask >> Kavouss and Milton to bring the following issue back to the bylaws >> drafting group: >> >> >> Section 1.1(d)(ii) incorporates by reference a number of documents >> external to the bylaws as a means to prevent challenges on the >> basis that those documents conflict with or violate the bylaws. In >> particular, bullet (D) applies this provision to "the IANA Naming >> Function Contract between ICANN and PTI effective [October 1, 2016]." >> >> Given the ICG's historical encouragement of the community to meet >> timelines necessary for a successful transition, I find this >> provision to be extremely problematic. It incorporates a reference >> to a document that does not exist yet and that is unlikely to be >> completed by the time the bylaws are supposed to be done (early >> June). In fact, it is not even clear at this point whether the new >> ICANN affiliate to be setup will be name "PTI" or have some other >> name. I don't understand how anyone can reason about whether >> 1.1(d)(ii) is an acceptable bylaws provision if it references a >> document that has not been written. (This also applies to (B) and >> (C) since it could apply to future documents that haven’t been >> written >> yet.) >> >> Furthermore, I question whether it is a sound decision to >> essentially allow for documents external to the bylaws to be able >> to modify the bylaws (under (F)). This section would make more >> sense if it was entirely internally specified, without the >> references to external documents. At a minimum, I think we should >> recommend that (D) be >> removed. >> >> >> Thanks, >> Alissa >> _______________________________________________ >> Internal-cg mailing list >> Internal-cg at mm.ianacg.org >> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org > > _______________________________________________ > Internal-cg mailing list > Internal-cg at mm.ianacg.org > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org _______________________________________________ Internal-cg mailing list Internal-cg at mm.ianacg.org http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From alissa at cooperw.in Tue May 3 21:10:29 2016 From: alissa at cooperw.in (Alissa Cooper) Date: Tue, 3 May 2016 14:10:29 -0700 Subject: [Internal-cg] bylaws feedback In-Reply-To: References: <79AB2AAA-ECED-4A05-A437-16F100D664EE@cooperw.in> <6170505D-57EB-4017-A9B6-68D37E9EF4EF@cooperw.in> <5978117D-AD72-4C5B-80D2-24CAED51A922@LStAmour.org> <648952D9-5962-4E6D-8271-55AE178F9113@cooperw.in> <7CCC84D4-1E20-41B8-8F41-4D06A9291F82@cooperw.in> Message-ID: <89F2259E-12EC-4990-987C-1193DD381938@cooperw.in> I don’t have an opinion about the substance of the RA/RAA renewals, but I don’t think they are within the scope of what the ICG should comment on. The renewal of RA and RAA agreements were discussed on today’s CCWG call (as well as on several previous CCWG calls and the CCWG mailing list). It appears that the CCWG will be commenting on these renewals in its own comments about the Bylaws, and will be supporting the existing language in (F) as it applies to the RA and RAA agreements. Considering that the CCWG appears to have discussed this topic at great length and has consensus on it, I don’t think the same argument we are making about (B)-(E) applies to the RA/RAA renewals. The CCWG is planning to submit its comments by May 10, so there should be more clarity about exactly what they intend to say soon. Alissa > On May 3, 2016, at 9:59 AM, Mueller, Milton L wrote: > > (F) applies the grandfathering to renewals of the agreements appearing in (B)-(D). > > MM: not correct: (F) applies the grandfathering to renewals of A – D. It reads: > > “(F) any renewals of agreements described in subsections (A)-(D) pursuant to their terms and conditions for renewal.” > > As I said in my initial comment, renewals of RA and RAA agreements are the most susceptible to bypassing mission limitations, because ICANN has the most expansive powers over names and the names community, unlike numbers and protocols, has not created a viable mechanism for changing the IFO. > > Picture this scenario: ICANN adds a highly regulatory requirement to the .com contract renewal; requiring it to pre-screen content in all .com second-level registrations. We might say, “this obviously violates the prohibition of content regulation in the mission statement,” but ICANN legal replies: “oh no, this is a renewal of the com agreement and therefore it is exempt from any such challenge.” > > If someone can show me that I am wrong legally about this possibility I’d be happy to drop it. But I haven’t seen any convincing arguments as to how this would not be possible. > > Therefore it would be extremely difficult for me to sign on to this statement if it does not mention the RA/RAA renewals problem and I frankly think we’d be missing the boat in a big way. > > --MM > > The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. > > Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). > > The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. > > Regards, > > Alissa Cooper on behalf of the ICG > > > [1] http://mm.icann.org/pipermail/cwg-stewardship/2016-April/004877.html > > > On Apr 30, 2016, at 8:16 AM, Mueller, Milton L > wrote: > > Ok, I have had time to read the transcript. I am even more strongly committed to developing a comment as ICG. > > Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that allows all of the work that was done to more precisely define the mission statement of ICANN in these bylaws ...to be completely contravened by whatever gets written into the ICANN PTI contract Because what this is says is that no one in the future will ever be able to challenge that contract on the basis that it contravenes the mission.” > > [and, I might add, the RZM contract, and renewals of registry contracts]. > > The only answer I saw to this was that we don’t need to worry about it because the PTI contract will be put up for public comment. > > Alissa also made the point: > "this memo ... seems to imply that ... the most important thing out of all of this is that ICANN can continue to perform the IANA function. And I think what we all learned in (unintelligible) in terms of what the ICG proposal says is that in fact that is not the most important thing. The most important thing is that the IANA functions can continue to be performed by some operator who’s capable of performing them according to the service level agreements that the community ...has. And those two things are not the same. And I certainly –I will put my IETF hat on here for a second and say that I think from an IETF perspective the important thing is that a protocol parameters functions can continue to be performed, not that they can only continue to be performed by ICANN." > > I don't think this argument of Alissa was ever answered. It seems like there could be ways of drafting these sections that do not commit us to a specific contract but makes it clear that performance of the IANA functions is not challengable as a mission violation so long as the community actually wants ICANN to perform those functions. > > Indeed, I am having trouble understanding the threat that these sections are supposed to avoid. > > However, the most dangerous mission-limitation-busting potential is in the renewals section (F). This is problematic partly because the CCWG never agreed to exempt renewals. We agreed to grandfather existing agreements, for the sake of stability. But the assumption was that if anything in these existing agreements contravened the new mission limitations, that they COULD be challenged during a renewal process. A contract renewal with a registry could include all kinds of regulatory measures that exceed the mission, and if these measures are framed as a "renewal of an existing agreement" then ICANN could in principle get away with anything. > > So I hope we are able to make it clear to ICANN and the CCWG that these provisions need to be changed.. > > > From: Alissa Cooper [mailto:alissa at cooperw.in ] > Sent: Friday, April 29, 2016 3:00 PM > To: Mueller, Milton L > > Cc: Lynn St.Amour >; IANA etc etcCoordination Group > > Subject: Re: [Internal-cg] bylaws feedback > > For folks following this issue, it is definitely worth reading the transcript or listening to the recording of the last CCWG call: https://community.icann.org/pages/viewpage.action?pageId=58730392 > > The more that I have thought about this, it has become clear to me that the core issue here is that there is a portion of bylaws section 1.1(d) that is not called for either by our proposal or by the CCWG proposal, as Lynn says. Had the content of 1.1(d)(ii)(B-E) been discussed as part of the transition proposal development, I think the concerns being raised now would have been raised then, and the whole community would have had time to sort them out. (I note that there was an extended discussion about RA/RAA agreements in the CCWG and that did result in text in its proposal in paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not extend to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been created out of whole cloth by the bylaws drafting team, and that was not within their remit in my opinion. The Bylaws are just supposed to implement the proposals. > > I think there are substantive issues too, but from an ICG perspective we may or may not want to focus on those. > > I would support sending a comment. We sent a message early on during the bylaws drafting and received no response, and the call to discuss this didn’t even occur until after the bylaws were put out for public comment. > > Alissa > > > On Apr 29, 2016, at 11:17 AM, Mueller, Milton L > wrote: > > I support what you are saying. I take it you are not satisfied with the lawyers' explanation? I was not able to attend the 0:400 call a few days ago so was not able to question them about it or hear their answers. > > --MM > > > > -----Original Message----- > From: Lynn St.Amour [mailto:Lynn at LStAmour.org ] > Sent: Friday, April 29, 2016 1:55 PM > To: Alissa Cooper >; Mueller, Milton L > >; IANA etc etcCoordination Group cg at ianacg.org > > Subject: Re: [Internal-cg] bylaws feedback > > Hi Alissa, Milton, all, > > I would like to come back to this subject. Specifically, I would like to propose > that the ICG send in a statement to the By-laws comment period. > > Alissa commented on a specific concern (see thread below) and I also believe > the ICG should be concerned about the overreach in the draft bylaws. > > My main concerns are: > > - the fact that these draft by-laws, through the grand-fathering provisions, > allow external agreements to define ICANN's Mission which seems like a bad > idea for many reasons. Further, this contradicts the desires of the community > (or is a run around the community - intentional or not) who worked hard to > clarify and correctly state ICANN’s mission throughout the IANA Transition > process (paragraphs 140-144 of the CCWG-Accountability proposal). > > - the ICG process was fashioned to ensure that the transition plans reflected > the consensus of the Internet community. And, it was to respect the roles and > responsibilities of the OCs in defining their own transition plans. The ICG and > the CCWG reports define those wishes, and any changes to the bylaws were to > be to implement those wishes, nothing more. Yet provisions in sections > 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- > Accountability proposals, and so there has not been appropriate community > involvement or review for those changes. Note: these sections affect much > of the Internet community, as they apply to agreements between ICANN and > the ASO, NRO, IETF, Root Zone Maintainer, and PTI. > > For transparency: the IAB/IETF are also concerned about the overreach and > are drafting their own comments, and as an IAB appointee to the ICG, I am > part of that review as well. > > If there is support for the ICG sending in a comment, I would be happy to work > with Alissa and others to draft something for ICG review. > > Regards, > Lynn > > > > > On Apr 12, 2016, at 3:15 PM, Alissa Cooper > wrote: > > From the minutes it looks like this was discussed on the CCWG call and there > will be follow-up. > > > > > > On Apr 12, 2016, at 8:39 AM, Mueller, Milton L > > wrote: > > > > I sent it yesterday but there has been no response at all. > > > > > -----Original Message----- > From: Alissa Cooper [mailto:alissa at cooperw.in ] > Sent: Monday, April 11, 2016 4:54 PM > To: Mueller, Milton L > > Cc: IANA etc etcCoordination Group > > Subject: Re: [Internal-cg] bylaws feedback > > I think that would be fine. > > Thanks, > Alissa > > > > On Apr 11, 2016, at 1:04 PM, Mueller, Milton L > > wrote: > > > > Alissa > If you don't mind I will just forward your message to the bylaws > and CWG > lists. > > > If there is some other way you want me to do this, please let me know. > > --MM > > > > -----Original Message----- > From: Internal-cg [mailto:internal-cg-bounces at ianacg.org ] On > Behalf Of Alissa Cooper > Sent: Monday, April 11, 2016 1:49 PM > To: IANA etc etcCoordination Group > > Subject: [Internal-cg] bylaws feedback > > I have looked a bit at the draft bylaws and I’d like to ask > Kavouss and Milton to bring the following issue back to the bylaws > drafting group: > > > > Section 1.1(d)(ii) incorporates by reference a number of documents > external to the bylaws as a means to prevent challenges on the > basis that those documents conflict with or violate the bylaws. In > particular, bullet (D) applies this provision to "the IANA Naming > Function Contract between ICANN and PTI effective [October 1, 2016]." > > Given the ICG's historical encouragement of the community to meet > timelines necessary for a successful transition, I find this > provision to be extremely problematic. It incorporates a reference > to a document that does not exist yet and that is unlikely to be > completed by the time the bylaws are supposed to be done (early > June). In fact, it is not even clear at this point whether the new > ICANN affiliate to be setup will be name "PTI" or have some other > name. I don't understand how anyone can reason about whether > 1.1(d)(ii) is an acceptable bylaws provision if it references a > document that has not been written. (This also applies to (B) and > (C) since it could apply to future documents that haven’t been > written > yet.) > > Furthermore, I question whether it is a sound decision to > essentially allow for documents external to the bylaws to be able > to modify the bylaws (under (F)). This section would make more > sense if it was entirely internally specified, without the > references to external documents. At a minimum, I think we should > recommend that (D) be > removed. > > > > Thanks, > Alissa > _______________________________________________ > Internal-cg mailing list > Internal-cg at mm.ianacg.org > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Boyle at nominet.uk Tue May 3 22:15:40 2016 From: Martin.Boyle at nominet.uk (Martin Boyle) Date: Tue, 3 May 2016 22:15:40 +0000 Subject: [Internal-cg] bylaws feedback In-Reply-To: <89F2259E-12EC-4990-987C-1193DD381938@cooperw.in> References: <79AB2AAA-ECED-4A05-A437-16F100D664EE@cooperw.in> <6170505D-57EB-4017-A9B6-68D37E9EF4EF@cooperw.in> <5978117D-AD72-4C5B-80D2-24CAED51A922@LStAmour.org> <648952D9-5962-4E6D-8271-55AE178F9113@cooperw.in> <7CCC84D4-1E20-41B8-8F41-4D06A9291F82@cooperw.in> <89F2259E-12EC-4990-987C-1193DD381938@cooperw.in> Message-ID: Hi Alissa, all, I agree with you, Alissa. This sort of detail does seem to me to go well beyond the remit of the ICG and we should certainly not be seeking to upset areas already agreed in the CCWG-Accountability process. For the rest of this, I am afraid I have not been following the CCWG process carefully enough to have a view of where the text bylaw drafting goes beyond the consensus of the proposal. I’ll try to look at it tomorrow, but on my cursory reading of the arguments below, this does look like a legitimate input from the ICG. Hope this helps Martin From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of Alissa Cooper Sent: 03 May 2016 22:10 To: Mueller, Milton L Cc: Lynn St.Amour ; IANA etc etcCoordination Group Subject: Re: [Internal-cg] bylaws feedback I don’t have an opinion about the substance of the RA/RAA renewals, but I don’t think they are within the scope of what the ICG should comment on. The renewal of RA and RAA agreements were discussed on today’s CCWG call (as well as on several previous CCWG calls and the CCWG mailing list). It appears that the CCWG will be commenting on these renewals in its own comments about the Bylaws, and will be supporting the existing language in (F) as it applies to the RA and RAA agreements. Considering that the CCWG appears to have discussed this topic at great length and has consensus on it, I don’t think the same argument we are making about (B)-(E) applies to the RA/RAA renewals. The CCWG is planning to submit its comments by May 10, so there should be more clarity about exactly what they intend to say soon. Alissa On May 3, 2016, at 9:59 AM, Mueller, Milton L > wrote: (F) applies the grandfathering to renewals of the agreements appearing in (B)-(D). MM: not correct: (F) applies the grandfathering to renewals of A – D. It reads: “(F) any renewals of agreements described in subsections (A)-(D) pursuant to their terms and conditions for renewal.” As I said in my initial comment, renewals of RA and RAA agreements are the most susceptible to bypassing mission limitations, because ICANN has the most expansive powers over names and the names community, unlike numbers and protocols, has not created a viable mechanism for changing the IFO. Picture this scenario: ICANN adds a highly regulatory requirement to the .com contract renewal; requiring it to pre-screen content in all .com second-level registrations. We might say, “this obviously violates the prohibition of content regulation in the mission statement,” but ICANN legal replies: “oh no, this is a renewal of the com agreement and therefore it is exempt from any such challenge.” If someone can show me that I am wrong legally about this possibility I’d be happy to drop it. But I haven’t seen any convincing arguments as to how this would not be possible. Therefore it would be extremely difficult for me to sign on to this statement if it does not mention the RA/RAA renewals problem and I frankly think we’d be missing the boat in a big way. --MM The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. Regards, Alissa Cooper on behalf of the ICG [1] http://mm.icann.org/pipermail/cwg-stewardship/2016-April/004877.html On Apr 30, 2016, at 8:16 AM, Mueller, Milton L > wrote: Ok, I have had time to read the transcript. I am even more strongly committed to developing a comment as ICG. Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that allows all of the work that was done to more precisely define the mission statement of ICANN in these bylaws ...to be completely contravened by whatever gets written into the ICANN PTI contract Because what this is says is that no one in the future will ever be able to challenge that contract on the basis that it contravenes the mission.” [and, I might add, the RZM contract, and renewals of registry contracts]. The only answer I saw to this was that we don’t need to worry about it because the PTI contract will be put up for public comment. Alissa also made the point: "this memo ... seems to imply that ... the most important thing out of all of this is that ICANN can continue to perform the IANA function. And I think what we all learned in (unintelligible) in terms of what the ICG proposal says is that in fact that is not the most important thing. The most important thing is that the IANA functions can continue to be performed by some operator who’s capable of performing them according to the service level agreements that the community ...has. And those two things are not the same. And I certainly –I will put my IETF hat on here for a second and say that I think from an IETF perspective the important thing is that a protocol parameters functions can continue to be performed, not that they can only continue to be performed by ICANN." I don't think this argument of Alissa was ever answered. It seems like there could be ways of drafting these sections that do not commit us to a specific contract but makes it clear that performance of the IANA functions is not challengable as a mission violation so long as the community actually wants ICANN to perform those functions. Indeed, I am having trouble understanding the threat that these sections are supposed to avoid. However, the most dangerous mission-limitation-busting potential is in the renewals section (F). This is problematic partly because the CCWG never agreed to exempt renewals. We agreed to grandfather existing agreements, for the sake of stability. But the assumption was that if anything in these existing agreements contravened the new mission limitations, that they COULD be challenged during a renewal process. A contract renewal with a registry could include all kinds of regulatory measures that exceed the mission, and if these measures are framed as a "renewal of an existing agreement" then ICANN could in principle get away with anything. So I hope we are able to make it clear to ICANN and the CCWG that these provisions need to be changed.. From: Alissa Cooper [mailto:alissa at cooperw.in] Sent: Friday, April 29, 2016 3:00 PM To: Mueller, Milton L > Cc: Lynn St.Amour >; IANA etc etcCoordination Group > Subject: Re: [Internal-cg] bylaws feedback For folks following this issue, it is definitely worth reading the transcript or listening to the recording of the last CCWG call: https://community.icann.org/pages/viewpage.action?pageId=58730392 The more that I have thought about this, it has become clear to me that the core issue here is that there is a portion of bylaws section 1.1(d) that is not called for either by our proposal or by the CCWG proposal, as Lynn says. Had the content of 1.1(d)(ii)(B-E) been discussed as part of the transition proposal development, I think the concerns being raised now would have been raised then, and the whole community would have had time to sort them out. (I note that there was an extended discussion about RA/RAA agreements in the CCWG and that did result in text in its proposal in paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not extend to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been created out of whole cloth by the bylaws drafting team, and that was not within their remit in my opinion. The Bylaws are just supposed to implement the proposals. I think there are substantive issues too, but from an ICG perspective we may or may not want to focus on those. I would support sending a comment. We sent a message early on during the bylaws drafting and received no response, and the call to discuss this didn’t even occur until after the bylaws were put out for public comment. Alissa On Apr 29, 2016, at 11:17 AM, Mueller, Milton L > wrote: I support what you are saying. I take it you are not satisfied with the lawyers' explanation? I was not able to attend the 0:400 call a few days ago so was not able to question them about it or hear their answers. --MM -----Original Message----- From: Lynn St.Amour [mailto:Lynn at LStAmour.org] Sent: Friday, April 29, 2016 1:55 PM To: Alissa Cooper >; Mueller, Milton L >; IANA etc etcCoordination Group > Subject: Re: [Internal-cg] bylaws feedback Hi Alissa, Milton, all, I would like to come back to this subject. Specifically, I would like to propose that the ICG send in a statement to the By-laws comment period. Alissa commented on a specific concern (see thread below) and I also believe the ICG should be concerned about the overreach in the draft bylaws. My main concerns are: - the fact that these draft by-laws, through the grand-fathering provisions, allow external agreements to define ICANN's Mission which seems like a bad idea for many reasons. Further, this contradicts the desires of the community (or is a run around the community - intentional or not) who worked hard to clarify and correctly state ICANN’s mission throughout the IANA Transition process (paragraphs 140-144 of the CCWG-Accountability proposal). - the ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community. And, it was to respect the roles and responsibilities of the OCs in defining their own transition plans. The ICG and the CCWG reports define those wishes, and any changes to the bylaws were to be to implement those wishes, nothing more. Yet provisions in sections 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- Accountability proposals, and so there has not been appropriate community involvement or review for those changes. Note: these sections affect much of the Internet community, as they apply to agreements between ICANN and the ASO, NRO, IETF, Root Zone Maintainer, and PTI. For transparency: the IAB/IETF are also concerned about the overreach and are drafting their own comments, and as an IAB appointee to the ICG, I am part of that review as well. If there is support for the ICG sending in a comment, I would be happy to work with Alissa and others to draft something for ICG review. Regards, Lynn On Apr 12, 2016, at 3:15 PM, Alissa Cooper > wrote: From the minutes it looks like this was discussed on the CCWG call and there will be follow-up. On Apr 12, 2016, at 8:39 AM, Mueller, Milton L > wrote: I sent it yesterday but there has been no response at all. -----Original Message----- From: Alissa Cooper [mailto:alissa at cooperw.in] Sent: Monday, April 11, 2016 4:54 PM To: Mueller, Milton L > Cc: IANA etc etcCoordination Group > Subject: Re: [Internal-cg] bylaws feedback I think that would be fine. Thanks, Alissa On Apr 11, 2016, at 1:04 PM, Mueller, Milton L > wrote: Alissa If you don't mind I will just forward your message to the bylaws and CWG lists. If there is some other way you want me to do this, please let me know. --MM -----Original Message----- From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of Alissa Cooper Sent: Monday, April 11, 2016 1:49 PM To: IANA etc etcCoordination Group > Subject: [Internal-cg] bylaws feedback I have looked a bit at the draft bylaws and I’d like to ask Kavouss and Milton to bring the following issue back to the bylaws drafting group: Section 1.1(d)(ii) incorporates by reference a number of documents external to the bylaws as a means to prevent challenges on the basis that those documents conflict with or violate the bylaws. In particular, bullet (D) applies this provision to "the IANA Naming Function Contract between ICANN and PTI effective [October 1, 2016]." Given the ICG's historical encouragement of the community to meet timelines necessary for a successful transition, I find this provision to be extremely problematic. It incorporates a reference to a document that does not exist yet and that is unlikely to be completed by the time the bylaws are supposed to be done (early June). In fact, it is not even clear at this point whether the new ICANN affiliate to be setup will be name "PTI" or have some other name. I don't understand how anyone can reason about whether 1.1(d)(ii) is an acceptable bylaws provision if it references a document that has not been written. (This also applies to (B) and (C) since it could apply to future documents that haven’t been written yet.) Furthermore, I question whether it is a sound decision to essentially allow for documents external to the bylaws to be able to modify the bylaws (under (F)). This section would make more sense if it was entirely internally specified, without the references to external documents. At a minimum, I think we should recommend that (D) be removed. Thanks, Alissa _______________________________________________ Internal-cg mailing list Internal-cg at mm.ianacg.org http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjs at dyalog.net Wed May 4 06:28:20 2016 From: jjs at dyalog.net (Subrenat, Jean-Jacques) Date: Wed, 4 May 2016 08:28:20 +0200 (CEST) Subject: [Internal-cg] bylaws feedback In-Reply-To: Message-ID: <142976331.139.1462343299764.JavaMail.jjs-mac-2@macbook-air-de-jean-jacques-2.home> Hello Alissa & All, I support the draft as it now stands, in order to - warn against any initiative or mechanism which would endanger the Transition proposal before it has even been thoroughly vetted in Washington, - underline the risk of the ICANN Mission being susceptible to modification by external texts or undertakings, some of which are not yet in existence, - demand the withdrawal of Sections 1.1(d)(ii)(B)-(E), and the modification of Section 1.1(d)(ii)(F) so as to apply only to Section 1.1(d)(ii)(A). Best regards, Jean-Jacques. ----- Mail original ----- De: "Martin Boyle" À: "Alissa Cooper" , "Milton L Mueller" Cc: "Lynn St.Amour" , "IANA etc etcCoordination Group" Envoyé: Mercredi 4 Mai 2016 00:15:40 Objet: Re: [Internal-cg] bylaws feedback Hi Alissa, all, I agree with you, Alissa. This sort of detail does seem to me to go well beyond the remit of the ICG and we should certainly not be seeking to upset areas already agreed in the CCWG-Accountability process. For the rest of this, I am afraid I have not been following the CCWG process carefully enough to have a view of where the text bylaw drafting goes beyond the consensus of the proposal. I’ll try to look at it tomorrow, but on my cursory reading of the arguments below, this does look like a legitimate input from the ICG. Hope this helps Martin From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of Alissa Cooper Sent: 03 May 2016 22:10 To: Mueller, Milton L Cc: Lynn St.Amour ; IANA etc etcCoordination Group Subject: Re: [Internal-cg] bylaws feedback I don’t have an opinion about the substance of the RA/RAA renewals, but I don’t think they are within the scope of what the ICG should comment on. The renewal of RA and RAA agreements were discussed on today’s CCWG call (as well as on several previous CCWG calls and the CCWG mailing list). It appears that the CCWG will be commenting on these renewals in its own comments about the Bylaws, and will be supporting the existing language in (F) as it applies to the RA and RAA agreements. Considering that the CCWG appears to have discussed this topic at great length and has consensus on it, I don’t think the same argument we are making about (B)-(E) applies to the RA/RAA renewals. The CCWG is planning to submit its comments by May 10, so there should be more clarity about exactly what they intend to say soon. Alissa On May 3, 2016, at 9:59 AM, Mueller, Milton L < milton at gatech.edu > wrote: (F) applies the grandfathering to renewals of the agreements appearing in (B)-(D). MM: not correct: (F) applies the grandfathering to renewals of A – D. It reads: “(F) any renewals of agreements described in subsections (A)-(D) pursuant to their terms and conditions for renewal.” As I said in my initial comment, renewals of RA and RAA agreements are the most susceptible to bypassing mission limitations, because ICANN has the most expansive powers over names and the names community, unlike numbers and protocols, has not created a viable mechanism for changing the IFO. Picture this scenario: ICANN adds a highly regulatory requirement to the .com contract renewal; requiring it to pre-screen content in all .com second-level registrations. We might say, “this obviously violates the prohibition of content regulation in the mission statement,” but ICANN legal replies: “oh no, this is a renewal of the com agreement and therefore it is exempt from any such challenge.” If someone can show me that I am wrong legally about this possibility I’d be happy to drop it. But I haven’t seen any convincing arguments as to how this would not be possible. Therefore it would be extremely difficult for me to sign on to this statement if it does not mention the RA/RAA renewals problem and I frankly think we’d be missing the boat in a big way. --MM The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. Regards, Alissa Cooper on behalf of the ICG [1] http://mm.icann.org/pipermail/cwg-stewardship/2016-April/004877.html On Apr 30, 2016, at 8:16 AM, Mueller, Milton L < milton at gatech.edu > wrote: Ok, I have had time to read the transcript. I am even more strongly committed to developing a comment as ICG. Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that allows all of the work that was done to more precisely define the mission statement of ICANN in these bylaws ...to be completely contravened by whatever gets written into the ICANN PTI contract Because what this is says is that no one in the future will ever be able to challenge that contract on the basis that it contravenes the mission.” [and, I might add, the RZM contract, and renewals of registry contracts]. The only answer I saw to this was that we don’t need to worry about it because the PTI contract will be put up for public comment. Alissa also made the point: "this memo ... seems to imply that ... the most important thing out of all of this is that ICANN can continue to perform the IANA function. And I think what we all learned in (unintelligible) in terms of what the ICG proposal says is that in fact that is not the most important thing. The most important thing is that the IANA functions can continue to be performed by some operator who’s capable of performing them according to the service level agreements that the community ...has. And those two things are not the same. And I certainly –I will put my IETF hat on here for a second and say that I think from an IETF perspective the important thing is that a protocol parameters functions can continue to be performed, not that they can only continue to be performed by ICANN." I don't think this argument of Alissa was ever answered. It seems like there could be ways of drafting these sections that do not commit us to a specific contract but makes it clear that performance of the IANA functions is not challengable as a mission violation so long as the community actually wants ICANN to perform those functions. Indeed, I am having trouble understanding the threat that these sections are supposed to avoid. However, the most dangerous mission-limitation-busting potential is in the renewals section (F). This is problematic partly because the CCWG never agreed to exempt renewals. We agreed to grandfather existing agreements, for the sake of stability. But the assumption was that if anything in these existing agreements contravened the new mission limitations, that they COULD be challenged during a renewal process. A contract renewal with a registry could include all kinds of regulatory measures that exceed the mission, and if these measures are framed as a "renewal of an existing agreement" then ICANN could in principle get away with anything. So I hope we are able to make it clear to ICANN and the CCWG that these provisions need to be changed.. From: Alissa Cooper [ mailto:alissa at cooperw.in ] Sent: Friday, April 29, 2016 3:00 PM To: Mueller, Milton L < milton at gatech.edu > Cc: Lynn St.Amour < Lynn at LStAmour.org >; IANA etc etcCoordination Group < internal-cg at ianacg.org > Subject: Re: [Internal-cg] bylaws feedback For folks following this issue, it is definitely worth reading the transcript or listening to the recording of the last CCWG call: https://community.icann.org/pages/viewpage.action?pageId=58730392 The more that I have thought about this, it has become clear to me that the core issue here is that there is a portion of bylaws section 1.1(d) that is not called for either by our proposal or by the CCWG proposal, as Lynn says. Had the content of 1.1(d)(ii)(B-E) been discussed as part of the transition proposal development, I think the concerns being raised now would have been raised then, and the whole community would have had time to sort them out. (I note that there was an extended discussion about RA/RAA agreements in the CCWG and that did result in text in its proposal in paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not extend to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been created out of whole cloth by the bylaws drafting team, and that was not within their remit in my opinion. The Bylaws are just supposed to implement the proposals. I think there are substantive issues too, but from an ICG perspective we may or may not want to focus on those. I would support sending a comment. We sent a message early on during the bylaws drafting and received no response, and the call to discuss this didn’t even occur until after the bylaws were put out for public comment. Alissa On Apr 29, 2016, at 11:17 AM, Mueller, Milton L < milton at gatech.edu > wrote: I support what you are saying. I take it you are not satisfied with the lawyers' explanation? I was not able to attend the 0:400 call a few days ago so was not able to question them about it or hear their answers. --MM -----Original Message----- From: Lynn St.Amour [ mailto:Lynn at LStAmour.org ] Sent: Friday, April 29, 2016 1:55 PM To: Alissa Cooper < alissa at cooperw.in >; Mueller, Milton L < milton at gatech.edu >; IANA etc etcCoordination Group Subject: Re: [Internal-cg] bylaws feedback Hi Alissa, Milton, all, I would like to come back to this subject. Specifically, I would like to propose that the ICG send in a statement to the By-laws comment period. Alissa commented on a specific concern (see thread below) and I also believe the ICG should be concerned about the overreach in the draft bylaws. My main concerns are: - the fact that these draft by-laws, through the grand-fathering provisions, allow external agreements to define ICANN's Mission which seems like a bad idea for many reasons. Further, this contradicts the desires of the community (or is a run around the community - intentional or not) who worked hard to clarify and correctly state ICANN’s mission throughout the IANA Transition process (paragraphs 140-144 of the CCWG-Accountability proposal). - the ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community. And, it was to respect the roles and responsibilities of the OCs in defining their own transition plans. The ICG and the CCWG reports define those wishes, and any changes to the bylaws were to be to implement those wishes, nothing more. Yet provisions in sections 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- Accountability proposals, and so there has not been appropriate community involvement or review for those changes. Note: these sections affect much of the Internet community, as they apply to agreements between ICANN and the ASO, NRO, IETF, Root Zone Maintainer, and PTI. For transparency: the IAB/IETF are also concerned about the overreach and are drafting their own comments, and as an IAB appointee to the ICG, I am part of that review as well. If there is support for the ICG sending in a comment, I would be happy to work with Alissa and others to draft something for ICG review. Regards, Lynn On Apr 12, 2016, at 3:15 PM, Alissa Cooper < alissa at cooperw.in > wrote: >From the minutes it looks like this was discussed on the CCWG call and there will be follow-up. On Apr 12, 2016, at 8:39 AM, Mueller, Milton L < milton at gatech.edu > wrote: I sent it yesterday but there has been no response at all. -----Original Message----- From: Alissa Cooper [ mailto:alissa at cooperw.in ] Sent: Monday, April 11, 2016 4:54 PM To: Mueller, Milton L < milton at gatech.edu > Cc: IANA etc etcCoordination Group < internal-cg at ianacg.org > Subject: Re: [Internal-cg] bylaws feedback I think that would be fine. Thanks, Alissa On Apr 11, 2016, at 1:04 PM, Mueller, Milton L < milton at gatech.edu > wrote: Alissa If you don't mind I will just forward your message to the bylaws and CWG lists. If there is some other way you want me to do this, please let me know. --MM -----Original Message----- From: Internal-cg [ mailto:internal-cg-bounces at ianacg.org ] On Behalf Of Alissa Cooper Sent: Monday, April 11, 2016 1:49 PM To: IANA etc etcCoordination Group < internal-cg at ianacg.org > Subject: [Internal-cg] bylaws feedback I have looked a bit at the draft bylaws and I’d like to ask Kavouss and Milton to bring the following issue back to the bylaws drafting group: Section 1.1(d)(ii) incorporates by reference a number of documents external to the bylaws as a means to prevent challenges on the basis that those documents conflict with or violate the bylaws. In particular, bullet (D) applies this provision to "the IANA Naming Function Contract between ICANN and PTI effective [October 1, 2016]." Given the ICG's historical encouragement of the community to meet timelines necessary for a successful transition, I find this provision to be extremely problematic. It incorporates a reference to a document that does not exist yet and that is unlikely to be completed by the time the bylaws are supposed to be done (early June). In fact, it is not even clear at this point whether the new ICANN affiliate to be setup will be name "PTI" or have some other name. I don't understand how anyone can reason about whether 1.1(d)(ii) is an acceptable bylaws provision if it references a document that has not been written. (This also applies to (B) and (C) since it could apply to future documents that haven’t been written yet.) Furthermore, I question whether it is a sound decision to essentially allow for documents external to the bylaws to be able to modify the bylaws (under (F)). This section would make more sense if it was entirely internally specified, without the references to external documents. At a minimum, I think we should recommend that (D) be removed. Thanks, Alissa _______________________________________________ Internal-cg mailing list Internal-cg at mm.ianacg.org http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org _______________________________________________ Internal-cg mailing list Internal-cg at mm.ianacg.org http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org From manal at tra.gov.eg Wed May 4 08:15:37 2016 From: manal at tra.gov.eg (Manal Ismail) Date: Wed, 4 May 2016 08:15:37 +0000 Subject: [Internal-cg] bylaws feedback In-Reply-To: <7CCC84D4-1E20-41B8-8F41-4D06A9291F82@cooperw.in> References: <79AB2AAA-ECED-4A05-A437-16F100D664EE@cooperw.in> <6170505D-57EB-4017-A9B6-68D37E9EF4EF@cooperw.in> <5978117D-AD72-4C5B-80D2-24CAED51A922@LStAmour.org> <648952D9-5962-4E6D-8271-55AE178F9113@cooperw.in> <7CCC84D4-1E20-41B8-8F41-4D06A9291F82@cooperw.in> Message-ID: <190a26858d22499dad19166a986f4d7f@ntra-mbx2.TRA.GOV.EG> I haven't been following the CCWG discussions closely lately, so many thanks to all colleagues who brought up this point to attention, explained its impact and provided the necessary references .. Having read the thread of exchanges and having checked the sections referenced below, I see the points raised, support sending a letter and support the draft below .. Thanks again to all colleagues who are keeping an eye on the process and flagging to us the need to intervene .. Kind Regards --Manal From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of Alissa Cooper Sent: Tuesday, May 03, 2016 1:01 AM To: Mueller, Milton L Cc: Lynn St.Amour; IANA etc etcCoordination Group Subject: Re: [Internal-cg] bylaws feedback I’ve put together an initial draft comment below, using Lynn’s email as the base. Please send feedback/edits. I am a little leery of raising the issue Milton points out below about RA/RAA renewals, since that is more a question about what was discussed and agreed in the CCWG proposal and how paragraph 147 of the CCWG proposal is being interpreted, as compared to the other arguments which are about whole new provisions that were added without reference to any proposal text or community discussion. I tried to remain non-commital on this point in the text below. — The ICG appreciates the opportunity to comment on the draft ICANN Bylaws. The ICG previously communicated concerns about Section 1.1(d)(ii) to the Bylaws drafting group [1]. However, these concerns were not addressed in the draft Bylaws that were posted for public comment. Section 1.1(d) "grandfathers" a number of agreements into the Bylaws in order to prevent parties from challenging those agreements on the basis that they violate the ICANN Mission statement. Under Section 1.1(d)(ii), (A) applies to RA/RAA agreements; (B)-(D) apply to agreements between ICANN and the NRO, ASO, IETF, RZM, and PTI; and (E) applies to ICANN's Five-Year Strategic Plan and Five-Year Operating Plan. (F) applies the grandfathering to renewals of the agreements appearing in (B)-(D). The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. Regards, Alissa Cooper on behalf of the ICG [1] http://mm.icann.org/pipermail/cwg-stewardship/2016-April/004877.html On Apr 30, 2016, at 8:16 AM, Mueller, Milton L > wrote: Ok, I have had time to read the transcript. I am even more strongly committed to developing a comment as ICG. Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that allows all of the work that was done to more precisely define the mission statement of ICANN in these bylaws ...to be completely contravened by whatever gets written into the ICANN PTI contract Because what this is says is that no one in the future will ever be able to challenge that contract on the basis that it contravenes the mission.” [and, I might add, the RZM contract, and renewals of registry contracts]. The only answer I saw to this was that we don’t need to worry about it because the PTI contract will be put up for public comment. Alissa also made the point: "this memo ... seems to imply that ... the most important thing out of all of this is that ICANN can continue to perform the IANA function. And I think what we all learned in (unintelligible) in terms of what the ICG proposal says is that in fact that is not the most important thing. The most important thing is that the IANA functions can continue to be performed by some operator who’s capable of performing them according to the service level agreements that the community ...has. And those two things are not the same. And I certainly –I will put my IETF hat on here for a second and say that I think from an IETF perspective the important thing is that a protocol parameters functions can continue to be performed, not that they can only continue to be performed by ICANN." I don't think this argument of Alissa was ever answered. It seems like there could be ways of drafting these sections that do not commit us to a specific contract but makes it clear that performance of the IANA functions is not challengable as a mission violation so long as the community actually wants ICANN to perform those functions. Indeed, I am having trouble understanding the threat that these sections are supposed to avoid. However, the most dangerous mission-limitation-busting potential is in the renewals section (F). This is problematic partly because the CCWG never agreed to exempt renewals. We agreed to grandfather existing agreements, for the sake of stability. But the assumption was that if anything in these existing agreements contravened the new mission limitations, that they COULD be challenged during a renewal process. A contract renewal with a registry could include all kinds of regulatory measures that exceed the mission, and if these measures are framed as a "renewal of an existing agreement" then ICANN could in principle get away with anything. So I hope we are able to make it clear to ICANN and the CCWG that these provisions need to be changed.. From: Alissa Cooper [mailto:alissa at cooperw.in] Sent: Friday, April 29, 2016 3:00 PM To: Mueller, Milton L > Cc: Lynn St.Amour >; IANA etc etcCoordination Group > Subject: Re: [Internal-cg] bylaws feedback For folks following this issue, it is definitely worth reading the transcript or listening to the recording of the last CCWG call: https://community.icann.org/pages/viewpage.action?pageId=58730392 The more that I have thought about this, it has become clear to me that the core issue here is that there is a portion of bylaws section 1.1(d) that is not called for either by our proposal or by the CCWG proposal, as Lynn says. Had the content of 1.1(d)(ii)(B-E) been discussed as part of the transition proposal development, I think the concerns being raised now would have been raised then, and the whole community would have had time to sort them out. (I note that there was an extended discussion about RA/RAA agreements in the CCWG and that did result in text in its proposal in paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not extend to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been created out of whole cloth by the bylaws drafting team, and that was not within their remit in my opinion. The Bylaws are just supposed to implement the proposals. I think there are substantive issues too, but from an ICG perspective we may or may not want to focus on those. I would support sending a comment. We sent a message early on during the bylaws drafting and received no response, and the call to discuss this didn’t even occur until after the bylaws were put out for public comment. Alissa On Apr 29, 2016, at 11:17 AM, Mueller, Milton L > wrote: I support what you are saying. I take it you are not satisfied with the lawyers' explanation? I was not able to attend the 0:400 call a few days ago so was not able to question them about it or hear their answers. --MM -----Original Message----- From: Lynn St.Amour [mailto:Lynn at LStAmour.org] Sent: Friday, April 29, 2016 1:55 PM To: Alissa Cooper >; Mueller, Milton L >; IANA etc etcCoordination Group > Subject: Re: [Internal-cg] bylaws feedback Hi Alissa, Milton, all, I would like to come back to this subject. Specifically, I would like to propose that the ICG send in a statement to the By-laws comment period. Alissa commented on a specific concern (see thread below) and I also believe the ICG should be concerned about the overreach in the draft bylaws. My main concerns are: - the fact that these draft by-laws, through the grand-fathering provisions, allow external agreements to define ICANN's Mission which seems like a bad idea for many reasons. Further, this contradicts the desires of the community (or is a run around the community - intentional or not) who worked hard to clarify and correctly state ICANN’s mission throughout the IANA Transition process (paragraphs 140-144 of the CCWG-Accountability proposal). - the ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community. And, it was to respect the roles and responsibilities of the OCs in defining their own transition plans. The ICG and the CCWG reports define those wishes, and any changes to the bylaws were to be to implement those wishes, nothing more. Yet provisions in sections 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- Accountability proposals, and so there has not been appropriate community involvement or review for those changes. Note: these sections affect much of the Internet community, as they apply to agreements between ICANN and the ASO, NRO, IETF, Root Zone Maintainer, and PTI. For transparency: the IAB/IETF are also concerned about the overreach and are drafting their own comments, and as an IAB appointee to the ICG, I am part of that review as well. If there is support for the ICG sending in a comment, I would be happy to work with Alissa and others to draft something for ICG review. Regards, Lynn On Apr 12, 2016, at 3:15 PM, Alissa Cooper > wrote: From the minutes it looks like this was discussed on the CCWG call and there will be follow-up. On Apr 12, 2016, at 8:39 AM, Mueller, Milton L > wrote: I sent it yesterday but there has been no response at all. -----Original Message----- From: Alissa Cooper [mailto:alissa at cooperw.in] Sent: Monday, April 11, 2016 4:54 PM To: Mueller, Milton L > Cc: IANA etc etcCoordination Group > Subject: Re: [Internal-cg] bylaws feedback I think that would be fine. Thanks, Alissa On Apr 11, 2016, at 1:04 PM, Mueller, Milton L > wrote: Alissa If you don't mind I will just forward your message to the bylaws and CWG lists. If there is some other way you want me to do this, please let me know. --MM -----Original Message----- From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of Alissa Cooper Sent: Monday, April 11, 2016 1:49 PM To: IANA etc etcCoordination Group > Subject: [Internal-cg] bylaws feedback I have looked a bit at the draft bylaws and I’d like to ask Kavouss and Milton to bring the following issue back to the bylaws drafting group: Section 1.1(d)(ii) incorporates by reference a number of documents external to the bylaws as a means to prevent challenges on the basis that those documents conflict with or violate the bylaws. In particular, bullet (D) applies this provision to "the IANA Naming Function Contract between ICANN and PTI effective [October 1, 2016]." Given the ICG's historical encouragement of the community to meet timelines necessary for a successful transition, I find this provision to be extremely problematic. It incorporates a reference to a document that does not exist yet and that is unlikely to be completed by the time the bylaws are supposed to be done (early June). In fact, it is not even clear at this point whether the new ICANN affiliate to be setup will be name "PTI" or have some other name. I don't understand how anyone can reason about whether 1.1(d)(ii) is an acceptable bylaws provision if it references a document that has not been written. (This also applies to (B) and (C) since it could apply to future documents that haven’t been written yet.) Furthermore, I question whether it is a sound decision to essentially allow for documents external to the bylaws to be able to modify the bylaws (under (F)). This section would make more sense if it was entirely internally specified, without the references to external documents. At a minimum, I think we should recommend that (D) be removed. Thanks, Alissa _______________________________________________ Internal-cg mailing list Internal-cg at mm.ianacg.org http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrik at frobbit.se Wed May 4 16:18:55 2016 From: patrik at frobbit.se (Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=) Date: Wed, 04 May 2016 18:18:55 +0200 Subject: [Internal-cg] Fwd: IAB sent comments on ICANN draft bylaws References: <20160504160215.GE5297@iab.org> Message-ID: FYI! Forwarded message: > From: IAB Chair > To: ietf-announce at ietf.org, ietf at ietf.org > Cc: iab at iab.org > Subject: IAB sent comments on ICANN draft bylaws > Date: Wed, 4 May 2016 12:02:17 -0400 > > Dear colleagues, > > The IAB sent a response to ICANN in response to their call for > comments on their proposed new bylaws. The IAB announcement is at > https://www.iab.org/2016/05/04/iab-comments-on-draft-new-icann-bylaws/ > and you can see the posting in the ICANN forum at > http://forum.icann.org/lists/comments-draft-new-bylaws-21apr16/msg00001.html. > > Best regards, > > Andrew > (for the IAB) > > -- > IAB Chair (Andrew Sullivan) > iab-chair at iab.org > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From milton at gatech.edu Wed May 4 20:00:44 2016 From: milton at gatech.edu (Mueller, Milton L) Date: Wed, 4 May 2016 20:00:44 +0000 Subject: [Internal-cg] bylaws feedback In-Reply-To: <89F2259E-12EC-4990-987C-1193DD381938@cooperw.in> References: <79AB2AAA-ECED-4A05-A437-16F100D664EE@cooperw.in> <6170505D-57EB-4017-A9B6-68D37E9EF4EF@cooperw.in> <5978117D-AD72-4C5B-80D2-24CAED51A922@LStAmour.org> <648952D9-5962-4E6D-8271-55AE178F9113@cooperw.in> <7CCC84D4-1E20-41B8-8F41-4D06A9291F82@cooperw.in> <89F2259E-12EC-4990-987C-1193DD381938@cooperw.in> Message-ID: MM: As a minor matter, do you agree to correct the factual error I pointed out in your description? Grandfathering applies to (A)-(F) not to (B)-(F) as you say in the comment. That’s just a mistake, please agree to fix it. If your point is that ICG concerns only extend to (B)-(F) that is a separate point, and should not be mis-stated as it is now. I don’t have an opinion about the substance of the RA/RAA renewals, but I don’t think they are within the scope of what the ICG should comment on. MM: Yes, we know you don’t care about names. ;-) That’s fine, if there is a problem others will comment on it. But it appeared to be essentially the same issue as the one you were complaining about; putting something that is open-ended and yet to be seen beyond challenge. However, this may have been fixed, see below. The renewal of RA and RAA agreements were discussed on today’s CCWG call (as well as on several previous CCWG calls and the CCWG mailing list). It appears that the CCWG will be commenting on these renewals in its own comments about the Bylaws, and will be supporting the existing language in (F) as it applies to the RA and RAA agreements. MM: My understanding of what transpired on that call is that only the form contracts and existing contracts will be grandfathered, not any amendments that might be called renewals. If that is so, then my concerns are alleviated. Considering that the CCWG appears to have discussed this topic at great length and has consensus on it, MM: It is not clear there is CCWG consensus yet; while there may be legal team consensus don’t confuse the two. I don’t think the same argument we are making about (B)-(E) applies to the RA/RAA renewals. MM: It does in spades, if (A) is not worded properly, see above. I have trouble understanding how anyone could say this. The CCWG is planning to submit its comments by May 10, so there should be more clarity about exactly what they intend to say soon. Alissa On May 3, 2016, at 9:59 AM, Mueller, Milton L > wrote: (F) applies the grandfathering to renewals of the agreements appearing in (B)-(D). MM: not correct: (F) applies the grandfathering to renewals of A – D. It reads: “(F) any renewals of agreements described in subsections (A)-(D) pursuant to their terms and conditions for renewal.” As I said in my initial comment, renewals of RA and RAA agreements are the most susceptible to bypassing mission limitations, because ICANN has the most expansive powers over names and the names community, unlike numbers and protocols, has not created a viable mechanism for changing the IFO. Picture this scenario: ICANN adds a highly regulatory requirement to the .com contract renewal; requiring it to pre-screen content in all .com second-level registrations. We might say, “this obviously violates the prohibition of content regulation in the mission statement,” but ICANN legal replies: “oh no, this is a renewal of the com agreement and therefore it is exempt from any such challenge.” If someone can show me that I am wrong legally about this possibility I’d be happy to drop it. But I haven’t seen any convincing arguments as to how this would not be possible. Therefore it would be extremely difficult for me to sign on to this statement if it does not mention the RA/RAA renewals problem and I frankly think we’d be missing the boat in a big way. --MM The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. Regards, Alissa Cooper on behalf of the ICG [1] http://mm.icann.org/pipermail/cwg-stewardship/2016-April/004877.html On Apr 30, 2016, at 8:16 AM, Mueller, Milton L > wrote: Ok, I have had time to read the transcript. I am even more strongly committed to developing a comment as ICG. Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that allows all of the work that was done to more precisely define the mission statement of ICANN in these bylaws ...to be completely contravened by whatever gets written into the ICANN PTI contract Because what this is says is that no one in the future will ever be able to challenge that contract on the basis that it contravenes the mission.” [and, I might add, the RZM contract, and renewals of registry contracts]. The only answer I saw to this was that we don’t need to worry about it because the PTI contract will be put up for public comment. Alissa also made the point: "this memo ... seems to imply that ... the most important thing out of all of this is that ICANN can continue to perform the IANA function. And I think what we all learned in (unintelligible) in terms of what the ICG proposal says is that in fact that is not the most important thing. The most important thing is that the IANA functions can continue to be performed by some operator who’s capable of performing them according to the service level agreements that the community ...has. And those two things are not the same. And I certainly –I will put my IETF hat on here for a second and say that I think from an IETF perspective the important thing is that a protocol parameters functions can continue to be performed, not that they can only continue to be performed by ICANN." I don't think this argument of Alissa was ever answered. It seems like there could be ways of drafting these sections that do not commit us to a specific contract but makes it clear that performance of the IANA functions is not challengable as a mission violation so long as the community actually wants ICANN to perform those functions. Indeed, I am having trouble understanding the threat that these sections are supposed to avoid. However, the most dangerous mission-limitation-busting potential is in the renewals section (F). This is problematic partly because the CCWG never agreed to exempt renewals. We agreed to grandfather existing agreements, for the sake of stability. But the assumption was that if anything in these existing agreements contravened the new mission limitations, that they COULD be challenged during a renewal process. A contract renewal with a registry could include all kinds of regulatory measures that exceed the mission, and if these measures are framed as a "renewal of an existing agreement" then ICANN could in principle get away with anything. So I hope we are able to make it clear to ICANN and the CCWG that these provisions need to be changed.. From: Alissa Cooper [mailto:alissa at cooperw.in] Sent: Friday, April 29, 2016 3:00 PM To: Mueller, Milton L > Cc: Lynn St.Amour >; IANA etc etcCoordination Group > Subject: Re: [Internal-cg] bylaws feedback For folks following this issue, it is definitely worth reading the transcript or listening to the recording of the last CCWG call: https://community.icann.org/pages/viewpage.action?pageId=58730392 The more that I have thought about this, it has become clear to me that the core issue here is that there is a portion of bylaws section 1.1(d) that is not called for either by our proposal or by the CCWG proposal, as Lynn says. Had the content of 1.1(d)(ii)(B-E) been discussed as part of the transition proposal development, I think the concerns being raised now would have been raised then, and the whole community would have had time to sort them out. (I note that there was an extended discussion about RA/RAA agreements in the CCWG and that did result in text in its proposal in paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not extend to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been created out of whole cloth by the bylaws drafting team, and that was not within their remit in my opinion. The Bylaws are just supposed to implement the proposals. I think there are substantive issues too, but from an ICG perspective we may or may not want to focus on those. I would support sending a comment. We sent a message early on during the bylaws drafting and received no response, and the call to discuss this didn’t even occur until after the bylaws were put out for public comment. Alissa On Apr 29, 2016, at 11:17 AM, Mueller, Milton L > wrote: I support what you are saying. I take it you are not satisfied with the lawyers' explanation? I was not able to attend the 0:400 call a few days ago so was not able to question them about it or hear their answers. --MM -----Original Message----- From: Lynn St.Amour [mailto:Lynn at LStAmour.org] Sent: Friday, April 29, 2016 1:55 PM To: Alissa Cooper >; Mueller, Milton L >; IANA etc etcCoordination Group > Subject: Re: [Internal-cg] bylaws feedback Hi Alissa, Milton, all, I would like to come back to this subject. Specifically, I would like to propose that the ICG send in a statement to the By-laws comment period. Alissa commented on a specific concern (see thread below) and I also believe the ICG should be concerned about the overreach in the draft bylaws. My main concerns are: - the fact that these draft by-laws, through the grand-fathering provisions, allow external agreements to define ICANN's Mission which seems like a bad idea for many reasons. Further, this contradicts the desires of the community (or is a run around the community - intentional or not) who worked hard to clarify and correctly state ICANN’s mission throughout the IANA Transition process (paragraphs 140-144 of the CCWG-Accountability proposal). - the ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community. And, it was to respect the roles and responsibilities of the OCs in defining their own transition plans. The ICG and the CCWG reports define those wishes, and any changes to the bylaws were to be to implement those wishes, nothing more. Yet provisions in sections 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- Accountability proposals, and so there has not been appropriate community involvement or review for those changes. Note: these sections affect much of the Internet community, as they apply to agreements between ICANN and the ASO, NRO, IETF, Root Zone Maintainer, and PTI. For transparency: the IAB/IETF are also concerned about the overreach and are drafting their own comments, and as an IAB appointee to the ICG, I am part of that review as well. If there is support for the ICG sending in a comment, I would be happy to work with Alissa and others to draft something for ICG review. Regards, Lynn On Apr 12, 2016, at 3:15 PM, Alissa Cooper > wrote: From the minutes it looks like this was discussed on the CCWG call and there will be follow-up. On Apr 12, 2016, at 8:39 AM, Mueller, Milton L > wrote: I sent it yesterday but there has been no response at all. -----Original Message----- From: Alissa Cooper [mailto:alissa at cooperw.in] Sent: Monday, April 11, 2016 4:54 PM To: Mueller, Milton L > Cc: IANA etc etcCoordination Group > Subject: Re: [Internal-cg] bylaws feedback I think that would be fine. Thanks, Alissa On Apr 11, 2016, at 1:04 PM, Mueller, Milton L > wrote: Alissa If you don't mind I will just forward your message to the bylaws and CWG lists. If there is some other way you want me to do this, please let me know. --MM -----Original Message----- From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of Alissa Cooper Sent: Monday, April 11, 2016 1:49 PM To: IANA etc etcCoordination Group > Subject: [Internal-cg] bylaws feedback I have looked a bit at the draft bylaws and I’d like to ask Kavouss and Milton to bring the following issue back to the bylaws drafting group: Section 1.1(d)(ii) incorporates by reference a number of documents external to the bylaws as a means to prevent challenges on the basis that those documents conflict with or violate the bylaws. In particular, bullet (D) applies this provision to "the IANA Naming Function Contract between ICANN and PTI effective [October 1, 2016]." Given the ICG's historical encouragement of the community to meet timelines necessary for a successful transition, I find this provision to be extremely problematic. It incorporates a reference to a document that does not exist yet and that is unlikely to be completed by the time the bylaws are supposed to be done (early June). In fact, it is not even clear at this point whether the new ICANN affiliate to be setup will be name "PTI" or have some other name. I don't understand how anyone can reason about whether 1.1(d)(ii) is an acceptable bylaws provision if it references a document that has not been written. (This also applies to (B) and (C) since it could apply to future documents that haven’t been written yet.) Furthermore, I question whether it is a sound decision to essentially allow for documents external to the bylaws to be able to modify the bylaws (under (F)). This section would make more sense if it was entirely internally specified, without the references to external documents. At a minimum, I think we should recommend that (D) be removed. Thanks, Alissa _______________________________________________ Internal-cg mailing list Internal-cg at mm.ianacg.org http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From milton at gatech.edu Wed May 4 20:03:40 2016 From: milton at gatech.edu (Mueller, Milton L) Date: Wed, 4 May 2016 20:03:40 +0000 Subject: [Internal-cg] bylaws feedback In-Reply-To: <190a26858d22499dad19166a986f4d7f@ntra-mbx2.TRA.GOV.EG> References: <79AB2AAA-ECED-4A05-A437-16F100D664EE@cooperw.in> <6170505D-57EB-4017-A9B6-68D37E9EF4EF@cooperw.in> <5978117D-AD72-4C5B-80D2-24CAED51A922@LStAmour.org> <648952D9-5962-4E6D-8271-55AE178F9113@cooperw.in> <7CCC84D4-1E20-41B8-8F41-4D06A9291F82@cooperw.in> <190a26858d22499dad19166a986f4d7f@ntra-mbx2.TRA.GOV.EG> Message-ID: Excuse me, how can people support the draft without modification when it contains either a typo or an obvious error? To repeat: the current statement says: (F) applies the grandfathering to renewals of the agreements appearing in (B)-(D). This is not correct: (F) applies the grandfathering to renewals of the agreements appearing in _A_ – D. It reads: “(F) any renewals of agreements described in subsections (A)-(D) pursuant to their terms and conditions for renewal.” No room for debate about this, please just fix it. From: Manal Ismail [mailto:manal at tra.gov.eg] Sent: Wednesday, May 4, 2016 4:16 AM To: Alissa Cooper ; Mueller, Milton L Cc: Lynn St.Amour ; IANA etc etcCoordination Group Subject: RE: [Internal-cg] bylaws feedback I haven't been following the CCWG discussions closely lately, so many thanks to all colleagues who brought up this point to attention, explained its impact and provided the necessary references .. Having read the thread of exchanges and having checked the sections referenced below, I see the points raised, support sending a letter and support the draft below .. Thanks again to all colleagues who are keeping an eye on the process and flagging to us the need to intervene .. Kind Regards --Manal From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of Alissa Cooper Sent: Tuesday, May 03, 2016 1:01 AM To: Mueller, Milton L Cc: Lynn St.Amour; IANA etc etcCoordination Group Subject: Re: [Internal-cg] bylaws feedback I’ve put together an initial draft comment below, using Lynn’s email as the base. Please send feedback/edits. I am a little leery of raising the issue Milton points out below about RA/RAA renewals, since that is more a question about what was discussed and agreed in the CCWG proposal and how paragraph 147 of the CCWG proposal is being interpreted, as compared to the other arguments which are about whole new provisions that were added without reference to any proposal text or community discussion. I tried to remain non-commital on this point in the text below. — The ICG appreciates the opportunity to comment on the draft ICANN Bylaws. The ICG previously communicated concerns about Section 1.1(d)(ii) to the Bylaws drafting group [1]. However, these concerns were not addressed in the draft Bylaws that were posted for public comment. Section 1.1(d) "grandfathers" a number of agreements into the Bylaws in order to prevent parties from challenging those agreements on the basis that they violate the ICANN Mission statement. Under Section 1.1(d)(ii), (A) applies to RA/RAA agreements; (B)-(D) apply to agreements between ICANN and the NRO, ASO, IETF, RZM, and PTI; and (E) applies to ICANN's Five-Year Strategic Plan and Five-Year Operating Plan. (F) applies the grandfathering to renewals of the agreements appearing in (B)-(D). The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. Regards, Alissa Cooper on behalf of the ICG [1] http://mm.icann.org/pipermail/cwg-stewardship/2016-April/004877.html On Apr 30, 2016, at 8:16 AM, Mueller, Milton L > wrote: Ok, I have had time to read the transcript. I am even more strongly committed to developing a comment as ICG. Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that allows all of the work that was done to more precisely define the mission statement of ICANN in these bylaws ...to be completely contravened by whatever gets written into the ICANN PTI contract Because what this is says is that no one in the future will ever be able to challenge that contract on the basis that it contravenes the mission.” [and, I might add, the RZM contract, and renewals of registry contracts]. The only answer I saw to this was that we don’t need to worry about it because the PTI contract will be put up for public comment. Alissa also made the point: "this memo ... seems to imply that ... the most important thing out of all of this is that ICANN can continue to perform the IANA function. And I think what we all learned in (unintelligible) in terms of what the ICG proposal says is that in fact that is not the most important thing. The most important thing is that the IANA functions can continue to be performed by some operator who’s capable of performing them according to the service level agreements that the community ...has. And those two things are not the same. And I certainly –I will put my IETF hat on here for a second and say that I think from an IETF perspective the important thing is that a protocol parameters functions can continue to be performed, not that they can only continue to be performed by ICANN." I don't think this argument of Alissa was ever answered. It seems like there could be ways of drafting these sections that do not commit us to a specific contract but makes it clear that performance of the IANA functions is not challengable as a mission violation so long as the community actually wants ICANN to perform those functions. Indeed, I am having trouble understanding the threat that these sections are supposed to avoid. However, the most dangerous mission-limitation-busting potential is in the renewals section (F). This is problematic partly because the CCWG never agreed to exempt renewals. We agreed to grandfather existing agreements, for the sake of stability. But the assumption was that if anything in these existing agreements contravened the new mission limitations, that they COULD be challenged during a renewal process. A contract renewal with a registry could include all kinds of regulatory measures that exceed the mission, and if these measures are framed as a "renewal of an existing agreement" then ICANN could in principle get away with anything. So I hope we are able to make it clear to ICANN and the CCWG that these provisions need to be changed.. From: Alissa Cooper [mailto:alissa at cooperw.in] Sent: Friday, April 29, 2016 3:00 PM To: Mueller, Milton L > Cc: Lynn St.Amour >; IANA etc etcCoordination Group > Subject: Re: [Internal-cg] bylaws feedback For folks following this issue, it is definitely worth reading the transcript or listening to the recording of the last CCWG call: https://community.icann.org/pages/viewpage.action?pageId=58730392 The more that I have thought about this, it has become clear to me that the core issue here is that there is a portion of bylaws section 1.1(d) that is not called for either by our proposal or by the CCWG proposal, as Lynn says. Had the content of 1.1(d)(ii)(B-E) been discussed as part of the transition proposal development, I think the concerns being raised now would have been raised then, and the whole community would have had time to sort them out. (I note that there was an extended discussion about RA/RAA agreements in the CCWG and that did result in text in its proposal in paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not extend to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been created out of whole cloth by the bylaws drafting team, and that was not within their remit in my opinion. The Bylaws are just supposed to implement the proposals. I think there are substantive issues too, but from an ICG perspective we may or may not want to focus on those. I would support sending a comment. We sent a message early on during the bylaws drafting and received no response, and the call to discuss this didn’t even occur until after the bylaws were put out for public comment. Alissa On Apr 29, 2016, at 11:17 AM, Mueller, Milton L > wrote: I support what you are saying. I take it you are not satisfied with the lawyers' explanation? I was not able to attend the 0:400 call a few days ago so was not able to question them about it or hear their answers. --MM -----Original Message----- From: Lynn St.Amour [mailto:Lynn at LStAmour.org] Sent: Friday, April 29, 2016 1:55 PM To: Alissa Cooper >; Mueller, Milton L >; IANA etc etcCoordination Group > Subject: Re: [Internal-cg] bylaws feedback Hi Alissa, Milton, all, I would like to come back to this subject. Specifically, I would like to propose that the ICG send in a statement to the By-laws comment period. Alissa commented on a specific concern (see thread below) and I also believe the ICG should be concerned about the overreach in the draft bylaws. My main concerns are: - the fact that these draft by-laws, through the grand-fathering provisions, allow external agreements to define ICANN's Mission which seems like a bad idea for many reasons. Further, this contradicts the desires of the community (or is a run around the community - intentional or not) who worked hard to clarify and correctly state ICANN’s mission throughout the IANA Transition process (paragraphs 140-144 of the CCWG-Accountability proposal). - the ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community. And, it was to respect the roles and responsibilities of the OCs in defining their own transition plans. The ICG and the CCWG reports define those wishes, and any changes to the bylaws were to be to implement those wishes, nothing more. Yet provisions in sections 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- Accountability proposals, and so there has not been appropriate community involvement or review for those changes. Note: these sections affect much of the Internet community, as they apply to agreements between ICANN and the ASO, NRO, IETF, Root Zone Maintainer, and PTI. For transparency: the IAB/IETF are also concerned about the overreach and are drafting their own comments, and as an IAB appointee to the ICG, I am part of that review as well. If there is support for the ICG sending in a comment, I would be happy to work with Alissa and others to draft something for ICG review. Regards, Lynn On Apr 12, 2016, at 3:15 PM, Alissa Cooper > wrote: From the minutes it looks like this was discussed on the CCWG call and there will be follow-up. On Apr 12, 2016, at 8:39 AM, Mueller, Milton L > wrote: I sent it yesterday but there has been no response at all. -----Original Message----- From: Alissa Cooper [mailto:alissa at cooperw.in] Sent: Monday, April 11, 2016 4:54 PM To: Mueller, Milton L > Cc: IANA etc etcCoordination Group > Subject: Re: [Internal-cg] bylaws feedback I think that would be fine. Thanks, Alissa On Apr 11, 2016, at 1:04 PM, Mueller, Milton L > wrote: Alissa If you don't mind I will just forward your message to the bylaws and CWG lists. If there is some other way you want me to do this, please let me know. --MM -----Original Message----- From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of Alissa Cooper Sent: Monday, April 11, 2016 1:49 PM To: IANA etc etcCoordination Group > Subject: [Internal-cg] bylaws feedback I have looked a bit at the draft bylaws and I’d like to ask Kavouss and Milton to bring the following issue back to the bylaws drafting group: Section 1.1(d)(ii) incorporates by reference a number of documents external to the bylaws as a means to prevent challenges on the basis that those documents conflict with or violate the bylaws. In particular, bullet (D) applies this provision to "the IANA Naming Function Contract between ICANN and PTI effective [October 1, 2016]." Given the ICG's historical encouragement of the community to meet timelines necessary for a successful transition, I find this provision to be extremely problematic. It incorporates a reference to a document that does not exist yet and that is unlikely to be completed by the time the bylaws are supposed to be done (early June). In fact, it is not even clear at this point whether the new ICANN affiliate to be setup will be name "PTI" or have some other name. I don't understand how anyone can reason about whether 1.1(d)(ii) is an acceptable bylaws provision if it references a document that has not been written. (This also applies to (B) and (C) since it could apply to future documents that haven’t been written yet.) Furthermore, I question whether it is a sound decision to essentially allow for documents external to the bylaws to be able to modify the bylaws (under (F)). This section would make more sense if it was entirely internally specified, without the references to external documents. At a minimum, I think we should recommend that (D) be removed. Thanks, Alissa _______________________________________________ Internal-cg mailing list Internal-cg at mm.ianacg.org http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From alissa at cooperw.in Wed May 4 20:05:55 2016 From: alissa at cooperw.in (Alissa Cooper) Date: Wed, 4 May 2016 13:05:55 -0700 Subject: [Internal-cg] bylaws feedback In-Reply-To: References: <79AB2AAA-ECED-4A05-A437-16F100D664EE@cooperw.in> <6170505D-57EB-4017-A9B6-68D37E9EF4EF@cooperw.in> <5978117D-AD72-4C5B-80D2-24CAED51A922@LStAmour.org> <648952D9-5962-4E6D-8271-55AE178F9113@cooperw.in> <7CCC84D4-1E20-41B8-8F41-4D06A9291F82@cooperw.in> <89F2259E-12EC-4990-987C-1193DD381938@cooperw.in> Message-ID: <3573451D-30D1-4340-89A9-E6847ABE4272@cooperw.in> > On May 4, 2016, at 1:00 PM, Mueller, Milton L wrote: > > > MM: As a minor matter, do you agree to correct the factual error I pointed out in your description? Grandfathering applies to (A)-(F) not to (B)-(F) as you say in the comment. That’s just a mistake, please agree to fix it. Of course. -------------- next part -------------- An HTML attachment was scrubbed... URL: From manal at tra.gov.eg Thu May 5 07:19:35 2016 From: manal at tra.gov.eg (Manal Ismail) Date: Thu, 5 May 2016 07:19:35 +0000 Subject: [Internal-cg] bylaws feedback In-Reply-To: References: <79AB2AAA-ECED-4A05-A437-16F100D664EE@cooperw.in> <6170505D-57EB-4017-A9B6-68D37E9EF4EF@cooperw.in> <5978117D-AD72-4C5B-80D2-24CAED51A922@LStAmour.org> <648952D9-5962-4E6D-8271-55AE178F9113@cooperw.in> <7CCC84D4-1E20-41B8-8F41-4D06A9291F82@cooperw.in> <190a26858d22499dad19166a986f4d7f@ntra-mbx2.TRA.GOV.EG> Message-ID: <9644df5cfa7c4918a7ee1872f4e3f0de@ntra-mbx2.TRA.GOV.EG> Sorry Milton .. Didn't notice the typo .. Thanks for re-sending .. Of course I do support fixing it !! Kind Regards --Manal From: Mueller, Milton L [mailto:milton at gatech.edu] Sent: Wednesday, May 04, 2016 10:04 PM To: Manal Ismail; Alissa Cooper Cc: IANA etc etcCoordination Group Subject: RE: [Internal-cg] bylaws feedback Excuse me, how can people support the draft without modification when it contains either a typo or an obvious error? To repeat: the current statement says: (F) applies the grandfathering to renewals of the agreements appearing in (B)-(D). This is not correct: (F) applies the grandfathering to renewals of the agreements appearing in _A_ – D. It reads: “(F) any renewals of agreements described in subsections (A)-(D) pursuant to their terms and conditions for renewal.” No room for debate about this, please just fix it. From: Manal Ismail [mailto:manal at tra.gov.eg] Sent: Wednesday, May 4, 2016 4:16 AM To: Alissa Cooper >; Mueller, Milton L > Cc: Lynn St.Amour >; IANA etc etcCoordination Group > Subject: RE: [Internal-cg] bylaws feedback I haven't been following the CCWG discussions closely lately, so many thanks to all colleagues who brought up this point to attention, explained its impact and provided the necessary references .. Having read the thread of exchanges and having checked the sections referenced below, I see the points raised, support sending a letter and support the draft below .. Thanks again to all colleagues who are keeping an eye on the process and flagging to us the need to intervene .. Kind Regards --Manal From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of Alissa Cooper Sent: Tuesday, May 03, 2016 1:01 AM To: Mueller, Milton L Cc: Lynn St.Amour; IANA etc etcCoordination Group Subject: Re: [Internal-cg] bylaws feedback I’ve put together an initial draft comment below, using Lynn’s email as the base. Please send feedback/edits. I am a little leery of raising the issue Milton points out below about RA/RAA renewals, since that is more a question about what was discussed and agreed in the CCWG proposal and how paragraph 147 of the CCWG proposal is being interpreted, as compared to the other arguments which are about whole new provisions that were added without reference to any proposal text or community discussion. I tried to remain non-commital on this point in the text below. — The ICG appreciates the opportunity to comment on the draft ICANN Bylaws. The ICG previously communicated concerns about Section 1.1(d)(ii) to the Bylaws drafting group [1]. However, these concerns were not addressed in the draft Bylaws that were posted for public comment. Section 1.1(d) "grandfathers" a number of agreements into the Bylaws in order to prevent parties from challenging those agreements on the basis that they violate the ICANN Mission statement. Under Section 1.1(d)(ii), (A) applies to RA/RAA agreements; (B)-(D) apply to agreements between ICANN and the NRO, ASO, IETF, RZM, and PTI; and (E) applies to ICANN's Five-Year Strategic Plan and Five-Year Operating Plan. (F) applies the grandfathering to renewals of the agreements appearing in (B)-(D). The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. Regards, Alissa Cooper on behalf of the ICG [1] http://mm.icann.org/pipermail/cwg-stewardship/2016-April/004877.html On Apr 30, 2016, at 8:16 AM, Mueller, Milton L > wrote: Ok, I have had time to read the transcript. I am even more strongly committed to developing a comment as ICG. Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that allows all of the work that was done to more precisely define the mission statement of ICANN in these bylaws ...to be completely contravened by whatever gets written into the ICANN PTI contract Because what this is says is that no one in the future will ever be able to challenge that contract on the basis that it contravenes the mission.” [and, I might add, the RZM contract, and renewals of registry contracts]. The only answer I saw to this was that we don’t need to worry about it because the PTI contract will be put up for public comment. Alissa also made the point: "this memo ... seems to imply that ... the most important thing out of all of this is that ICANN can continue to perform the IANA function. And I think what we all learned in (unintelligible) in terms of what the ICG proposal says is that in fact that is not the most important thing. The most important thing is that the IANA functions can continue to be performed by some operator who’s capable of performing them according to the service level agreements that the community ...has. And those two things are not the same. And I certainly –I will put my IETF hat on here for a second and say that I think from an IETF perspective the important thing is that a protocol parameters functions can continue to be performed, not that they can only continue to be performed by ICANN." I don't think this argument of Alissa was ever answered. It seems like there could be ways of drafting these sections that do not commit us to a specific contract but makes it clear that performance of the IANA functions is not challengable as a mission violation so long as the community actually wants ICANN to perform those functions. Indeed, I am having trouble understanding the threat that these sections are supposed to avoid. However, the most dangerous mission-limitation-busting potential is in the renewals section (F). This is problematic partly because the CCWG never agreed to exempt renewals. We agreed to grandfather existing agreements, for the sake of stability. But the assumption was that if anything in these existing agreements contravened the new mission limitations, that they COULD be challenged during a renewal process. A contract renewal with a registry could include all kinds of regulatory measures that exceed the mission, and if these measures are framed as a "renewal of an existing agreement" then ICANN could in principle get away with anything. So I hope we are able to make it clear to ICANN and the CCWG that these provisions need to be changed.. From: Alissa Cooper [mailto:alissa at cooperw.in] Sent: Friday, April 29, 2016 3:00 PM To: Mueller, Milton L > Cc: Lynn St.Amour >; IANA etc etcCoordination Group > Subject: Re: [Internal-cg] bylaws feedback For folks following this issue, it is definitely worth reading the transcript or listening to the recording of the last CCWG call: https://community.icann.org/pages/viewpage.action?pageId=58730392 The more that I have thought about this, it has become clear to me that the core issue here is that there is a portion of bylaws section 1.1(d) that is not called for either by our proposal or by the CCWG proposal, as Lynn says. Had the content of 1.1(d)(ii)(B-E) been discussed as part of the transition proposal development, I think the concerns being raised now would have been raised then, and the whole community would have had time to sort them out. (I note that there was an extended discussion about RA/RAA agreements in the CCWG and that did result in text in its proposal in paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not extend to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been created out of whole cloth by the bylaws drafting team, and that was not within their remit in my opinion. The Bylaws are just supposed to implement the proposals. I think there are substantive issues too, but from an ICG perspective we may or may not want to focus on those. I would support sending a comment. We sent a message early on during the bylaws drafting and received no response, and the call to discuss this didn’t even occur until after the bylaws were put out for public comment. Alissa On Apr 29, 2016, at 11:17 AM, Mueller, Milton L > wrote: I support what you are saying. I take it you are not satisfied with the lawyers' explanation? I was not able to attend the 0:400 call a few days ago so was not able to question them about it or hear their answers. --MM -----Original Message----- From: Lynn St.Amour [mailto:Lynn at LStAmour.org] Sent: Friday, April 29, 2016 1:55 PM To: Alissa Cooper >; Mueller, Milton L >; IANA etc etcCoordination Group > Subject: Re: [Internal-cg] bylaws feedback Hi Alissa, Milton, all, I would like to come back to this subject. Specifically, I would like to propose that the ICG send in a statement to the By-laws comment period. Alissa commented on a specific concern (see thread below) and I also believe the ICG should be concerned about the overreach in the draft bylaws. My main concerns are: - the fact that these draft by-laws, through the grand-fathering provisions, allow external agreements to define ICANN's Mission which seems like a bad idea for many reasons. Further, this contradicts the desires of the community (or is a run around the community - intentional or not) who worked hard to clarify and correctly state ICANN’s mission throughout the IANA Transition process (paragraphs 140-144 of the CCWG-Accountability proposal). - the ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community. And, it was to respect the roles and responsibilities of the OCs in defining their own transition plans. The ICG and the CCWG reports define those wishes, and any changes to the bylaws were to be to implement those wishes, nothing more. Yet provisions in sections 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- Accountability proposals, and so there has not been appropriate community involvement or review for those changes. Note: these sections affect much of the Internet community, as they apply to agreements between ICANN and the ASO, NRO, IETF, Root Zone Maintainer, and PTI. For transparency: the IAB/IETF are also concerned about the overreach and are drafting their own comments, and as an IAB appointee to the ICG, I am part of that review as well. If there is support for the ICG sending in a comment, I would be happy to work with Alissa and others to draft something for ICG review. Regards, Lynn On Apr 12, 2016, at 3:15 PM, Alissa Cooper > wrote: From the minutes it looks like this was discussed on the CCWG call and there will be follow-up. On Apr 12, 2016, at 8:39 AM, Mueller, Milton L > wrote: I sent it yesterday but there has been no response at all. -----Original Message----- From: Alissa Cooper [mailto:alissa at cooperw.in] Sent: Monday, April 11, 2016 4:54 PM To: Mueller, Milton L > Cc: IANA etc etcCoordination Group > Subject: Re: [Internal-cg] bylaws feedback I think that would be fine. Thanks, Alissa On Apr 11, 2016, at 1:04 PM, Mueller, Milton L > wrote: Alissa If you don't mind I will just forward your message to the bylaws and CWG lists. If there is some other way you want me to do this, please let me know. --MM -----Original Message----- From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of Alissa Cooper Sent: Monday, April 11, 2016 1:49 PM To: IANA etc etcCoordination Group > Subject: [Internal-cg] bylaws feedback I have looked a bit at the draft bylaws and I’d like to ask Kavouss and Milton to bring the following issue back to the bylaws drafting group: Section 1.1(d)(ii) incorporates by reference a number of documents external to the bylaws as a means to prevent challenges on the basis that those documents conflict with or violate the bylaws. In particular, bullet (D) applies this provision to "the IANA Naming Function Contract between ICANN and PTI effective [October 1, 2016]." Given the ICG's historical encouragement of the community to meet timelines necessary for a successful transition, I find this provision to be extremely problematic. It incorporates a reference to a document that does not exist yet and that is unlikely to be completed by the time the bylaws are supposed to be done (early June). In fact, it is not even clear at this point whether the new ICANN affiliate to be setup will be name "PTI" or have some other name. I don't understand how anyone can reason about whether 1.1(d)(ii) is an acceptable bylaws provision if it references a document that has not been written. (This also applies to (B) and (C) since it could apply to future documents that haven’t been written yet.) Furthermore, I question whether it is a sound decision to essentially allow for documents external to the bylaws to be able to modify the bylaws (under (F)). This section would make more sense if it was entirely internally specified, without the references to external documents. At a minimum, I think we should recommend that (D) be removed. Thanks, Alissa _______________________________________________ Internal-cg mailing list Internal-cg at mm.ianacg.org http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From narelle.clark at accan.org.au Thu May 5 07:36:38 2016 From: narelle.clark at accan.org.au (Narelle Clark) Date: Thu, 5 May 2016 17:36:38 +1000 Subject: [Internal-cg] bylaws feedback In-Reply-To: <7CCC84D4-1E20-41B8-8F41-4D06A9291F82@cooperw.in> References: <79AB2AAA-ECED-4A05-A437-16F100D664EE@cooperw.in> <6170505D-57EB-4017-A9B6-68D37E9EF4EF@cooperw.in> <5978117D-AD72-4C5B-80D2-24CAED51A922@LStAmour.org> <648952D9-5962-4E6D-8271-55AE178F9113@cooperw.in> <7CCC84D4-1E20-41B8-8F41-4D06A9291F82@cooperw.in> Message-ID: <7146C0FDA8771A43BEB20E18700C2E4F0181AF71AF37@ACCAN01.accan.local> I am in strong support of this communication (with the corrections noted in subsequent emails). It is important that the transition not be muddied by broader agendas any more than it already has! Please get it out there. Narelle From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of Alissa Cooper Sent: Tuesday, 3 May 2016 9:01 AM To: Mueller, Milton L Cc: Lynn St.Amour; IANA etc etcCoordination Group Subject: Re: [Internal-cg] bylaws feedback I’ve put together an initial draft comment below, using Lynn’s email as the base. Please send feedback/edits. I am a little leery of raising the issue Milton points out below about RA/RAA renewals, since that is more a question about what was discussed and agreed in the CCWG proposal and how paragraph 147 of the CCWG proposal is being interpreted, as compared to the other arguments which are about whole new provisions that were added without reference to any proposal text or community discussion. I tried to remain non-commital on this point in the text below. — The ICG appreciates the opportunity to comment on the draft ICANN Bylaws. The ICG previously communicated concerns about Section 1.1(d)(ii) to the Bylaws drafting group [1]. However, these concerns were not addressed in the draft Bylaws that were posted for public comment. Section 1.1(d) "grandfathers" a number of agreements into the Bylaws in order to prevent parties from challenging those agreements on the basis that they violate the ICANN Mission statement. Under Section 1.1(d)(ii), (A) applies to RA/RAA agreements; (B)-(D) apply to agreements between ICANN and the NRO, ASO, IETF, RZM, and PTI; and (E) applies to ICANN's Five-Year Strategic Plan and Five-Year Operating Plan. (F) applies the grandfathering to renewals of the agreements appearing in (B)-(D). The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. Regards, Alissa Cooper on behalf of the ICG [1] http://mm.icann.org/pipermail/cwg-stewardship/2016-April/004877.html On Apr 30, 2016, at 8:16 AM, Mueller, Milton L > wrote: Ok, I have had time to read the transcript. I am even more strongly committed to developing a comment as ICG. Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that allows all of the work that was done to more precisely define the mission statement of ICANN in these bylaws ...to be completely contravened by whatever gets written into the ICANN PTI contract Because what this is says is that no one in the future will ever be able to challenge that contract on the basis that it contravenes the mission.” [and, I might add, the RZM contract, and renewals of registry contracts]. The only answer I saw to this was that we don’t need to worry about it because the PTI contract will be put up for public comment. Alissa also made the point: "this memo ... seems to imply that ... the most important thing out of all of this is that ICANN can continue to perform the IANA function. And I think what we all learned in (unintelligible) in terms of what the ICG proposal says is that in fact that is not the most important thing. The most important thing is that the IANA functions can continue to be performed by some operator who’s capable of performing them according to the service level agreements that the community ...has. And those two things are not the same. And I certainly –I will put my IETF hat on here for a second and say that I think from an IETF perspective the important thing is that a protocol parameters functions can continue to be performed, not that they can only continue to be performed by ICANN." I don't think this argument of Alissa was ever answered. It seems like there could be ways of drafting these sections that do not commit us to a specific contract but makes it clear that performance of the IANA functions is not challengable as a mission violation so long as the community actually wants ICANN to perform those functions. Indeed, I am having trouble understanding the threat that these sections are supposed to avoid. However, the most dangerous mission-limitation-busting potential is in the renewals section (F). This is problematic partly because the CCWG never agreed to exempt renewals. We agreed to grandfather existing agreements, for the sake of stability. But the assumption was that if anything in these existing agreements contravened the new mission limitations, that they COULD be challenged during a renewal process. A contract renewal with a registry could include all kinds of regulatory measures that exceed the mission, and if these measures are framed as a "renewal of an existing agreement" then ICANN could in principle get away with anything. So I hope we are able to make it clear to ICANN and the CCWG that these provisions need to be changed.. From: Alissa Cooper [mailto:alissa at cooperw.in] Sent: Friday, April 29, 2016 3:00 PM To: Mueller, Milton L > Cc: Lynn St.Amour >; IANA etc etcCoordination Group > Subject: Re: [Internal-cg] bylaws feedback For folks following this issue, it is definitely worth reading the transcript or listening to the recording of the last CCWG call: https://community.icann.org/pages/viewpage.action?pageId=58730392 The more that I have thought about this, it has become clear to me that the core issue here is that there is a portion of bylaws section 1.1(d) that is not called for either by our proposal or by the CCWG proposal, as Lynn says. Had the content of 1.1(d)(ii)(B-E) been discussed as part of the transition proposal development, I think the concerns being raised now would have been raised then, and the whole community would have had time to sort them out. (I note that there was an extended discussion about RA/RAA agreements in the CCWG and that did result in text in its proposal in paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not extend to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been created out of whole cloth by the bylaws drafting team, and that was not within their remit in my opinion. The Bylaws are just supposed to implement the proposals. I think there are substantive issues too, but from an ICG perspective we may or may not want to focus on those. I would support sending a comment. We sent a message early on during the bylaws drafting and received no response, and the call to discuss this didn’t even occur until after the bylaws were put out for public comment. Alissa On Apr 29, 2016, at 11:17 AM, Mueller, Milton L > wrote: I support what you are saying. I take it you are not satisfied with the lawyers' explanation? I was not able to attend the 0:400 call a few days ago so was not able to question them about it or hear their answers. --MM -----Original Message----- From: Lynn St.Amour [mailto:Lynn at LStAmour.org] Sent: Friday, April 29, 2016 1:55 PM To: Alissa Cooper >; Mueller, Milton L >; IANA etc etcCoordination Group > Subject: Re: [Internal-cg] bylaws feedback Hi Alissa, Milton, all, I would like to come back to this subject. Specifically, I would like to propose that the ICG send in a statement to the By-laws comment period. Alissa commented on a specific concern (see thread below) and I also believe the ICG should be concerned about the overreach in the draft bylaws. My main concerns are: - the fact that these draft by-laws, through the grand-fathering provisions, allow external agreements to define ICANN's Mission which seems like a bad idea for many reasons. Further, this contradicts the desires of the community (or is a run around the community - intentional or not) who worked hard to clarify and correctly state ICANN’s mission throughout the IANA Transition process (paragraphs 140-144 of the CCWG-Accountability proposal). - the ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community. And, it was to respect the roles and responsibilities of the OCs in defining their own transition plans. The ICG and the CCWG reports define those wishes, and any changes to the bylaws were to be to implement those wishes, nothing more. Yet provisions in sections 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- Accountability proposals, and so there has not been appropriate community involvement or review for those changes. Note: these sections affect much of the Internet community, as they apply to agreements between ICANN and the ASO, NRO, IETF, Root Zone Maintainer, and PTI. For transparency: the IAB/IETF are also concerned about the overreach and are drafting their own comments, and as an IAB appointee to the ICG, I am part of that review as well. If there is support for the ICG sending in a comment, I would be happy to work with Alissa and others to draft something for ICG review. Regards, Lynn On Apr 12, 2016, at 3:15 PM, Alissa Cooper > wrote: From the minutes it looks like this was discussed on the CCWG call and there will be follow-up. On Apr 12, 2016, at 8:39 AM, Mueller, Milton L > wrote: I sent it yesterday but there has been no response at all. -----Original Message----- From: Alissa Cooper [mailto:alissa at cooperw.in] Sent: Monday, April 11, 2016 4:54 PM To: Mueller, Milton L > Cc: IANA etc etcCoordination Group > Subject: Re: [Internal-cg] bylaws feedback I think that would be fine. Thanks, Alissa On Apr 11, 2016, at 1:04 PM, Mueller, Milton L > wrote: Alissa If you don't mind I will just forward your message to the bylaws and CWG lists. If there is some other way you want me to do this, please let me know. --MM -----Original Message----- From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of Alissa Cooper Sent: Monday, April 11, 2016 1:49 PM To: IANA etc etcCoordination Group > Subject: [Internal-cg] bylaws feedback I have looked a bit at the draft bylaws and I’d like to ask Kavouss and Milton to bring the following issue back to the bylaws drafting group: Section 1.1(d)(ii) incorporates by reference a number of documents external to the bylaws as a means to prevent challenges on the basis that those documents conflict with or violate the bylaws. In particular, bullet (D) applies this provision to "the IANA Naming Function Contract between ICANN and PTI effective [October 1, 2016]." Given the ICG's historical encouragement of the community to meet timelines necessary for a successful transition, I find this provision to be extremely problematic. It incorporates a reference to a document that does not exist yet and that is unlikely to be completed by the time the bylaws are supposed to be done (early June). In fact, it is not even clear at this point whether the new ICANN affiliate to be setup will be name "PTI" or have some other name. I don't understand how anyone can reason about whether 1.1(d)(ii) is an acceptable bylaws provision if it references a document that has not been written. (This also applies to (B) and (C) since it could apply to future documents that haven’t been written yet.) Furthermore, I question whether it is a sound decision to essentially allow for documents external to the bylaws to be able to modify the bylaws (under (F)). This section would make more sense if it was entirely internally specified, without the references to external documents. At a minimum, I think we should recommend that (D) be removed. Thanks, Alissa _______________________________________________ Internal-cg mailing list Internal-cg at mm.ianacg.org http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From narelle.clark at accan.org.au Thu May 5 07:43:37 2016 From: narelle.clark at accan.org.au (Narelle Clark) Date: Thu, 5 May 2016 17:43:37 +1000 Subject: [Internal-cg] bylaws feedback In-Reply-To: <142976331.139.1462343299764.JavaMail.jjs-mac-2@macbook-air-de-jean-jacques-2.home> References: <142976331.139.1462343299764.JavaMail.jjs-mac-2@macbook-air-de-jean-jacques-2.home> Message-ID: <7146C0FDA8771A43BEB20E18700C2E4F0181AF71AF3A@ACCAN01.accan.local> Jean-Jacques has the rationale exactly. +1 Narelle > -----Original Message----- > From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of > Subrenat, Jean-Jacques > Sent: Wednesday, 4 May 2016 4:28 PM > To: Martin Boyle > Cc: Lynn St.Amour; Milton L Mueller; IANA etc etcCoordination Group > Subject: Re: [Internal-cg] bylaws feedback > > Hello Alissa & All, > > I support the draft as it now stands, in order to > - warn against any initiative or mechanism which would endanger the > Transition proposal before it has even been thoroughly vetted in > Washington, > - underline the risk of the ICANN Mission being susceptible to modification > by external texts or undertakings, some of which are not yet in existence, > - demand the withdrawal of Sections 1.1(d)(ii)(B)-(E), and the modification > of Section 1.1(d)(ii)(F) so as to apply only to Section 1.1(d)(ii)(A). > > Best regards, > Jean-Jacques. > > > > > ----- Mail original ----- > De: "Martin Boyle" > À: "Alissa Cooper" , "Milton L Mueller" > > Cc: "Lynn St.Amour" , "IANA etc etcCoordination > Group" > Envoyé: Mercredi 4 Mai 2016 00:15:40 > Objet: Re: [Internal-cg] bylaws feedback > > > > > > Hi Alissa, all, > > > > I agree with you, Alissa. This sort of detail does seem to me to go well > beyond the remit of the ICG and we should certainly not be seeking to > upset areas already agreed in the CCWG-Accountability process. > > > > For the rest of this, I am afraid I have not been following the CCWG process > carefully enough to have a view of where the text bylaw drafting goes > beyond the consensus of the proposal. I’ll try to look at it tomorrow, but on > my cursory reading of the arguments below, this does look like a legitimate > input from the ICG. > > > > Hope this helps > > > > Martin > > > > > > From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of > Alissa Cooper > Sent: 03 May 2016 22:10 > To: Mueller, Milton L > Cc: Lynn St.Amour ; IANA etc etcCoordination Group > > Subject: Re: [Internal-cg] bylaws feedback > > > > > I don’t have an opinion about the substance of the RA/RAA renewals, but I > don’t think they are within the scope of what the ICG should comment on. > > > > > > The renewal of RA and RAA agreements were discussed on today’s CCWG > call (as well as on several previous CCWG calls and the CCWG mailing list). It > appears that the CCWG will be commenting on these renewals in its own > comments about the Bylaws, and will be supporting the existing language in > (F) as it applies to the RA and RAA agreements. Considering that the CCWG > appears to have discussed this topic at great length and has consensus on > it, I don’t think the same argument we are making about (B)-(E) applies to > the RA/RAA renewals. > > > > > > The CCWG is planning to submit its comments by May 10, so there should > be more clarity about exactly what they intend to say soon. > > > > > > Alissa > > > > > > > > > > > On May 3, 2016, at 9:59 AM, Mueller, Milton L < milton at gatech.edu > > wrote: > > > > > > (F) applies the grandfathering to renewals of the agreements appearing in > (B)-(D). > > > > > > MM: not correct: (F) applies the grandfathering to renewals of A – D. It > reads: > > > > > > “(F) any renewals of agreements described in subsections (A)-(D) pursuant > to their terms and conditions for renewal.” > > > > > > As I said in my initial comment, renewals of RA and RAA agreements are the > most susceptible to bypassing mission limitations, because ICANN has the > most expansive powers over names and the names community, unlike > numbers and protocols, has not created a viable mechanism for changing > the IFO. > > > > > > Picture this scenario: ICANN adds a highly regulatory requirement to the > .com contract renewal; requiring it to pre-screen content in all .com second- > level registrations. We might say, “this obviously violates the prohibition of > content regulation in the mission statement,” but ICANN legal replies: “oh > no, this is a renewal of the com agreement and therefore it is exempt from > any such challenge.” > > > > > > If someone can show me that I am wrong legally about this possibility I’d be > happy to drop it. But I haven’t seen any convincing arguments as to how > this would not be possible. > > > > > > Therefore it would be extremely difficult for me to sign on to this statement > if it does not mention the RA/RAA renewals problem and I frankly think > we’d be missing the boat in a big way. > > > > > > --MM > > > > > > > > The ICG process was fashioned to ensure that the transition plans reflected > the consensus of the Internet community and allowed the operational > communities to define their own transition plans. The ICG and the CCWG > proposals define those wishes, and any changes to the Bylaws were to be to > implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are > outside the scope of both the ICG and the CCWG proposals. Unlike Section > 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is > documented in paragraph 147 of the CCWG proposal, the substance of (B)- > (E) have not enjoyed appropriate community involvement or review. These > sections affect much of the Internet community since they apply to > agreements with a variety of external parties, including all of the > operational communities. > > > > > > > > Because several of the referenced agreements have not yet been written > and most have not yet been agreed to by the relevant parties, the draft > Bylaws essentially allow these external agreements to define ICANN's > Mission. This seems like a bad idea for many reasons, not the least of which > is that it creates the possibility for the agreements to contradict or > circumvent the desires of the community who worked hard to clarify and > correctly state ICANN’s Mission throughout the IANA stewardship > transition process (see paragraphs 140-147 of the CCWG proposal). > > > > > > > > The ICG believes that in order for the Bylaws to be considered consistent > with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and > Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). > This assumes that (F) is indeed called for by paragraph 147 of the CCWG > proposal, which we leave for the CCWG to judge. > > > > > > > > Regards, > > > > > > > > Alissa Cooper on behalf of the ICG > > > > > > > > > > > > [1] http://mm.icann.org/pipermail/cwg-stewardship/2016- > April/004877.html > > > > > > > > > > > > > > On Apr 30, 2016, at 8:16 AM, Mueller, Milton L < milton at gatech.edu > > wrote: > > > > > > > > Ok, I have had time to read the transcript. I am even more strongly > committed to developing a comment as ICG. > > > > > > > > Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that allows all > of the work that was done to more precisely define the mission statement > of ICANN in these bylaws ...to be completely contravened by whatever gets > written into the ICANN PTI contract Because what this is says is that no one > in the future will ever be able to challenge that contract on the basis that it > contravenes the mission.” > > > > > > > > [and, I might add, the RZM contract, and renewals of registry contracts]. > > > > > > > > The only answer I saw to this was that we don’t need to worry about it > because the PTI contract will be put up for public comment. > > > > > > > > Alissa also made the point: > > > > "this memo ... seems to imply that ... the most important thing out of all of > this is that ICANN can continue to perform the IANA function. And I think > what we all learned in (unintelligible) in terms of what the ICG proposal says > is that in fact that is not the most important thing. The most important > thing is that the IANA functions can continue to be performed by some > operator who’s capable of performing them according to the service level > agreements that the community ...has. And those two things are not the > same. And I certainly –I will put my IETF hat on here for a second and say > that I think from an IETF perspective the important thing is that a protocol > parameters functions can continue to be performed, not that they can only > continue to be performed by ICANN." > > > > > > > > I don't think this argument of Alissa was ever answered. It seems like there > could be ways of drafting these sections that do not commit us to a specific > contract but makes it clear that performance of the IANA functions is not > challengable as a mission violation so long as the community actually wants > ICANN to perform those functions. > > > > > > > > Indeed, I am having trouble understanding the threat that these sections > are supposed to avoid. > > > > > > > > However, the most dangerous mission-limitation-busting potential is in the > renewals section (F). This is problematic partly because the CCWG never > agreed to exempt renewals. We agreed to grandfather existing agreements, > for the sake of stability. But the assumption was that if anything in these > existing agreements contravened the new mission limitations, that they > COULD be challenged during a renewal process. A contract renewal with a > registry could include all kinds of regulatory measures that exceed the > mission, and if these measures are framed as a "renewal of an existing > agreement" then ICANN could in principle get away with anything. > > > > > > > > So I hope we are able to make it clear to ICANN and the CCWG that these > provisions need to be changed.. > > > > > > > > > > > > > > > From: Alissa Cooper [ mailto:alissa at cooperw.in ] > Sent: Friday, April 29, 2016 3:00 PM > To: Mueller, Milton L < milton at gatech.edu > > Cc: Lynn St.Amour < Lynn at LStAmour.org >; IANA etc etcCoordination > Group < internal-cg at ianacg.org > > Subject: Re: [Internal-cg] bylaws feedback > > > > > > > > > For folks following this issue, it is definitely worth reading the transcript or > listening to the recording of the last CCWG call: > https://community.icann.org/pages/viewpage.action?pageId=58730392 > > > > > > > > > > The more that I have thought about this, it has become clear to me that the > core issue here is that there is a portion of bylaws section 1.1(d) that is not > called for either by our proposal or by the CCWG proposal, as Lynn says. > Had the content of 1.1(d)(ii)(B-E) been discussed as part of the transition > proposal development, I think the concerns being raised now would have > been raised then, and the whole community would have had time to sort > them out. (I note that there was an extended discussion about RA/RAA > agreements in the CCWG and that did result in text in its proposal in > paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not extend > to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been created > out of whole cloth by the bylaws drafting team, and that was not within > their remit in my opinion. The Bylaws are just supposed to implement the > proposals. > > > > > > > > > > I think there are substantive issues too, but from an ICG perspective we > may or may not want to focus on those. > > > > > > > > > > I would support sending a comment. We sent a message early on during the > bylaws drafting and received no response, and the call to discuss this didn’t > even occur until after the bylaws were put out for public comment. > > > > > > > > > > Alissa > > > > > > > > > > > > > > > > > On Apr 29, 2016, at 11:17 AM, Mueller, Milton L < milton at gatech.edu > > wrote: > > > > > > > > > > I support what you are saying. I take it you are not satisfied with the > lawyers' explanation? I was not able to attend the 0:400 call a few days ago > so was not able to question them about it or hear their answers. > > --MM > > > > > > > > > > > -----Original Message----- > From: Lynn St.Amour [ mailto:Lynn at LStAmour.org ] > Sent: Friday, April 29, 2016 1:55 PM > To: Alissa Cooper < alissa at cooperw.in >; Mueller, Milton L < > milton at gatech.edu >; IANA etc etcCoordination Group cg at ianacg.org > > Subject: Re: [Internal-cg] bylaws feedback > > Hi Alissa, Milton, all, > > I would like to come back to this subject. Specifically, I would like to > propose that the ICG send in a statement to the By-laws comment period. > > Alissa commented on a specific concern (see thread below) and I also > believe the ICG should be concerned about the overreach in the draft > bylaws. > > My main concerns are: > > - the fact that these draft by-laws, through the grand-fathering provisions, > allow external agreements to define ICANN's Mission which seems like a > bad idea for many reasons. Further, this contradicts the desires of the > community (or is a run around the community - intentional or not) who > worked hard to clarify and correctly state ICANN’s mission throughout the > IANA Transition process (paragraphs 140-144 of the CCWG-Accountability > proposal). > > - the ICG process was fashioned to ensure that the transition plans reflected > the consensus of the Internet community. And, it was to respect the roles > and responsibilities of the OCs in defining their own transition plans. The > ICG and the CCWG reports define those wishes, and any changes to the > bylaws were to be to implement those wishes, nothing more. Yet provisions > in sections > 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- > Accountability proposals, and so there has not been appropriate > community involvement or review for those changes. Note: these sections > affect much of the Internet community, as they apply to agreements > between ICANN and the ASO, NRO, IETF, Root Zone Maintainer, and PTI. > > For transparency: the IAB/IETF are also concerned about the overreach and > are drafting their own comments, and as an IAB appointee to the ICG, I am > part of that review as well. > > If there is support for the ICG sending in a comment, I would be happy to > work with Alissa and others to draft something for ICG review. > > Regards, > Lynn > > > > > > > > > > > > On Apr 12, 2016, at 3:15 PM, Alissa Cooper < alissa at cooperw.in > wrote: > > From the minutes it looks like this was discussed on the CCWG call and > there > > > > will be follow-up. > > > > > > > > > > > > > > > > > > > > On Apr 12, 2016, at 8:39 AM, Mueller, Milton L < milton at gatech.edu > > > > > wrote: > > > > > > > > > > > > > I sent it yesterday but there has been no response at all. > > > > > > > > > > > > -----Original Message----- > From: Alissa Cooper [ mailto:alissa at cooperw.in ] > Sent: Monday, April 11, 2016 4:54 PM > To: Mueller, Milton L < milton at gatech.edu > > Cc: IANA etc etcCoordination Group < internal-cg at ianacg.org > > Subject: Re: [Internal-cg] bylaws feedback > > I think that would be fine. > > Thanks, > Alissa > > > > > > > > > > > On Apr 11, 2016, at 1:04 PM, Mueller, Milton L < milton at gatech.edu > > > > > wrote: > > > > > > > > > > > Alissa > If you don't mind I will just forward your message to the bylaws > and CWG > > > > lists. > > > > > > > > > > If there is some other way you want me to do this, please let me know. > > --MM > > > > > > > > > > > -----Original Message----- > From: Internal-cg [ mailto:internal-cg-bounces at ianacg.org ] On > Behalf Of Alissa Cooper > Sent: Monday, April 11, 2016 1:49 PM > To: IANA etc etcCoordination Group < internal-cg at ianacg.org > > Subject: [Internal-cg] bylaws feedback > > I have looked a bit at the draft bylaws and I’d like to ask > Kavouss and Milton to bring the following issue back to the bylaws > > > > drafting group: > > > > > > > > > > > > > > > > > > > Section 1.1(d)(ii) incorporates by reference a number of documents > external to the bylaws as a means to prevent challenges on the > basis that those documents conflict with or violate the bylaws. In > particular, bullet (D) applies this provision to "the IANA Naming > Function Contract between ICANN and PTI effective [October 1, 2016]." > > Given the ICG's historical encouragement of the community to meet > timelines necessary for a successful transition, I find this > provision to be extremely problematic. It incorporates a reference > to a document that does not exist yet and that is unlikely to be > completed by the time the bylaws are supposed to be done (early > June). In fact, it is not even clear at this point whether the new > ICANN affiliate to be setup will be name "PTI" or have some other > name. I don't understand how anyone can reason about whether > 1.1(d)(ii) is an acceptable bylaws provision if it references a > document that has not been written. (This also applies to (B) and > (C) since it could apply to future documents that haven’t been > written > yet.) > > Furthermore, I question whether it is a sound decision to > essentially allow for documents external to the bylaws to be able > to modify the bylaws (under (F)). This section would make more > sense if it was entirely internally specified, without the > references to external documents. At a minimum, I think we should > recommend that (D) be > > > > removed. > > > > > > > > > > > > > Thanks, > Alissa > _______________________________________________ > Internal-cg mailing list > Internal-cg at mm.ianacg.org > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org > > > _______________________________________________ > Internal-cg mailing list > Internal-cg at mm.ianacg.org > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org > > _______________________________________________ > Internal-cg mailing list > Internal-cg at mm.ianacg.org > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org From mundy at tislabs.com Thu May 5 20:45:09 2016 From: mundy at tislabs.com (Russ Mundy) Date: Thu, 5 May 2016 16:45:09 -0400 Subject: [Internal-cg] bylaws feedback In-Reply-To: <7146C0FDA8771A43BEB20E18700C2E4F0181AF71AF3A@ACCAN01.accan.local> References: <142976331.139.1462343299764.JavaMail.jjs-mac-2@macbook-air-de-jean-jacques-2.home> <7146C0FDA8771A43BEB20E18700C2E4F0181AF71AF3A@ACCAN01.accan.local> Message-ID: I’m a bit slow on responding to the thread but I fully support it. RussM On May 5, 2016, at 3:43 AM, Narelle Clark wrote: > Jean-Jacques has the rationale exactly. > > +1 > > Narelle > > >> -----Original Message----- >> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of >> Subrenat, Jean-Jacques >> Sent: Wednesday, 4 May 2016 4:28 PM >> To: Martin Boyle >> Cc: Lynn St.Amour; Milton L Mueller; IANA etc etcCoordination Group >> Subject: Re: [Internal-cg] bylaws feedback >> >> Hello Alissa & All, >> >> I support the draft as it now stands, in order to >> - warn against any initiative or mechanism which would endanger the >> Transition proposal before it has even been thoroughly vetted in >> Washington, >> - underline the risk of the ICANN Mission being susceptible to modification >> by external texts or undertakings, some of which are not yet in existence, >> - demand the withdrawal of Sections 1.1(d)(ii)(B)-(E), and the modification >> of Section 1.1(d)(ii)(F) so as to apply only to Section 1.1(d)(ii)(A). >> >> Best regards, >> Jean-Jacques. >> >> >> >> >> ----- Mail original ----- >> De: "Martin Boyle" >> À: "Alissa Cooper" , "Milton L Mueller" >> >> Cc: "Lynn St.Amour" , "IANA etc etcCoordination >> Group" >> Envoyé: Mercredi 4 Mai 2016 00:15:40 >> Objet: Re: [Internal-cg] bylaws feedback >> >> >> >> >> >> Hi Alissa, all, >> >> >> >> I agree with you, Alissa. This sort of detail does seem to me to go well >> beyond the remit of the ICG and we should certainly not be seeking to >> upset areas already agreed in the CCWG-Accountability process. >> >> >> >> For the rest of this, I am afraid I have not been following the CCWG process >> carefully enough to have a view of where the text bylaw drafting goes >> beyond the consensus of the proposal. I’ll try to look at it tomorrow, but on >> my cursory reading of the arguments below, this does look like a legitimate >> input from the ICG. >> >> >> >> Hope this helps >> >> >> >> Martin >> >> >> >> >> >> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of >> Alissa Cooper >> Sent: 03 May 2016 22:10 >> To: Mueller, Milton L >> Cc: Lynn St.Amour ; IANA etc etcCoordination Group >> >> Subject: Re: [Internal-cg] bylaws feedback >> >> >> >> >> I don’t have an opinion about the substance of the RA/RAA renewals, but I >> don’t think they are within the scope of what the ICG should comment on. >> >> >> >> >> >> The renewal of RA and RAA agreements were discussed on today’s CCWG >> call (as well as on several previous CCWG calls and the CCWG mailing list). It >> appears that the CCWG will be commenting on these renewals in its own >> comments about the Bylaws, and will be supporting the existing language in >> (F) as it applies to the RA and RAA agreements. Considering that the CCWG >> appears to have discussed this topic at great length and has consensus on >> it, I don’t think the same argument we are making about (B)-(E) applies to >> the RA/RAA renewals. >> >> >> >> >> >> The CCWG is planning to submit its comments by May 10, so there should >> be more clarity about exactly what they intend to say soon. >> >> >> >> >> >> Alissa >> >> >> >> >> >> >> >> >> >> >> On May 3, 2016, at 9:59 AM, Mueller, Milton L < milton at gatech.edu > >> wrote: >> >> >> >> >> >> (F) applies the grandfathering to renewals of the agreements appearing in >> (B)-(D). >> >> >> >> >> >> MM: not correct: (F) applies the grandfathering to renewals of A – D. It >> reads: >> >> >> >> >> >> “(F) any renewals of agreements described in subsections (A)-(D) pursuant >> to their terms and conditions for renewal.” >> >> >> >> >> >> As I said in my initial comment, renewals of RA and RAA agreements are the >> most susceptible to bypassing mission limitations, because ICANN has the >> most expansive powers over names and the names community, unlike >> numbers and protocols, has not created a viable mechanism for changing >> the IFO. >> >> >> >> >> >> Picture this scenario: ICANN adds a highly regulatory requirement to the >> .com contract renewal; requiring it to pre-screen content in all .com second- >> level registrations. We might say, “this obviously violates the prohibition of >> content regulation in the mission statement,” but ICANN legal replies: “oh >> no, this is a renewal of the com agreement and therefore it is exempt from >> any such challenge.” >> >> >> >> >> >> If someone can show me that I am wrong legally about this possibility I’d be >> happy to drop it. But I haven’t seen any convincing arguments as to how >> this would not be possible. >> >> >> >> >> >> Therefore it would be extremely difficult for me to sign on to this statement >> if it does not mention the RA/RAA renewals problem and I frankly think >> we’d be missing the boat in a big way. >> >> >> >> >> >> --MM >> >> >> >> >> >> >> >> The ICG process was fashioned to ensure that the transition plans reflected >> the consensus of the Internet community and allowed the operational >> communities to define their own transition plans. The ICG and the CCWG >> proposals define those wishes, and any changes to the Bylaws were to be to >> implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are >> outside the scope of both the ICG and the CCWG proposals. Unlike Section >> 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is >> documented in paragraph 147 of the CCWG proposal, the substance of (B)- >> (E) have not enjoyed appropriate community involvement or review. These >> sections affect much of the Internet community since they apply to >> agreements with a variety of external parties, including all of the >> operational communities. >> >> >> >> >> >> >> >> Because several of the referenced agreements have not yet been written >> and most have not yet been agreed to by the relevant parties, the draft >> Bylaws essentially allow these external agreements to define ICANN's >> Mission. This seems like a bad idea for many reasons, not the least of which >> is that it creates the possibility for the agreements to contradict or >> circumvent the desires of the community who worked hard to clarify and >> correctly state ICANN’s Mission throughout the IANA stewardship >> transition process (see paragraphs 140-147 of the CCWG proposal). >> >> >> >> >> >> >> >> The ICG believes that in order for the Bylaws to be considered consistent >> with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and >> Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). >> This assumes that (F) is indeed called for by paragraph 147 of the CCWG >> proposal, which we leave for the CCWG to judge. >> >> >> >> >> >> >> >> Regards, >> >> >> >> >> >> >> >> Alissa Cooper on behalf of the ICG >> >> >> >> >> >> >> >> >> >> >> >> [1] http://mm.icann.org/pipermail/cwg-stewardship/2016- >> April/004877.html >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Apr 30, 2016, at 8:16 AM, Mueller, Milton L < milton at gatech.edu > >> wrote: >> >> >> >> >> >> >> >> Ok, I have had time to read the transcript. I am even more strongly >> committed to developing a comment as ICG. >> >> >> >> >> >> >> >> Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that allows all >> of the work that was done to more precisely define the mission statement >> of ICANN in these bylaws ...to be completely contravened by whatever gets >> written into the ICANN PTI contract Because what this is says is that no one >> in the future will ever be able to challenge that contract on the basis that it >> contravenes the mission.” >> >> >> >> >> >> >> >> [and, I might add, the RZM contract, and renewals of registry contracts]. >> >> >> >> >> >> >> >> The only answer I saw to this was that we don’t need to worry about it >> because the PTI contract will be put up for public comment. >> >> >> >> >> >> >> >> Alissa also made the point: >> >> >> >> "this memo ... seems to imply that ... the most important thing out of all of >> this is that ICANN can continue to perform the IANA function. And I think >> what we all learned in (unintelligible) in terms of what the ICG proposal says >> is that in fact that is not the most important thing. The most important >> thing is that the IANA functions can continue to be performed by some >> operator who’s capable of performing them according to the service level >> agreements that the community ...has. And those two things are not the >> same. And I certainly –I will put my IETF hat on here for a second and say >> that I think from an IETF perspective the important thing is that a protocol >> parameters functions can continue to be performed, not that they can only >> continue to be performed by ICANN." >> >> >> >> >> >> >> >> I don't think this argument of Alissa was ever answered. It seems like there >> could be ways of drafting these sections that do not commit us to a specific >> contract but makes it clear that performance of the IANA functions is not >> challengable as a mission violation so long as the community actually wants >> ICANN to perform those functions. >> >> >> >> >> >> >> >> Indeed, I am having trouble understanding the threat that these sections >> are supposed to avoid. >> >> >> >> >> >> >> >> However, the most dangerous mission-limitation-busting potential is in the >> renewals section (F). This is problematic partly because the CCWG never >> agreed to exempt renewals. We agreed to grandfather existing agreements, >> for the sake of stability. But the assumption was that if anything in these >> existing agreements contravened the new mission limitations, that they >> COULD be challenged during a renewal process. A contract renewal with a >> registry could include all kinds of regulatory measures that exceed the >> mission, and if these measures are framed as a "renewal of an existing >> agreement" then ICANN could in principle get away with anything. >> >> >> >> >> >> >> >> So I hope we are able to make it clear to ICANN and the CCWG that these >> provisions need to be changed.. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> From: Alissa Cooper [ mailto:alissa at cooperw.in ] >> Sent: Friday, April 29, 2016 3:00 PM >> To: Mueller, Milton L < milton at gatech.edu > >> Cc: Lynn St.Amour < Lynn at LStAmour.org >; IANA etc etcCoordination >> Group < internal-cg at ianacg.org > >> Subject: Re: [Internal-cg] bylaws feedback >> >> >> >> >> >> >> >> >> For folks following this issue, it is definitely worth reading the transcript or >> listening to the recording of the last CCWG call: >> https://community.icann.org/pages/viewpage.action?pageId=58730392 >> >> >> >> >> >> >> >> >> >> The more that I have thought about this, it has become clear to me that the >> core issue here is that there is a portion of bylaws section 1.1(d) that is not >> called for either by our proposal or by the CCWG proposal, as Lynn says. >> Had the content of 1.1(d)(ii)(B-E) been discussed as part of the transition >> proposal development, I think the concerns being raised now would have >> been raised then, and the whole community would have had time to sort >> them out. (I note that there was an extended discussion about RA/RAA >> agreements in the CCWG and that did result in text in its proposal in >> paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not extend >> to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been created >> out of whole cloth by the bylaws drafting team, and that was not within >> their remit in my opinion. The Bylaws are just supposed to implement the >> proposals. >> >> >> >> >> >> >> >> >> >> I think there are substantive issues too, but from an ICG perspective we >> may or may not want to focus on those. >> >> >> >> >> >> >> >> >> >> I would support sending a comment. We sent a message early on during the >> bylaws drafting and received no response, and the call to discuss this didn’t >> even occur until after the bylaws were put out for public comment. >> >> >> >> >> >> >> >> >> >> Alissa >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Apr 29, 2016, at 11:17 AM, Mueller, Milton L < milton at gatech.edu > >> wrote: >> >> >> >> >> >> >> >> >> >> I support what you are saying. I take it you are not satisfied with the >> lawyers' explanation? I was not able to attend the 0:400 call a few days ago >> so was not able to question them about it or hear their answers. >> >> --MM >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> From: Lynn St.Amour [ mailto:Lynn at LStAmour.org ] >> Sent: Friday, April 29, 2016 1:55 PM >> To: Alissa Cooper < alissa at cooperw.in >; Mueller, Milton L < >> milton at gatech.edu >; IANA etc etcCoordination Group > cg at ianacg.org > >> Subject: Re: [Internal-cg] bylaws feedback >> >> Hi Alissa, Milton, all, >> >> I would like to come back to this subject. Specifically, I would like to >> propose that the ICG send in a statement to the By-laws comment period. >> >> Alissa commented on a specific concern (see thread below) and I also >> believe the ICG should be concerned about the overreach in the draft >> bylaws. >> >> My main concerns are: >> >> - the fact that these draft by-laws, through the grand-fathering provisions, >> allow external agreements to define ICANN's Mission which seems like a >> bad idea for many reasons. Further, this contradicts the desires of the >> community (or is a run around the community - intentional or not) who >> worked hard to clarify and correctly state ICANN’s mission throughout the >> IANA Transition process (paragraphs 140-144 of the CCWG-Accountability >> proposal). >> >> - the ICG process was fashioned to ensure that the transition plans reflected >> the consensus of the Internet community. And, it was to respect the roles >> and responsibilities of the OCs in defining their own transition plans. The >> ICG and the CCWG reports define those wishes, and any changes to the >> bylaws were to be to implement those wishes, nothing more. Yet provisions >> in sections >> 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- >> Accountability proposals, and so there has not been appropriate >> community involvement or review for those changes. Note: these sections >> affect much of the Internet community, as they apply to agreements >> between ICANN and the ASO, NRO, IETF, Root Zone Maintainer, and PTI. >> >> For transparency: the IAB/IETF are also concerned about the overreach and >> are drafting their own comments, and as an IAB appointee to the ICG, I am >> part of that review as well. >> >> If there is support for the ICG sending in a comment, I would be happy to >> work with Alissa and others to draft something for ICG review. >> >> Regards, >> Lynn >> >> >> >> >> >> >> >> >> >> >> >> On Apr 12, 2016, at 3:15 PM, Alissa Cooper < alissa at cooperw.in > wrote: >> >> From the minutes it looks like this was discussed on the CCWG call and >> there >> >> >> >> will be follow-up. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Apr 12, 2016, at 8:39 AM, Mueller, Milton L < milton at gatech.edu > >> >> >> >> wrote: >> >> >> >> >> >> >> >> >> >> >> >> >> I sent it yesterday but there has been no response at all. >> >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> From: Alissa Cooper [ mailto:alissa at cooperw.in ] >> Sent: Monday, April 11, 2016 4:54 PM >> To: Mueller, Milton L < milton at gatech.edu > >> Cc: IANA etc etcCoordination Group < internal-cg at ianacg.org > >> Subject: Re: [Internal-cg] bylaws feedback >> >> I think that would be fine. >> >> Thanks, >> Alissa >> >> >> >> >> >> >> >> >> >> >> On Apr 11, 2016, at 1:04 PM, Mueller, Milton L < milton at gatech.edu > >> >> >> >> wrote: >> >> >> >> >> >> >> >> >> >> >> Alissa >> If you don't mind I will just forward your message to the bylaws >> and CWG >> >> >> >> lists. >> >> >> >> >> >> >> >> >> >> If there is some other way you want me to do this, please let me know. >> >> --MM >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> From: Internal-cg [ mailto:internal-cg-bounces at ianacg.org ] On >> Behalf Of Alissa Cooper >> Sent: Monday, April 11, 2016 1:49 PM >> To: IANA etc etcCoordination Group < internal-cg at ianacg.org > >> Subject: [Internal-cg] bylaws feedback >> >> I have looked a bit at the draft bylaws and I’d like to ask >> Kavouss and Milton to bring the following issue back to the bylaws >> >> >> >> drafting group: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Section 1.1(d)(ii) incorporates by reference a number of documents >> external to the bylaws as a means to prevent challenges on the >> basis that those documents conflict with or violate the bylaws. In >> particular, bullet (D) applies this provision to "the IANA Naming >> Function Contract between ICANN and PTI effective [October 1, 2016]." >> >> Given the ICG's historical encouragement of the community to meet >> timelines necessary for a successful transition, I find this >> provision to be extremely problematic. It incorporates a reference >> to a document that does not exist yet and that is unlikely to be >> completed by the time the bylaws are supposed to be done (early >> June). In fact, it is not even clear at this point whether the new >> ICANN affiliate to be setup will be name "PTI" or have some other >> name. I don't understand how anyone can reason about whether >> 1.1(d)(ii) is an acceptable bylaws provision if it references a >> document that has not been written. (This also applies to (B) and >> (C) since it could apply to future documents that haven’t been >> written >> yet.) >> >> Furthermore, I question whether it is a sound decision to >> essentially allow for documents external to the bylaws to be able >> to modify the bylaws (under (F)). This section would make more >> sense if it was entirely internally specified, without the >> references to external documents. At a minimum, I think we should >> recommend that (D) be >> >> >> >> removed. >> >> >> >> >> >> >> >> >> >> >> >> >> Thanks, >> Alissa >> _______________________________________________ >> Internal-cg mailing list >> Internal-cg at mm.ianacg.org >> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >> >> >> _______________________________________________ >> Internal-cg mailing list >> Internal-cg at mm.ianacg.org >> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >> >> _______________________________________________ >> Internal-cg mailing list >> Internal-cg at mm.ianacg.org >> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org > _______________________________________________ > Internal-cg mailing list > Internal-cg at mm.ianacg.org > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org From kavouss.arasteh at gmail.com Fri May 6 06:59:16 2016 From: kavouss.arasteh at gmail.com (Kavouss Arasteh) Date: Fri, 6 May 2016 08:59:16 +0200 Subject: [Internal-cg] bylaws feedback In-Reply-To: <7146C0FDA8771A43BEB20E18700C2E4F0181AF71AF3A@ACCAN01.accan.local> References: <142976331.139.1462343299764.JavaMail.jjs-mac-2@macbook-air-de-jean-jacques-2.home> <7146C0FDA8771A43BEB20E18700C2E4F0181AF71AF3A@ACCAN01.accan.local> Message-ID: Jean Jaques Tks This is what I and you pushed since long time but have not yet been heard Kavousd Sent from my iPhone > On 5 May 2016, at 09:43, Narelle Clark wrote: > > Jean-Jacques has the rationale exactly. > > +1 > > Narelle > > >> -----Original Message----- >> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of >> Subrenat, Jean-Jacques >> Sent: Wednesday, 4 May 2016 4:28 PM >> To: Martin Boyle >> Cc: Lynn St.Amour; Milton L Mueller; IANA etc etcCoordination Group >> Subject: Re: [Internal-cg] bylaws feedback >> >> Hello Alissa & All, >> >> I support the draft as it now stands, in order to >> - warn against any initiative or mechanism which would endanger the >> Transition proposal before it has even been thoroughly vetted in >> Washington, >> - underline the risk of the ICANN Mission being susceptible to modification >> by external texts or undertakings, some of which are not yet in existence, >> - demand the withdrawal of Sections 1.1(d)(ii)(B)-(E), and the modification >> of Section 1.1(d)(ii)(F) so as to apply only to Section 1.1(d)(ii)(A). >> >> Best regards, >> Jean-Jacques. >> >> >> >> >> ----- Mail original ----- >> De: "Martin Boyle" >> À: "Alissa Cooper" , "Milton L Mueller" >> >> Cc: "Lynn St.Amour" , "IANA etc etcCoordination >> Group" >> Envoyé: Mercredi 4 Mai 2016 00:15:40 >> Objet: Re: [Internal-cg] bylaws feedback >> >> >> >> >> >> Hi Alissa, all, >> >> >> >> I agree with you, Alissa. This sort of detail does seem to me to go well >> beyond the remit of the ICG and we should certainly not be seeking to >> upset areas already agreed in the CCWG-Accountability process. >> >> >> >> For the rest of this, I am afraid I have not been following the CCWG process >> carefully enough to have a view of where the text bylaw drafting goes >> beyond the consensus of the proposal. I’ll try to look at it tomorrow, but on >> my cursory reading of the arguments below, this does look like a legitimate >> input from the ICG. >> >> >> >> Hope this helps >> >> >> >> Martin >> >> >> >> >> >> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of >> Alissa Cooper >> Sent: 03 May 2016 22:10 >> To: Mueller, Milton L >> Cc: Lynn St.Amour ; IANA etc etcCoordination Group >> >> Subject: Re: [Internal-cg] bylaws feedback >> >> >> >> >> I don’t have an opinion about the substance of the RA/RAA renewals, but I >> don’t think they are within the scope of what the ICG should comment on. >> >> >> >> >> >> The renewal of RA and RAA agreements were discussed on today’s CCWG >> call (as well as on several previous CCWG calls and the CCWG mailing list). It >> appears that the CCWG will be commenting on these renewals in its own >> comments about the Bylaws, and will be supporting the existing language in >> (F) as it applies to the RA and RAA agreements. Considering that the CCWG >> appears to have discussed this topic at great length and has consensus on >> it, I don’t think the same argument we are making about (B)-(E) applies to >> the RA/RAA renewals. >> >> >> >> >> >> The CCWG is planning to submit its comments by May 10, so there should >> be more clarity about exactly what they intend to say soon. >> >> >> >> >> >> Alissa >> >> >> >> >> >> >> >> >> >> >> On May 3, 2016, at 9:59 AM, Mueller, Milton L < milton at gatech.edu > >> wrote: >> >> >> >> >> >> (F) applies the grandfathering to renewals of the agreements appearing in >> (B)-(D). >> >> >> >> >> >> MM: not correct: (F) applies the grandfathering to renewals of A – D. It >> reads: >> >> >> >> >> >> “(F) any renewals of agreements described in subsections (A)-(D) pursuant >> to their terms and conditions for renewal.” >> >> >> >> >> >> As I said in my initial comment, renewals of RA and RAA agreements are the >> most susceptible to bypassing mission limitations, because ICANN has the >> most expansive powers over names and the names community, unlike >> numbers and protocols, has not created a viable mechanism for changing >> the IFO. >> >> >> >> >> >> Picture this scenario: ICANN adds a highly regulatory requirement to the >> .com contract renewal; requiring it to pre-screen content in all .com second- >> level registrations. We might say, “this obviously violates the prohibition of >> content regulation in the mission statement,” but ICANN legal replies: “oh >> no, this is a renewal of the com agreement and therefore it is exempt from >> any such challenge.” >> >> >> >> >> >> If someone can show me that I am wrong legally about this possibility I’d be >> happy to drop it. But I haven’t seen any convincing arguments as to how >> this would not be possible. >> >> >> >> >> >> Therefore it would be extremely difficult for me to sign on to this statement >> if it does not mention the RA/RAA renewals problem and I frankly think >> we’d be missing the boat in a big way. >> >> >> >> >> >> --MM >> >> >> >> >> >> >> >> The ICG process was fashioned to ensure that the transition plans reflected >> the consensus of the Internet community and allowed the operational >> communities to define their own transition plans. The ICG and the CCWG >> proposals define those wishes, and any changes to the Bylaws were to be to >> implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are >> outside the scope of both the ICG and the CCWG proposals. Unlike Section >> 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is >> documented in paragraph 147 of the CCWG proposal, the substance of (B)- >> (E) have not enjoyed appropriate community involvement or review. These >> sections affect much of the Internet community since they apply to >> agreements with a variety of external parties, including all of the >> operational communities. >> >> >> >> >> >> >> >> Because several of the referenced agreements have not yet been written >> and most have not yet been agreed to by the relevant parties, the draft >> Bylaws essentially allow these external agreements to define ICANN's >> Mission. This seems like a bad idea for many reasons, not the least of which >> is that it creates the possibility for the agreements to contradict or >> circumvent the desires of the community who worked hard to clarify and >> correctly state ICANN’s Mission throughout the IANA stewardship >> transition process (see paragraphs 140-147 of the CCWG proposal). >> >> >> >> >> >> >> >> The ICG believes that in order for the Bylaws to be considered consistent >> with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and >> Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). >> This assumes that (F) is indeed called for by paragraph 147 of the CCWG >> proposal, which we leave for the CCWG to judge. >> >> >> >> >> >> >> >> Regards, >> >> >> >> >> >> >> >> Alissa Cooper on behalf of the ICG >> >> >> >> >> >> >> >> >> >> >> >> [1] http://mm.icann.org/pipermail/cwg-stewardship/2016- >> April/004877.html >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Apr 30, 2016, at 8:16 AM, Mueller, Milton L < milton at gatech.edu > >> wrote: >> >> >> >> >> >> >> >> Ok, I have had time to read the transcript. I am even more strongly >> committed to developing a comment as ICG. >> >> >> >> >> >> >> >> Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that allows all >> of the work that was done to more precisely define the mission statement >> of ICANN in these bylaws ...to be completely contravened by whatever gets >> written into the ICANN PTI contract Because what this is says is that no one >> in the future will ever be able to challenge that contract on the basis that it >> contravenes the mission.” >> >> >> >> >> >> >> >> [and, I might add, the RZM contract, and renewals of registry contracts]. >> >> >> >> >> >> >> >> The only answer I saw to this was that we don’t need to worry about it >> because the PTI contract will be put up for public comment. >> >> >> >> >> >> >> >> Alissa also made the point: >> >> >> >> "this memo ... seems to imply that ... the most important thing out of all of >> this is that ICANN can continue to perform the IANA function. And I think >> what we all learned in (unintelligible) in terms of what the ICG proposal says >> is that in fact that is not the most important thing. The most important >> thing is that the IANA functions can continue to be performed by some >> operator who’s capable of performing them according to the service level >> agreements that the community ...has. And those two things are not the >> same. And I certainly –I will put my IETF hat on here for a second and say >> that I think from an IETF perspective the important thing is that a protocol >> parameters functions can continue to be performed, not that they can only >> continue to be performed by ICANN." >> >> >> >> >> >> >> >> I don't think this argument of Alissa was ever answered. It seems like there >> could be ways of drafting these sections that do not commit us to a specific >> contract but makes it clear that performance of the IANA functions is not >> challengable as a mission violation so long as the community actually wants >> ICANN to perform those functions. >> >> >> >> >> >> >> >> Indeed, I am having trouble understanding the threat that these sections >> are supposed to avoid. >> >> >> >> >> >> >> >> However, the most dangerous mission-limitation-busting potential is in the >> renewals section (F). This is problematic partly because the CCWG never >> agreed to exempt renewals. We agreed to grandfather existing agreements, >> for the sake of stability. But the assumption was that if anything in these >> existing agreements contravened the new mission limitations, that they >> COULD be challenged during a renewal process. A contract renewal with a >> registry could include all kinds of regulatory measures that exceed the >> mission, and if these measures are framed as a "renewal of an existing >> agreement" then ICANN could in principle get away with anything. >> >> >> >> >> >> >> >> So I hope we are able to make it clear to ICANN and the CCWG that these >> provisions need to be changed.. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> From: Alissa Cooper [ mailto:alissa at cooperw.in ] >> Sent: Friday, April 29, 2016 3:00 PM >> To: Mueller, Milton L < milton at gatech.edu > >> Cc: Lynn St.Amour < Lynn at LStAmour.org >; IANA etc etcCoordination >> Group < internal-cg at ianacg.org > >> Subject: Re: [Internal-cg] bylaws feedback >> >> >> >> >> >> >> >> >> For folks following this issue, it is definitely worth reading the transcript or >> listening to the recording of the last CCWG call: >> https://community.icann.org/pages/viewpage.action?pageId=58730392 >> >> >> >> >> >> >> >> >> >> The more that I have thought about this, it has become clear to me that the >> core issue here is that there is a portion of bylaws section 1.1(d) that is not >> called for either by our proposal or by the CCWG proposal, as Lynn says. >> Had the content of 1.1(d)(ii)(B-E) been discussed as part of the transition >> proposal development, I think the concerns being raised now would have >> been raised then, and the whole community would have had time to sort >> them out. (I note that there was an extended discussion about RA/RAA >> agreements in the CCWG and that did result in text in its proposal in >> paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not extend >> to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been created >> out of whole cloth by the bylaws drafting team, and that was not within >> their remit in my opinion. The Bylaws are just supposed to implement the >> proposals. >> >> >> >> >> >> >> >> >> >> I think there are substantive issues too, but from an ICG perspective we >> may or may not want to focus on those. >> >> >> >> >> >> >> >> >> >> I would support sending a comment. We sent a message early on during the >> bylaws drafting and received no response, and the call to discuss this didn’t >> even occur until after the bylaws were put out for public comment. >> >> >> >> >> >> >> >> >> >> Alissa >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Apr 29, 2016, at 11:17 AM, Mueller, Milton L < milton at gatech.edu > >> wrote: >> >> >> >> >> >> >> >> >> >> I support what you are saying. I take it you are not satisfied with the >> lawyers' explanation? I was not able to attend the 0:400 call a few days ago >> so was not able to question them about it or hear their answers. >> >> --MM >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> From: Lynn St.Amour [ mailto:Lynn at LStAmour.org ] >> Sent: Friday, April 29, 2016 1:55 PM >> To: Alissa Cooper < alissa at cooperw.in >; Mueller, Milton L < >> milton at gatech.edu >; IANA etc etcCoordination Group > cg at ianacg.org > >> Subject: Re: [Internal-cg] bylaws feedback >> >> Hi Alissa, Milton, all, >> >> I would like to come back to this subject. Specifically, I would like to >> propose that the ICG send in a statement to the By-laws comment period. >> >> Alissa commented on a specific concern (see thread below) and I also >> believe the ICG should be concerned about the overreach in the draft >> bylaws. >> >> My main concerns are: >> >> - the fact that these draft by-laws, through the grand-fathering provisions, >> allow external agreements to define ICANN's Mission which seems like a >> bad idea for many reasons. Further, this contradicts the desires of the >> community (or is a run around the community - intentional or not) who >> worked hard to clarify and correctly state ICANN’s mission throughout the >> IANA Transition process (paragraphs 140-144 of the CCWG-Accountability >> proposal). >> >> - the ICG process was fashioned to ensure that the transition plans reflected >> the consensus of the Internet community. And, it was to respect the roles >> and responsibilities of the OCs in defining their own transition plans. The >> ICG and the CCWG reports define those wishes, and any changes to the >> bylaws were to be to implement those wishes, nothing more. Yet provisions >> in sections >> 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- >> Accountability proposals, and so there has not been appropriate >> community involvement or review for those changes. Note: these sections >> affect much of the Internet community, as they apply to agreements >> between ICANN and the ASO, NRO, IETF, Root Zone Maintainer, and PTI. >> >> For transparency: the IAB/IETF are also concerned about the overreach and >> are drafting their own comments, and as an IAB appointee to the ICG, I am >> part of that review as well. >> >> If there is support for the ICG sending in a comment, I would be happy to >> work with Alissa and others to draft something for ICG review. >> >> Regards, >> Lynn >> >> >> >> >> >> >> >> >> >> >> >> On Apr 12, 2016, at 3:15 PM, Alissa Cooper < alissa at cooperw.in > wrote: >> >> From the minutes it looks like this was discussed on the CCWG call and >> there >> >> >> >> will be follow-up. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Apr 12, 2016, at 8:39 AM, Mueller, Milton L < milton at gatech.edu > >> >> >> >> wrote: >> >> >> >> >> >> >> >> >> >> >> >> >> I sent it yesterday but there has been no response at all. >> >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> From: Alissa Cooper [ mailto:alissa at cooperw.in ] >> Sent: Monday, April 11, 2016 4:54 PM >> To: Mueller, Milton L < milton at gatech.edu > >> Cc: IANA etc etcCoordination Group < internal-cg at ianacg.org > >> Subject: Re: [Internal-cg] bylaws feedback >> >> I think that would be fine. >> >> Thanks, >> Alissa >> >> >> >> >> >> >> >> >> >> >> On Apr 11, 2016, at 1:04 PM, Mueller, Milton L < milton at gatech.edu > >> >> >> >> wrote: >> >> >> >> >> >> >> >> >> >> >> Alissa >> If you don't mind I will just forward your message to the bylaws >> and CWG >> >> >> >> lists. >> >> >> >> >> >> >> >> >> >> If there is some other way you want me to do this, please let me know. >> >> --MM >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> From: Internal-cg [ mailto:internal-cg-bounces at ianacg.org ] On >> Behalf Of Alissa Cooper >> Sent: Monday, April 11, 2016 1:49 PM >> To: IANA etc etcCoordination Group < internal-cg at ianacg.org > >> Subject: [Internal-cg] bylaws feedback >> >> I have looked a bit at the draft bylaws and I’d like to ask >> Kavouss and Milton to bring the following issue back to the bylaws >> >> >> >> drafting group: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Section 1.1(d)(ii) incorporates by reference a number of documents >> external to the bylaws as a means to prevent challenges on the >> basis that those documents conflict with or violate the bylaws. In >> particular, bullet (D) applies this provision to "the IANA Naming >> Function Contract between ICANN and PTI effective [October 1, 2016]." >> >> Given the ICG's historical encouragement of the community to meet >> timelines necessary for a successful transition, I find this >> provision to be extremely problematic. It incorporates a reference >> to a document that does not exist yet and that is unlikely to be >> completed by the time the bylaws are supposed to be done (early >> June). In fact, it is not even clear at this point whether the new >> ICANN affiliate to be setup will be name "PTI" or have some other >> name. I don't understand how anyone can reason about whether >> 1.1(d)(ii) is an acceptable bylaws provision if it references a >> document that has not been written. (This also applies to (B) and >> (C) since it could apply to future documents that haven’t been >> written >> yet.) >> >> Furthermore, I question whether it is a sound decision to >> essentially allow for documents external to the bylaws to be able >> to modify the bylaws (under (F)). This section would make more >> sense if it was entirely internally specified, without the >> references to external documents. At a minimum, I think we should >> recommend that (D) be >> >> >> >> removed. >> >> >> >> >> >> >> >> >> >> >> >> >> Thanks, >> Alissa >> _______________________________________________ >> Internal-cg mailing list >> Internal-cg at mm.ianacg.org >> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >> >> >> _______________________________________________ >> Internal-cg mailing list >> Internal-cg at mm.ianacg.org >> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >> >> _______________________________________________ >> Internal-cg mailing list >> Internal-cg at mm.ianacg.org >> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org > _______________________________________________ > Internal-cg mailing list > Internal-cg at mm.ianacg.org > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org From alissa at cooperw.in Fri May 6 23:15:02 2016 From: alissa at cooperw.in (Alissa Cooper) Date: Fri, 6 May 2016 16:15:02 -0700 Subject: [Internal-cg] Fwd: WSIS Forum - CCWG Accountability session: statement regarding the ICG References: <008b01d1a6f7$35a84c50$a0f8e4f0$@icgsec.asia> Message-ID: <8594FCB5-E92F-44C2-A958-80ACFC3A7030@cooperw.in> Kavouss was at the WSIS Forum and wanted to relay the following: > > At the WSIS forum in Geneva during the CCWG Accountability ICANN - Cross Community Working Group on Internet Governance session, the topic of the IANA transition was presented and discussed, however the ICG’s role was not fully touched upon. Due the fact that none of the ICG chairs were present and as the sole ICG member on the panel, Kavouss highlighted the important work that the ICG did in its coordination role at the forefront of the whole transition process. > Thanks, Kavouss, for making sure both the ICG and CCWG proposals got air time. Alissa -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lynn at LStAmour.org Sat May 7 16:47:31 2016 From: Lynn at LStAmour.org (Lynn St.Amour) Date: Sat, 7 May 2016 12:47:31 -0400 Subject: [Internal-cg] WSIS Forum - CCWG Accountability session: statement regarding the ICG In-Reply-To: <8594FCB5-E92F-44C2-A958-80ACFC3A7030@cooperw.in> References: <008b01d1a6f7$35a84c50$a0f8e4f0$@icgsec.asia> <8594FCB5-E92F-44C2-A958-80ACFC3A7030@cooperw.in> Message-ID: <3F4A37BF-290A-4425-8FC6-09555426E709@LStAmour.org> Hi Kavouss, all, I participated remotely in that session and would like to recognize and thank Kavouss for his very hepful comments. Lynn > On May 6, 2016, at 7:15 PM, Alissa Cooper wrote: > > Kavouss was at the WSIS Forum and wanted to relay the following: > >> >> At the WSIS forum in Geneva during the CCWG Accountability ICANN - Cross Community Working Group on Internet Governance session, the topic of the IANA transition was presented and discussed, however the ICG’s role was not fully touched upon. Due the fact that none of the ICG chairs were present and as the sole ICG member on the panel, Kavouss highlighted the important work that the ICG did in its coordination role at the forefront of the whole transition process. >> > > Thanks, Kavouss, for making sure both the ICG and CCWG proposals got air time. > > Alissa > _______________________________________________ > Internal-cg mailing list > Internal-cg at mm.ianacg.org > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org From manal at tra.gov.eg Sat May 7 20:59:45 2016 From: manal at tra.gov.eg (Manal Ismail) Date: Sat, 7 May 2016 20:59:45 +0000 Subject: [Internal-cg] WSIS Forum - CCWG Accountability session: statement regarding the ICG In-Reply-To: <3F4A37BF-290A-4425-8FC6-09555426E709@LStAmour.org> References: <008b01d1a6f7$35a84c50$a0f8e4f0$@icgsec.asia> <8594FCB5-E92F-44C2-A958-80ACFC3A7030@cooperw.in> <3F4A37BF-290A-4425-8FC6-09555426E709@LStAmour.org> Message-ID: Adding my thanks .. Many thanks Kavouss .. Kind Regards --Manal -----Original Message----- From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of Lynn St.Amour Sent: Saturday, May 7, 2016 6:48 PM To: IANA Stewardship Transition Coordination Group Subject: Re: [Internal-cg] WSIS Forum - CCWG Accountability session: statement regarding the ICG Hi Kavouss, all, I participated remotely in that session and would like to recognize and thank Kavouss for his very hepful comments. Lynn > On May 6, 2016, at 7:15 PM, Alissa Cooper wrote: > > Kavouss was at the WSIS Forum and wanted to relay the following: > >> >> At the WSIS forum in Geneva during the CCWG Accountability ICANN - Cross Community Working Group on Internet Governance session, the topic of the IANA transition was presented and discussed, however the ICG’s role was not fully touched upon. Due the fact that none of the ICG chairs were present and as the sole ICG member on the panel, Kavouss highlighted the important work that the ICG did in its coordination role at the forefront of the whole transition process. >> > > Thanks, Kavouss, for making sure both the ICG and CCWG proposals got air time. > > Alissa > _______________________________________________ > Internal-cg mailing list > Internal-cg at mm.ianacg.org > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org _______________________________________________ Internal-cg mailing list Internal-cg at mm.ianacg.org http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org From alissa at cooperw.in Wed May 11 19:11:25 2016 From: alissa at cooperw.in (Alissa Cooper) Date: Wed, 11 May 2016 15:11:25 -0400 Subject: [Internal-cg] bylaws feedback In-Reply-To: References: <142976331.139.1462343299764.JavaMail.jjs-mac-2@macbook-air-de-jean-jacques-2.home> <7146C0FDA8771A43BEB20E18700C2E4F0181AF71AF3A@ACCAN01.accan.local> Message-ID: <9B260ABE-EA98-4DD3-B8A5-2510C600CFAF@cooperw.in> I’d like us to close out on this. If anyone objects to us submitting the text below as a public comment on the draft bylaws, please say so by Friday, May 13 at 23:59. If there are no objections, I’ll submit it. --- The ICG appreciates the opportunity to comment on the draft ICANN Bylaws. The ICG previously communicated concerns about Section 1.1(d)(ii) to the Bylaws drafting group [1]. However, these concerns were not addressed in the draft Bylaws that were posted for public comment. Section 1.1(d) "grandfathers" a number of agreements into the Bylaws in order to prevent parties from challenging those agreements on the basis that they violate the ICANN Mission statement. Under Section 1.1(d)(ii), (A) applies to RA/RAA agreements; (B)-(D) apply to agreements between ICANN and the NRO, ASO, IETF, RZM, and PTI; and (E) applies to ICANN's Five-Year Strategic Plan and Five-Year Operating Plan. (F) applies the grandfathering to renewals of the agreements appearing in (B)-(E). The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. Regards, Alissa Cooper on behalf of the ICG > On May 6, 2016, at 2:59 AM, Kavouss Arasteh wrote: > > Jean Jaques > Tks > This is what I and you pushed since long time but have not yet been heard > Kavousd > > Sent from my iPhone > >> On 5 May 2016, at 09:43, Narelle Clark wrote: >> >> Jean-Jacques has the rationale exactly. >> >> +1 >> >> Narelle >> >> >>> -----Original Message----- >>> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of >>> Subrenat, Jean-Jacques >>> Sent: Wednesday, 4 May 2016 4:28 PM >>> To: Martin Boyle >>> Cc: Lynn St.Amour; Milton L Mueller; IANA etc etcCoordination Group >>> Subject: Re: [Internal-cg] bylaws feedback >>> >>> Hello Alissa & All, >>> >>> I support the draft as it now stands, in order to >>> - warn against any initiative or mechanism which would endanger the >>> Transition proposal before it has even been thoroughly vetted in >>> Washington, >>> - underline the risk of the ICANN Mission being susceptible to modification >>> by external texts or undertakings, some of which are not yet in existence, >>> - demand the withdrawal of Sections 1.1(d)(ii)(B)-(E), and the modification >>> of Section 1.1(d)(ii)(F) so as to apply only to Section 1.1(d)(ii)(A). >>> >>> Best regards, >>> Jean-Jacques. >>> >>> >>> >>> >>> ----- Mail original ----- >>> De: "Martin Boyle" >>> À: "Alissa Cooper" , "Milton L Mueller" >>> >>> Cc: "Lynn St.Amour" , "IANA etc etcCoordination >>> Group" >>> Envoyé: Mercredi 4 Mai 2016 00:15:40 >>> Objet: Re: [Internal-cg] bylaws feedback >>> >>> >>> >>> >>> >>> Hi Alissa, all, >>> >>> >>> >>> I agree with you, Alissa. This sort of detail does seem to me to go well >>> beyond the remit of the ICG and we should certainly not be seeking to >>> upset areas already agreed in the CCWG-Accountability process. >>> >>> >>> >>> For the rest of this, I am afraid I have not been following the CCWG process >>> carefully enough to have a view of where the text bylaw drafting goes >>> beyond the consensus of the proposal. I’ll try to look at it tomorrow, but on >>> my cursory reading of the arguments below, this does look like a legitimate >>> input from the ICG. >>> >>> >>> >>> Hope this helps >>> >>> >>> >>> Martin >>> >>> >>> >>> >>> >>> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of >>> Alissa Cooper >>> Sent: 03 May 2016 22:10 >>> To: Mueller, Milton L >>> Cc: Lynn St.Amour ; IANA etc etcCoordination Group >>> >>> Subject: Re: [Internal-cg] bylaws feedback >>> >>> >>> >>> >>> I don’t have an opinion about the substance of the RA/RAA renewals, but I >>> don’t think they are within the scope of what the ICG should comment on. >>> >>> >>> >>> >>> >>> The renewal of RA and RAA agreements were discussed on today’s CCWG >>> call (as well as on several previous CCWG calls and the CCWG mailing list). It >>> appears that the CCWG will be commenting on these renewals in its own >>> comments about the Bylaws, and will be supporting the existing language in >>> (F) as it applies to the RA and RAA agreements. Considering that the CCWG >>> appears to have discussed this topic at great length and has consensus on >>> it, I don’t think the same argument we are making about (B)-(E) applies to >>> the RA/RAA renewals. >>> >>> >>> >>> >>> >>> The CCWG is planning to submit its comments by May 10, so there should >>> be more clarity about exactly what they intend to say soon. >>> >>> >>> >>> >>> >>> Alissa >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On May 3, 2016, at 9:59 AM, Mueller, Milton L < milton at gatech.edu > >>> wrote: >>> >>> >>> >>> >>> >>> (F) applies the grandfathering to renewals of the agreements appearing in >>> (B)-(D). >>> >>> >>> >>> >>> >>> MM: not correct: (F) applies the grandfathering to renewals of A – D. It >>> reads: >>> >>> >>> >>> >>> >>> “(F) any renewals of agreements described in subsections (A)-(D) pursuant >>> to their terms and conditions for renewal.” >>> >>> >>> >>> >>> >>> As I said in my initial comment, renewals of RA and RAA agreements are the >>> most susceptible to bypassing mission limitations, because ICANN has the >>> most expansive powers over names and the names community, unlike >>> numbers and protocols, has not created a viable mechanism for changing >>> the IFO. >>> >>> >>> >>> >>> >>> Picture this scenario: ICANN adds a highly regulatory requirement to the >>> .com contract renewal; requiring it to pre-screen content in all .com second- >>> level registrations. We might say, “this obviously violates the prohibition of >>> content regulation in the mission statement,” but ICANN legal replies: “oh >>> no, this is a renewal of the com agreement and therefore it is exempt from >>> any such challenge.” >>> >>> >>> >>> >>> >>> If someone can show me that I am wrong legally about this possibility I’d be >>> happy to drop it. But I haven’t seen any convincing arguments as to how >>> this would not be possible. >>> >>> >>> >>> >>> >>> Therefore it would be extremely difficult for me to sign on to this statement >>> if it does not mention the RA/RAA renewals problem and I frankly think >>> we’d be missing the boat in a big way. >>> >>> >>> >>> >>> >>> --MM >>> >>> >>> >>> >>> >>> >>> >>> The ICG process was fashioned to ensure that the transition plans reflected >>> the consensus of the Internet community and allowed the operational >>> communities to define their own transition plans. The ICG and the CCWG >>> proposals define those wishes, and any changes to the Bylaws were to be to >>> implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are >>> outside the scope of both the ICG and the CCWG proposals. Unlike Section >>> 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is >>> documented in paragraph 147 of the CCWG proposal, the substance of (B)- >>> (E) have not enjoyed appropriate community involvement or review. These >>> sections affect much of the Internet community since they apply to >>> agreements with a variety of external parties, including all of the >>> operational communities. >>> >>> >>> >>> >>> >>> >>> >>> Because several of the referenced agreements have not yet been written >>> and most have not yet been agreed to by the relevant parties, the draft >>> Bylaws essentially allow these external agreements to define ICANN's >>> Mission. This seems like a bad idea for many reasons, not the least of which >>> is that it creates the possibility for the agreements to contradict or >>> circumvent the desires of the community who worked hard to clarify and >>> correctly state ICANN’s Mission throughout the IANA stewardship >>> transition process (see paragraphs 140-147 of the CCWG proposal). >>> >>> >>> >>> >>> >>> >>> >>> The ICG believes that in order for the Bylaws to be considered consistent >>> with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and >>> Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). >>> This assumes that (F) is indeed called for by paragraph 147 of the CCWG >>> proposal, which we leave for the CCWG to judge. >>> >>> >>> >>> >>> >>> >>> >>> Regards, >>> >>> >>> >>> >>> >>> >>> >>> Alissa Cooper on behalf of the ICG >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> [1] http://mm.icann.org/pipermail/cwg-stewardship/2016- >>> April/004877.html >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Apr 30, 2016, at 8:16 AM, Mueller, Milton L < milton at gatech.edu > >>> wrote: >>> >>> >>> >>> >>> >>> >>> >>> Ok, I have had time to read the transcript. I am even more strongly >>> committed to developing a comment as ICG. >>> >>> >>> >>> >>> >>> >>> >>> Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that allows all >>> of the work that was done to more precisely define the mission statement >>> of ICANN in these bylaws ...to be completely contravened by whatever gets >>> written into the ICANN PTI contract Because what this is says is that no one >>> in the future will ever be able to challenge that contract on the basis that it >>> contravenes the mission.” >>> >>> >>> >>> >>> >>> >>> >>> [and, I might add, the RZM contract, and renewals of registry contracts]. >>> >>> >>> >>> >>> >>> >>> >>> The only answer I saw to this was that we don’t need to worry about it >>> because the PTI contract will be put up for public comment. >>> >>> >>> >>> >>> >>> >>> >>> Alissa also made the point: >>> >>> >>> >>> "this memo ... seems to imply that ... the most important thing out of all of >>> this is that ICANN can continue to perform the IANA function. And I think >>> what we all learned in (unintelligible) in terms of what the ICG proposal says >>> is that in fact that is not the most important thing. The most important >>> thing is that the IANA functions can continue to be performed by some >>> operator who’s capable of performing them according to the service level >>> agreements that the community ...has. And those two things are not the >>> same. And I certainly –I will put my IETF hat on here for a second and say >>> that I think from an IETF perspective the important thing is that a protocol >>> parameters functions can continue to be performed, not that they can only >>> continue to be performed by ICANN." >>> >>> >>> >>> >>> >>> >>> >>> I don't think this argument of Alissa was ever answered. It seems like there >>> could be ways of drafting these sections that do not commit us to a specific >>> contract but makes it clear that performance of the IANA functions is not >>> challengable as a mission violation so long as the community actually wants >>> ICANN to perform those functions. >>> >>> >>> >>> >>> >>> >>> >>> Indeed, I am having trouble understanding the threat that these sections >>> are supposed to avoid. >>> >>> >>> >>> >>> >>> >>> >>> However, the most dangerous mission-limitation-busting potential is in the >>> renewals section (F). This is problematic partly because the CCWG never >>> agreed to exempt renewals. We agreed to grandfather existing agreements, >>> for the sake of stability. But the assumption was that if anything in these >>> existing agreements contravened the new mission limitations, that they >>> COULD be challenged during a renewal process. A contract renewal with a >>> registry could include all kinds of regulatory measures that exceed the >>> mission, and if these measures are framed as a "renewal of an existing >>> agreement" then ICANN could in principle get away with anything. >>> >>> >>> >>> >>> >>> >>> >>> So I hope we are able to make it clear to ICANN and the CCWG that these >>> provisions need to be changed.. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> From: Alissa Cooper [ mailto:alissa at cooperw.in ] >>> Sent: Friday, April 29, 2016 3:00 PM >>> To: Mueller, Milton L < milton at gatech.edu > >>> Cc: Lynn St.Amour < Lynn at LStAmour.org >; IANA etc etcCoordination >>> Group < internal-cg at ianacg.org > >>> Subject: Re: [Internal-cg] bylaws feedback >>> >>> >>> >>> >>> >>> >>> >>> >>> For folks following this issue, it is definitely worth reading the transcript or >>> listening to the recording of the last CCWG call: >>> https://community.icann.org/pages/viewpage.action?pageId=58730392 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> The more that I have thought about this, it has become clear to me that the >>> core issue here is that there is a portion of bylaws section 1.1(d) that is not >>> called for either by our proposal or by the CCWG proposal, as Lynn says. >>> Had the content of 1.1(d)(ii)(B-E) been discussed as part of the transition >>> proposal development, I think the concerns being raised now would have >>> been raised then, and the whole community would have had time to sort >>> them out. (I note that there was an extended discussion about RA/RAA >>> agreements in the CCWG and that did result in text in its proposal in >>> paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not extend >>> to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been created >>> out of whole cloth by the bylaws drafting team, and that was not within >>> their remit in my opinion. The Bylaws are just supposed to implement the >>> proposals. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I think there are substantive issues too, but from an ICG perspective we >>> may or may not want to focus on those. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I would support sending a comment. We sent a message early on during the >>> bylaws drafting and received no response, and the call to discuss this didn’t >>> even occur until after the bylaws were put out for public comment. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Alissa >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Apr 29, 2016, at 11:17 AM, Mueller, Milton L < milton at gatech.edu > >>> wrote: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I support what you are saying. I take it you are not satisfied with the >>> lawyers' explanation? I was not able to attend the 0:400 call a few days ago >>> so was not able to question them about it or hear their answers. >>> >>> --MM >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Lynn St.Amour [ mailto:Lynn at LStAmour.org ] >>> Sent: Friday, April 29, 2016 1:55 PM >>> To: Alissa Cooper < alissa at cooperw.in >; Mueller, Milton L < >>> milton at gatech.edu >; IANA etc etcCoordination Group >> cg at ianacg.org > >>> Subject: Re: [Internal-cg] bylaws feedback >>> >>> Hi Alissa, Milton, all, >>> >>> I would like to come back to this subject. Specifically, I would like to >>> propose that the ICG send in a statement to the By-laws comment period. >>> >>> Alissa commented on a specific concern (see thread below) and I also >>> believe the ICG should be concerned about the overreach in the draft >>> bylaws. >>> >>> My main concerns are: >>> >>> - the fact that these draft by-laws, through the grand-fathering provisions, >>> allow external agreements to define ICANN's Mission which seems like a >>> bad idea for many reasons. Further, this contradicts the desires of the >>> community (or is a run around the community - intentional or not) who >>> worked hard to clarify and correctly state ICANN’s mission throughout the >>> IANA Transition process (paragraphs 140-144 of the CCWG-Accountability >>> proposal). >>> >>> - the ICG process was fashioned to ensure that the transition plans reflected >>> the consensus of the Internet community. And, it was to respect the roles >>> and responsibilities of the OCs in defining their own transition plans. The >>> ICG and the CCWG reports define those wishes, and any changes to the >>> bylaws were to be to implement those wishes, nothing more. Yet provisions >>> in sections >>> 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- >>> Accountability proposals, and so there has not been appropriate >>> community involvement or review for those changes. Note: these sections >>> affect much of the Internet community, as they apply to agreements >>> between ICANN and the ASO, NRO, IETF, Root Zone Maintainer, and PTI. >>> >>> For transparency: the IAB/IETF are also concerned about the overreach and >>> are drafting their own comments, and as an IAB appointee to the ICG, I am >>> part of that review as well. >>> >>> If there is support for the ICG sending in a comment, I would be happy to >>> work with Alissa and others to draft something for ICG review. >>> >>> Regards, >>> Lynn >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Apr 12, 2016, at 3:15 PM, Alissa Cooper < alissa at cooperw.in > wrote: >>> >>> From the minutes it looks like this was discussed on the CCWG call and >>> there >>> >>> >>> >>> will be follow-up. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Apr 12, 2016, at 8:39 AM, Mueller, Milton L < milton at gatech.edu > >>> >>> >>> >>> wrote: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I sent it yesterday but there has been no response at all. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Alissa Cooper [ mailto:alissa at cooperw.in ] >>> Sent: Monday, April 11, 2016 4:54 PM >>> To: Mueller, Milton L < milton at gatech.edu > >>> Cc: IANA etc etcCoordination Group < internal-cg at ianacg.org > >>> Subject: Re: [Internal-cg] bylaws feedback >>> >>> I think that would be fine. >>> >>> Thanks, >>> Alissa >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Apr 11, 2016, at 1:04 PM, Mueller, Milton L < milton at gatech.edu > >>> >>> >>> >>> wrote: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Alissa >>> If you don't mind I will just forward your message to the bylaws >>> and CWG >>> >>> >>> >>> lists. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> If there is some other way you want me to do this, please let me know. >>> >>> --MM >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Internal-cg [ mailto:internal-cg-bounces at ianacg.org ] On >>> Behalf Of Alissa Cooper >>> Sent: Monday, April 11, 2016 1:49 PM >>> To: IANA etc etcCoordination Group < internal-cg at ianacg.org > >>> Subject: [Internal-cg] bylaws feedback >>> >>> I have looked a bit at the draft bylaws and I’d like to ask >>> Kavouss and Milton to bring the following issue back to the bylaws >>> >>> >>> >>> drafting group: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Section 1.1(d)(ii) incorporates by reference a number of documents >>> external to the bylaws as a means to prevent challenges on the >>> basis that those documents conflict with or violate the bylaws. In >>> particular, bullet (D) applies this provision to "the IANA Naming >>> Function Contract between ICANN and PTI effective [October 1, 2016]." >>> >>> Given the ICG's historical encouragement of the community to meet >>> timelines necessary for a successful transition, I find this >>> provision to be extremely problematic. It incorporates a reference >>> to a document that does not exist yet and that is unlikely to be >>> completed by the time the bylaws are supposed to be done (early >>> June). In fact, it is not even clear at this point whether the new >>> ICANN affiliate to be setup will be name "PTI" or have some other >>> name. I don't understand how anyone can reason about whether >>> 1.1(d)(ii) is an acceptable bylaws provision if it references a >>> document that has not been written. (This also applies to (B) and >>> (C) since it could apply to future documents that haven’t been >>> written >>> yet.) >>> >>> Furthermore, I question whether it is a sound decision to >>> essentially allow for documents external to the bylaws to be able >>> to modify the bylaws (under (F)). This section would make more >>> sense if it was entirely internally specified, without the >>> references to external documents. At a minimum, I think we should >>> recommend that (D) be >>> >>> >>> >>> removed. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Thanks, >>> Alissa >>> _______________________________________________ >>> Internal-cg mailing list >>> Internal-cg at mm.ianacg.org >>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >>> >>> >>> _______________________________________________ >>> Internal-cg mailing list >>> Internal-cg at mm.ianacg.org >>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >>> >>> _______________________________________________ >>> Internal-cg mailing list >>> Internal-cg at mm.ianacg.org >>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >> _______________________________________________ >> Internal-cg mailing list >> Internal-cg at mm.ianacg.org >> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org > > _______________________________________________ > Internal-cg mailing list > Internal-cg at mm.ianacg.org > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org From jjs at dyalog.net Thu May 12 07:21:28 2016 From: jjs at dyalog.net (Subrenat, Jean-Jacques) Date: Thu, 12 May 2016 09:21:28 +0200 (CEST) Subject: [Internal-cg] bylaws feedback In-Reply-To: <9B260ABE-EA98-4DD3-B8A5-2510C600CFAF@cooperw.in> Message-ID: <1801150400.92.1463037684894.JavaMail.jjs-mac-2@MacBook-Air-de-Jean-Jacques-2.local> Thank you Alissa. I fully support this statement. Jean-Jacques. ----- Mail original ----- De: "Alissa Cooper" À: "Kavouss Arasteh" Cc: "Lynn St.Amour" , "Milton L Mueller" , "IANA etc etcCoordination Group" Envoyé: Mercredi 11 Mai 2016 21:11:25 Objet: Re: [Internal-cg] bylaws feedback I’d like us to close out on this. If anyone objects to us submitting the text below as a public comment on the draft bylaws, please say so by Friday, May 13 at 23:59. If there are no objections, I’ll submit it. --- The ICG appreciates the opportunity to comment on the draft ICANN Bylaws. The ICG previously communicated concerns about Section 1.1(d)(ii) to the Bylaws drafting group [1]. However, these concerns were not addressed in the draft Bylaws that were posted for public comment. Section 1.1(d) "grandfathers" a number of agreements into the Bylaws in order to prevent parties from challenging those agreements on the basis that they violate the ICANN Mission statement. Under Section 1.1(d)(ii), (A) applies to RA/RAA agreements; (B)-(D) apply to agreements between ICANN and the NRO, ASO, IETF, RZM, and PTI; and (E) applies to ICANN's Five-Year Strategic Plan and Five-Year Operating Plan. (F) applies the grandfathering to renewals of the agreements appearing in (B)-(E). The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. Regards, Alissa Cooper on behalf of the ICG > On May 6, 2016, at 2:59 AM, Kavouss Arasteh wrote: > > Jean Jaques > Tks > This is what I and you pushed since long time but have not yet been heard > Kavousd > > Sent from my iPhone > >> On 5 May 2016, at 09:43, Narelle Clark wrote: >> >> Jean-Jacques has the rationale exactly. >> >> +1 >> >> Narelle >> >> >>> -----Original Message----- >>> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of >>> Subrenat, Jean-Jacques >>> Sent: Wednesday, 4 May 2016 4:28 PM >>> To: Martin Boyle >>> Cc: Lynn St.Amour; Milton L Mueller; IANA etc etcCoordination Group >>> Subject: Re: [Internal-cg] bylaws feedback >>> >>> Hello Alissa & All, >>> >>> I support the draft as it now stands, in order to >>> - warn against any initiative or mechanism which would endanger the >>> Transition proposal before it has even been thoroughly vetted in >>> Washington, >>> - underline the risk of the ICANN Mission being susceptible to modification >>> by external texts or undertakings, some of which are not yet in existence, >>> - demand the withdrawal of Sections 1.1(d)(ii)(B)-(E), and the modification >>> of Section 1.1(d)(ii)(F) so as to apply only to Section 1.1(d)(ii)(A). >>> >>> Best regards, >>> Jean-Jacques. >>> >>> >>> >>> >>> ----- Mail original ----- >>> De: "Martin Boyle" >>> À: "Alissa Cooper" , "Milton L Mueller" >>> >>> Cc: "Lynn St.Amour" , "IANA etc etcCoordination >>> Group" >>> Envoyé: Mercredi 4 Mai 2016 00:15:40 >>> Objet: Re: [Internal-cg] bylaws feedback >>> >>> >>> >>> >>> >>> Hi Alissa, all, >>> >>> >>> >>> I agree with you, Alissa. This sort of detail does seem to me to go well >>> beyond the remit of the ICG and we should certainly not be seeking to >>> upset areas already agreed in the CCWG-Accountability process. >>> >>> >>> >>> For the rest of this, I am afraid I have not been following the CCWG process >>> carefully enough to have a view of where the text bylaw drafting goes >>> beyond the consensus of the proposal. I’ll try to look at it tomorrow, but on >>> my cursory reading of the arguments below, this does look like a legitimate >>> input from the ICG. >>> >>> >>> >>> Hope this helps >>> >>> >>> >>> Martin >>> >>> >>> >>> >>> >>> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of >>> Alissa Cooper >>> Sent: 03 May 2016 22:10 >>> To: Mueller, Milton L >>> Cc: Lynn St.Amour ; IANA etc etcCoordination Group >>> >>> Subject: Re: [Internal-cg] bylaws feedback >>> >>> >>> >>> >>> I don’t have an opinion about the substance of the RA/RAA renewals, but I >>> don’t think they are within the scope of what the ICG should comment on. >>> >>> >>> >>> >>> >>> The renewal of RA and RAA agreements were discussed on today’s CCWG >>> call (as well as on several previous CCWG calls and the CCWG mailing list). It >>> appears that the CCWG will be commenting on these renewals in its own >>> comments about the Bylaws, and will be supporting the existing language in >>> (F) as it applies to the RA and RAA agreements. Considering that the CCWG >>> appears to have discussed this topic at great length and has consensus on >>> it, I don’t think the same argument we are making about (B)-(E) applies to >>> the RA/RAA renewals. >>> >>> >>> >>> >>> >>> The CCWG is planning to submit its comments by May 10, so there should >>> be more clarity about exactly what they intend to say soon. >>> >>> >>> >>> >>> >>> Alissa >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On May 3, 2016, at 9:59 AM, Mueller, Milton L < milton at gatech.edu > >>> wrote: >>> >>> >>> >>> >>> >>> (F) applies the grandfathering to renewals of the agreements appearing in >>> (B)-(D). >>> >>> >>> >>> >>> >>> MM: not correct: (F) applies the grandfathering to renewals of A – D. It >>> reads: >>> >>> >>> >>> >>> >>> “(F) any renewals of agreements described in subsections (A)-(D) pursuant >>> to their terms and conditions for renewal.” >>> >>> >>> >>> >>> >>> As I said in my initial comment, renewals of RA and RAA agreements are the >>> most susceptible to bypassing mission limitations, because ICANN has the >>> most expansive powers over names and the names community, unlike >>> numbers and protocols, has not created a viable mechanism for changing >>> the IFO. >>> >>> >>> >>> >>> >>> Picture this scenario: ICANN adds a highly regulatory requirement to the >>> .com contract renewal; requiring it to pre-screen content in all .com second- >>> level registrations. We might say, “this obviously violates the prohibition of >>> content regulation in the mission statement,” but ICANN legal replies: “oh >>> no, this is a renewal of the com agreement and therefore it is exempt from >>> any such challenge.” >>> >>> >>> >>> >>> >>> If someone can show me that I am wrong legally about this possibility I’d be >>> happy to drop it. But I haven’t seen any convincing arguments as to how >>> this would not be possible. >>> >>> >>> >>> >>> >>> Therefore it would be extremely difficult for me to sign on to this statement >>> if it does not mention the RA/RAA renewals problem and I frankly think >>> we’d be missing the boat in a big way. >>> >>> >>> >>> >>> >>> --MM >>> >>> >>> >>> >>> >>> >>> >>> The ICG process was fashioned to ensure that the transition plans reflected >>> the consensus of the Internet community and allowed the operational >>> communities to define their own transition plans. The ICG and the CCWG >>> proposals define those wishes, and any changes to the Bylaws were to be to >>> implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are >>> outside the scope of both the ICG and the CCWG proposals. Unlike Section >>> 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is >>> documented in paragraph 147 of the CCWG proposal, the substance of (B)- >>> (E) have not enjoyed appropriate community involvement or review. These >>> sections affect much of the Internet community since they apply to >>> agreements with a variety of external parties, including all of the >>> operational communities. >>> >>> >>> >>> >>> >>> >>> >>> Because several of the referenced agreements have not yet been written >>> and most have not yet been agreed to by the relevant parties, the draft >>> Bylaws essentially allow these external agreements to define ICANN's >>> Mission. This seems like a bad idea for many reasons, not the least of which >>> is that it creates the possibility for the agreements to contradict or >>> circumvent the desires of the community who worked hard to clarify and >>> correctly state ICANN’s Mission throughout the IANA stewardship >>> transition process (see paragraphs 140-147 of the CCWG proposal). >>> >>> >>> >>> >>> >>> >>> >>> The ICG believes that in order for the Bylaws to be considered consistent >>> with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and >>> Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). >>> This assumes that (F) is indeed called for by paragraph 147 of the CCWG >>> proposal, which we leave for the CCWG to judge. >>> >>> >>> >>> >>> >>> >>> >>> Regards, >>> >>> >>> >>> >>> >>> >>> >>> Alissa Cooper on behalf of the ICG >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> [1] http://mm.icann.org/pipermail/cwg-stewardship/2016- >>> April/004877.html >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Apr 30, 2016, at 8:16 AM, Mueller, Milton L < milton at gatech.edu > >>> wrote: >>> >>> >>> >>> >>> >>> >>> >>> Ok, I have had time to read the transcript. I am even more strongly >>> committed to developing a comment as ICG. >>> >>> >>> >>> >>> >>> >>> >>> Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that allows all >>> of the work that was done to more precisely define the mission statement >>> of ICANN in these bylaws ...to be completely contravened by whatever gets >>> written into the ICANN PTI contract Because what this is says is that no one >>> in the future will ever be able to challenge that contract on the basis that it >>> contravenes the mission.” >>> >>> >>> >>> >>> >>> >>> >>> [and, I might add, the RZM contract, and renewals of registry contracts]. >>> >>> >>> >>> >>> >>> >>> >>> The only answer I saw to this was that we don’t need to worry about it >>> because the PTI contract will be put up for public comment. >>> >>> >>> >>> >>> >>> >>> >>> Alissa also made the point: >>> >>> >>> >>> "this memo ... seems to imply that ... the most important thing out of all of >>> this is that ICANN can continue to perform the IANA function. And I think >>> what we all learned in (unintelligible) in terms of what the ICG proposal says >>> is that in fact that is not the most important thing. The most important >>> thing is that the IANA functions can continue to be performed by some >>> operator who’s capable of performing them according to the service level >>> agreements that the community ...has. And those two things are not the >>> same. And I certainly –I will put my IETF hat on here for a second and say >>> that I think from an IETF perspective the important thing is that a protocol >>> parameters functions can continue to be performed, not that they can only >>> continue to be performed by ICANN." >>> >>> >>> >>> >>> >>> >>> >>> I don't think this argument of Alissa was ever answered. It seems like there >>> could be ways of drafting these sections that do not commit us to a specific >>> contract but makes it clear that performance of the IANA functions is not >>> challengable as a mission violation so long as the community actually wants >>> ICANN to perform those functions. >>> >>> >>> >>> >>> >>> >>> >>> Indeed, I am having trouble understanding the threat that these sections >>> are supposed to avoid. >>> >>> >>> >>> >>> >>> >>> >>> However, the most dangerous mission-limitation-busting potential is in the >>> renewals section (F). This is problematic partly because the CCWG never >>> agreed to exempt renewals. We agreed to grandfather existing agreements, >>> for the sake of stability. But the assumption was that if anything in these >>> existing agreements contravened the new mission limitations, that they >>> COULD be challenged during a renewal process. A contract renewal with a >>> registry could include all kinds of regulatory measures that exceed the >>> mission, and if these measures are framed as a "renewal of an existing >>> agreement" then ICANN could in principle get away with anything. >>> >>> >>> >>> >>> >>> >>> >>> So I hope we are able to make it clear to ICANN and the CCWG that these >>> provisions need to be changed.. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> From: Alissa Cooper [ mailto:alissa at cooperw.in ] >>> Sent: Friday, April 29, 2016 3:00 PM >>> To: Mueller, Milton L < milton at gatech.edu > >>> Cc: Lynn St.Amour < Lynn at LStAmour.org >; IANA etc etcCoordination >>> Group < internal-cg at ianacg.org > >>> Subject: Re: [Internal-cg] bylaws feedback >>> >>> >>> >>> >>> >>> >>> >>> >>> For folks following this issue, it is definitely worth reading the transcript or >>> listening to the recording of the last CCWG call: >>> https://community.icann.org/pages/viewpage.action?pageId=58730392 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> The more that I have thought about this, it has become clear to me that the >>> core issue here is that there is a portion of bylaws section 1.1(d) that is not >>> called for either by our proposal or by the CCWG proposal, as Lynn says. >>> Had the content of 1.1(d)(ii)(B-E) been discussed as part of the transition >>> proposal development, I think the concerns being raised now would have >>> been raised then, and the whole community would have had time to sort >>> them out. (I note that there was an extended discussion about RA/RAA >>> agreements in the CCWG and that did result in text in its proposal in >>> paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not extend >>> to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been created >>> out of whole cloth by the bylaws drafting team, and that was not within >>> their remit in my opinion. The Bylaws are just supposed to implement the >>> proposals. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I think there are substantive issues too, but from an ICG perspective we >>> may or may not want to focus on those. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I would support sending a comment. We sent a message early on during the >>> bylaws drafting and received no response, and the call to discuss this didn’t >>> even occur until after the bylaws were put out for public comment. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Alissa >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Apr 29, 2016, at 11:17 AM, Mueller, Milton L < milton at gatech.edu > >>> wrote: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I support what you are saying. I take it you are not satisfied with the >>> lawyers' explanation? I was not able to attend the 0:400 call a few days ago >>> so was not able to question them about it or hear their answers. >>> >>> --MM >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Lynn St.Amour [ mailto:Lynn at LStAmour.org ] >>> Sent: Friday, April 29, 2016 1:55 PM >>> To: Alissa Cooper < alissa at cooperw.in >; Mueller, Milton L < >>> milton at gatech.edu >; IANA etc etcCoordination Group >> cg at ianacg.org > >>> Subject: Re: [Internal-cg] bylaws feedback >>> >>> Hi Alissa, Milton, all, >>> >>> I would like to come back to this subject. Specifically, I would like to >>> propose that the ICG send in a statement to the By-laws comment period. >>> >>> Alissa commented on a specific concern (see thread below) and I also >>> believe the ICG should be concerned about the overreach in the draft >>> bylaws. >>> >>> My main concerns are: >>> >>> - the fact that these draft by-laws, through the grand-fathering provisions, >>> allow external agreements to define ICANN's Mission which seems like a >>> bad idea for many reasons. Further, this contradicts the desires of the >>> community (or is a run around the community - intentional or not) who >>> worked hard to clarify and correctly state ICANN’s mission throughout the >>> IANA Transition process (paragraphs 140-144 of the CCWG-Accountability >>> proposal). >>> >>> - the ICG process was fashioned to ensure that the transition plans reflected >>> the consensus of the Internet community. And, it was to respect the roles >>> and responsibilities of the OCs in defining their own transition plans. The >>> ICG and the CCWG reports define those wishes, and any changes to the >>> bylaws were to be to implement those wishes, nothing more. Yet provisions >>> in sections >>> 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- >>> Accountability proposals, and so there has not been appropriate >>> community involvement or review for those changes. Note: these sections >>> affect much of the Internet community, as they apply to agreements >>> between ICANN and the ASO, NRO, IETF, Root Zone Maintainer, and PTI. >>> >>> For transparency: the IAB/IETF are also concerned about the overreach and >>> are drafting their own comments, and as an IAB appointee to the ICG, I am >>> part of that review as well. >>> >>> If there is support for the ICG sending in a comment, I would be happy to >>> work with Alissa and others to draft something for ICG review. >>> >>> Regards, >>> Lynn >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Apr 12, 2016, at 3:15 PM, Alissa Cooper < alissa at cooperw.in > wrote: >>> >>> From the minutes it looks like this was discussed on the CCWG call and >>> there >>> >>> >>> >>> will be follow-up. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Apr 12, 2016, at 8:39 AM, Mueller, Milton L < milton at gatech.edu > >>> >>> >>> >>> wrote: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I sent it yesterday but there has been no response at all. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Alissa Cooper [ mailto:alissa at cooperw.in ] >>> Sent: Monday, April 11, 2016 4:54 PM >>> To: Mueller, Milton L < milton at gatech.edu > >>> Cc: IANA etc etcCoordination Group < internal-cg at ianacg.org > >>> Subject: Re: [Internal-cg] bylaws feedback >>> >>> I think that would be fine. >>> >>> Thanks, >>> Alissa >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Apr 11, 2016, at 1:04 PM, Mueller, Milton L < milton at gatech.edu > >>> >>> >>> >>> wrote: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Alissa >>> If you don't mind I will just forward your message to the bylaws >>> and CWG >>> >>> >>> >>> lists. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> If there is some other way you want me to do this, please let me know. >>> >>> --MM >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Internal-cg [ mailto:internal-cg-bounces at ianacg.org ] On >>> Behalf Of Alissa Cooper >>> Sent: Monday, April 11, 2016 1:49 PM >>> To: IANA etc etcCoordination Group < internal-cg at ianacg.org > >>> Subject: [Internal-cg] bylaws feedback >>> >>> I have looked a bit at the draft bylaws and I’d like to ask >>> Kavouss and Milton to bring the following issue back to the bylaws >>> >>> >>> >>> drafting group: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Section 1.1(d)(ii) incorporates by reference a number of documents >>> external to the bylaws as a means to prevent challenges on the >>> basis that those documents conflict with or violate the bylaws. In >>> particular, bullet (D) applies this provision to "the IANA Naming >>> Function Contract between ICANN and PTI effective [October 1, 2016]." >>> >>> Given the ICG's historical encouragement of the community to meet >>> timelines necessary for a successful transition, I find this >>> provision to be extremely problematic. It incorporates a reference >>> to a document that does not exist yet and that is unlikely to be >>> completed by the time the bylaws are supposed to be done (early >>> June). In fact, it is not even clear at this point whether the new >>> ICANN affiliate to be setup will be name "PTI" or have some other >>> name. I don't understand how anyone can reason about whether >>> 1.1(d)(ii) is an acceptable bylaws provision if it references a >>> document that has not been written. (This also applies to (B) and >>> (C) since it could apply to future documents that haven’t been >>> written >>> yet.) >>> >>> Furthermore, I question whether it is a sound decision to >>> essentially allow for documents external to the bylaws to be able >>> to modify the bylaws (under (F)). This section would make more >>> sense if it was entirely internally specified, without the >>> references to external documents. At a minimum, I think we should >>> recommend that (D) be >>> >>> >>> >>> removed. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Thanks, >>> Alissa >>> _______________________________________________ >>> Internal-cg mailing list >>> Internal-cg at mm.ianacg.org >>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >>> >>> >>> _______________________________________________ >>> Internal-cg mailing list >>> Internal-cg at mm.ianacg.org >>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >>> >>> _______________________________________________ >>> Internal-cg mailing list >>> Internal-cg at mm.ianacg.org >>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >> _______________________________________________ >> Internal-cg mailing list >> Internal-cg at mm.ianacg.org >> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org > > _______________________________________________ > Internal-cg mailing list > Internal-cg at mm.ianacg.org > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org _______________________________________________ Internal-cg mailing list Internal-cg at mm.ianacg.org http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org From joseph.alhadeff at oracle.com Thu May 12 14:16:43 2016 From: joseph.alhadeff at oracle.com (Joseph Alhadeff) Date: Thu, 12 May 2016 10:16:43 -0400 Subject: [Internal-cg] bylaws feedback In-Reply-To: <1801150400.92.1463037684894.JavaMail.jjs-mac-2@MacBook-Air-de-Jean-Jacques-2.local> References: <1801150400.92.1463037684894.JavaMail.jjs-mac-2@MacBook-Air-de-Jean-Jacques-2.local> Message-ID: <5734904B.50103@oracle.com> agree. On 5/12/2016 3:21 AM, Subrenat, Jean-Jacques wrote: > Thank you Alissa. I fully support this statement. > Jean-Jacques. > > > > > > > ----- Mail original ----- > De: "Alissa Cooper" > À: "Kavouss Arasteh" > Cc: "Lynn St.Amour" , "Milton L Mueller" , "IANA etc etcCoordination Group" > Envoyé: Mercredi 11 Mai 2016 21:11:25 > Objet: Re: [Internal-cg] bylaws feedback > > I’d like us to close out on this. If anyone objects to us submitting the text below as a public comment on the draft bylaws, please say so by Friday, May 13 at 23:59. If there are no objections, I’ll submit it. > > --- > > The ICG appreciates the opportunity to comment on the draft ICANN Bylaws. > > The ICG previously communicated concerns about Section 1.1(d)(ii) to the Bylaws drafting group [1]. However, these concerns were not addressed in the draft Bylaws that were posted for public comment. > > Section 1.1(d) "grandfathers" a number of agreements into the Bylaws in order to prevent parties from challenging those agreements on the basis that they violate the ICANN Mission statement. Under Section 1.1(d)(ii), (A) applies to RA/RAA agreements; (B)-(D) apply to agreements between ICANN and the NRO, ASO, IETF, RZM, and PTI; and (E) applies to ICANN's Five-Year Strategic Plan and Five-Year Operating Plan. (F) applies the grandfathering to renewals of the agreements appearing in (B)-(E). > > The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. > > Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). > > The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. > > Regards, > > Alissa Cooper on behalf of the ICG > > > >> On May 6, 2016, at 2:59 AM, Kavouss Arasteh wrote: >> >> Jean Jaques >> Tks >> This is what I and you pushed since long time but have not yet been heard >> Kavousd >> >> Sent from my iPhone >> >>> On 5 May 2016, at 09:43, Narelle Clark wrote: >>> >>> Jean-Jacques has the rationale exactly. >>> >>> +1 >>> >>> Narelle >>> >>> >>>> -----Original Message----- >>>> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of >>>> Subrenat, Jean-Jacques >>>> Sent: Wednesday, 4 May 2016 4:28 PM >>>> To: Martin Boyle >>>> Cc: Lynn St.Amour; Milton L Mueller; IANA etc etcCoordination Group >>>> Subject: Re: [Internal-cg] bylaws feedback >>>> >>>> Hello Alissa & All, >>>> >>>> I support the draft as it now stands, in order to >>>> - warn against any initiative or mechanism which would endanger the >>>> Transition proposal before it has even been thoroughly vetted in >>>> Washington, >>>> - underline the risk of the ICANN Mission being susceptible to modification >>>> by external texts or undertakings, some of which are not yet in existence, >>>> - demand the withdrawal of Sections 1.1(d)(ii)(B)-(E), and the modification >>>> of Section 1.1(d)(ii)(F) so as to apply only to Section 1.1(d)(ii)(A). >>>> >>>> Best regards, >>>> Jean-Jacques. >>>> >>>> >>>> >>>> >>>> ----- Mail original ----- >>>> De: "Martin Boyle" >>>> À: "Alissa Cooper" , "Milton L Mueller" >>>> >>>> Cc: "Lynn St.Amour" , "IANA etc etcCoordination >>>> Group" >>>> Envoyé: Mercredi 4 Mai 2016 00:15:40 >>>> Objet: Re: [Internal-cg] bylaws feedback >>>> >>>> >>>> >>>> >>>> >>>> Hi Alissa, all, >>>> >>>> >>>> >>>> I agree with you, Alissa. This sort of detail does seem to me to go well >>>> beyond the remit of the ICG and we should certainly not be seeking to >>>> upset areas already agreed in the CCWG-Accountability process. >>>> >>>> >>>> >>>> For the rest of this, I am afraid I have not been following the CCWG process >>>> carefully enough to have a view of where the text bylaw drafting goes >>>> beyond the consensus of the proposal. I’ll try to look at it tomorrow, but on >>>> my cursory reading of the arguments below, this does look like a legitimate >>>> input from the ICG. >>>> >>>> >>>> >>>> Hope this helps >>>> >>>> >>>> >>>> Martin >>>> >>>> >>>> >>>> >>>> >>>> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of >>>> Alissa Cooper >>>> Sent: 03 May 2016 22:10 >>>> To: Mueller, Milton L >>>> Cc: Lynn St.Amour ; IANA etc etcCoordination Group >>>> >>>> Subject: Re: [Internal-cg] bylaws feedback >>>> >>>> >>>> >>>> >>>> I don’t have an opinion about the substance of the RA/RAA renewals, but I >>>> don’t think they are within the scope of what the ICG should comment on. >>>> >>>> >>>> >>>> >>>> >>>> The renewal of RA and RAA agreements were discussed on today’s CCWG >>>> call (as well as on several previous CCWG calls and the CCWG mailing list). It >>>> appears that the CCWG will be commenting on these renewals in its own >>>> comments about the Bylaws, and will be supporting the existing language in >>>> (F) as it applies to the RA and RAA agreements. Considering that the CCWG >>>> appears to have discussed this topic at great length and has consensus on >>>> it, I don’t think the same argument we are making about (B)-(E) applies to >>>> the RA/RAA renewals. >>>> >>>> >>>> >>>> >>>> >>>> The CCWG is planning to submit its comments by May 10, so there should >>>> be more clarity about exactly what they intend to say soon. >>>> >>>> >>>> >>>> >>>> >>>> Alissa >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On May 3, 2016, at 9:59 AM, Mueller, Milton L < milton at gatech.edu > >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> (F) applies the grandfathering to renewals of the agreements appearing in >>>> (B)-(D). >>>> >>>> >>>> >>>> >>>> >>>> MM: not correct: (F) applies the grandfathering to renewals of A – D. It >>>> reads: >>>> >>>> >>>> >>>> >>>> >>>> “(F) any renewals of agreements described in subsections (A)-(D) pursuant >>>> to their terms and conditions for renewal.” >>>> >>>> >>>> >>>> >>>> >>>> As I said in my initial comment, renewals of RA and RAA agreements are the >>>> most susceptible to bypassing mission limitations, because ICANN has the >>>> most expansive powers over names and the names community, unlike >>>> numbers and protocols, has not created a viable mechanism for changing >>>> the IFO. >>>> >>>> >>>> >>>> >>>> >>>> Picture this scenario: ICANN adds a highly regulatory requirement to the >>>> .com contract renewal; requiring it to pre-screen content in all .com second- >>>> level registrations. We might say, “this obviously violates the prohibition of >>>> content regulation in the mission statement,” but ICANN legal replies: “oh >>>> no, this is a renewal of the com agreement and therefore it is exempt from >>>> any such challenge.” >>>> >>>> >>>> >>>> >>>> >>>> If someone can show me that I am wrong legally about this possibility I’d be >>>> happy to drop it. But I haven’t seen any convincing arguments as to how >>>> this would not be possible. >>>> >>>> >>>> >>>> >>>> >>>> Therefore it would be extremely difficult for me to sign on to this statement >>>> if it does not mention the RA/RAA renewals problem and I frankly think >>>> we’d be missing the boat in a big way. >>>> >>>> >>>> >>>> >>>> >>>> --MM >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> The ICG process was fashioned to ensure that the transition plans reflected >>>> the consensus of the Internet community and allowed the operational >>>> communities to define their own transition plans. The ICG and the CCWG >>>> proposals define those wishes, and any changes to the Bylaws were to be to >>>> implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are >>>> outside the scope of both the ICG and the CCWG proposals. Unlike Section >>>> 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is >>>> documented in paragraph 147 of the CCWG proposal, the substance of (B)- >>>> (E) have not enjoyed appropriate community involvement or review. These >>>> sections affect much of the Internet community since they apply to >>>> agreements with a variety of external parties, including all of the >>>> operational communities. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Because several of the referenced agreements have not yet been written >>>> and most have not yet been agreed to by the relevant parties, the draft >>>> Bylaws essentially allow these external agreements to define ICANN's >>>> Mission. This seems like a bad idea for many reasons, not the least of which >>>> is that it creates the possibility for the agreements to contradict or >>>> circumvent the desires of the community who worked hard to clarify and >>>> correctly state ICANN’s Mission throughout the IANA stewardship >>>> transition process (see paragraphs 140-147 of the CCWG proposal). >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> The ICG believes that in order for the Bylaws to be considered consistent >>>> with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and >>>> Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). >>>> This assumes that (F) is indeed called for by paragraph 147 of the CCWG >>>> proposal, which we leave for the CCWG to judge. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Regards, >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Alissa Cooper on behalf of the ICG >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> [1] http://mm.icann.org/pipermail/cwg-stewardship/2016- >>>> April/004877.html >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Apr 30, 2016, at 8:16 AM, Mueller, Milton L < milton at gatech.edu > >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Ok, I have had time to read the transcript. I am even more strongly >>>> committed to developing a comment as ICG. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that allows all >>>> of the work that was done to more precisely define the mission statement >>>> of ICANN in these bylaws ...to be completely contravened by whatever gets >>>> written into the ICANN PTI contract Because what this is says is that no one >>>> in the future will ever be able to challenge that contract on the basis that it >>>> contravenes the mission.” >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> [and, I might add, the RZM contract, and renewals of registry contracts]. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> The only answer I saw to this was that we don’t need to worry about it >>>> because the PTI contract will be put up for public comment. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Alissa also made the point: >>>> >>>> >>>> >>>> "this memo ... seems to imply that ... the most important thing out of all of >>>> this is that ICANN can continue to perform the IANA function. And I think >>>> what we all learned in (unintelligible) in terms of what the ICG proposal says >>>> is that in fact that is not the most important thing. The most important >>>> thing is that the IANA functions can continue to be performed by some >>>> operator who’s capable of performing them according to the service level >>>> agreements that the community ...has. And those two things are not the >>>> same. And I certainly –I will put my IETF hat on here for a second and say >>>> that I think from an IETF perspective the important thing is that a protocol >>>> parameters functions can continue to be performed, not that they can only >>>> continue to be performed by ICANN." >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> I don't think this argument of Alissa was ever answered. It seems like there >>>> could be ways of drafting these sections that do not commit us to a specific >>>> contract but makes it clear that performance of the IANA functions is not >>>> challengable as a mission violation so long as the community actually wants >>>> ICANN to perform those functions. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Indeed, I am having trouble understanding the threat that these sections >>>> are supposed to avoid. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> However, the most dangerous mission-limitation-busting potential is in the >>>> renewals section (F). This is problematic partly because the CCWG never >>>> agreed to exempt renewals. We agreed to grandfather existing agreements, >>>> for the sake of stability. But the assumption was that if anything in these >>>> existing agreements contravened the new mission limitations, that they >>>> COULD be challenged during a renewal process. A contract renewal with a >>>> registry could include all kinds of regulatory measures that exceed the >>>> mission, and if these measures are framed as a "renewal of an existing >>>> agreement" then ICANN could in principle get away with anything. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> So I hope we are able to make it clear to ICANN and the CCWG that these >>>> provisions need to be changed.. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> From: Alissa Cooper [ mailto:alissa at cooperw.in ] >>>> Sent: Friday, April 29, 2016 3:00 PM >>>> To: Mueller, Milton L < milton at gatech.edu > >>>> Cc: Lynn St.Amour < Lynn at LStAmour.org >; IANA etc etcCoordination >>>> Group < internal-cg at ianacg.org > >>>> Subject: Re: [Internal-cg] bylaws feedback >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> For folks following this issue, it is definitely worth reading the transcript or >>>> listening to the recording of the last CCWG call: >>>> https://community.icann.org/pages/viewpage.action?pageId=58730392 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> The more that I have thought about this, it has become clear to me that the >>>> core issue here is that there is a portion of bylaws section 1.1(d) that is not >>>> called for either by our proposal or by the CCWG proposal, as Lynn says. >>>> Had the content of 1.1(d)(ii)(B-E) been discussed as part of the transition >>>> proposal development, I think the concerns being raised now would have >>>> been raised then, and the whole community would have had time to sort >>>> them out. (I note that there was an extended discussion about RA/RAA >>>> agreements in the CCWG and that did result in text in its proposal in >>>> paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not extend >>>> to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been created >>>> out of whole cloth by the bylaws drafting team, and that was not within >>>> their remit in my opinion. The Bylaws are just supposed to implement the >>>> proposals. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> I think there are substantive issues too, but from an ICG perspective we >>>> may or may not want to focus on those. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> I would support sending a comment. We sent a message early on during the >>>> bylaws drafting and received no response, and the call to discuss this didn’t >>>> even occur until after the bylaws were put out for public comment. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Alissa >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Apr 29, 2016, at 11:17 AM, Mueller, Milton L < milton at gatech.edu > >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> I support what you are saying. I take it you are not satisfied with the >>>> lawyers' explanation? I was not able to attend the 0:400 call a few days ago >>>> so was not able to question them about it or hear their answers. >>>> >>>> --MM >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Lynn St.Amour [ mailto:Lynn at LStAmour.org ] >>>> Sent: Friday, April 29, 2016 1:55 PM >>>> To: Alissa Cooper < alissa at cooperw.in >; Mueller, Milton L < >>>> milton at gatech.edu >; IANA etc etcCoordination Group >>> cg at ianacg.org > >>>> Subject: Re: [Internal-cg] bylaws feedback >>>> >>>> Hi Alissa, Milton, all, >>>> >>>> I would like to come back to this subject. Specifically, I would like to >>>> propose that the ICG send in a statement to the By-laws comment period. >>>> >>>> Alissa commented on a specific concern (see thread below) and I also >>>> believe the ICG should be concerned about the overreach in the draft >>>> bylaws. >>>> >>>> My main concerns are: >>>> >>>> - the fact that these draft by-laws, through the grand-fathering provisions, >>>> allow external agreements to define ICANN's Mission which seems like a >>>> bad idea for many reasons. Further, this contradicts the desires of the >>>> community (or is a run around the community - intentional or not) who >>>> worked hard to clarify and correctly state ICANN’s mission throughout the >>>> IANA Transition process (paragraphs 140-144 of the CCWG-Accountability >>>> proposal). >>>> >>>> - the ICG process was fashioned to ensure that the transition plans reflected >>>> the consensus of the Internet community. And, it was to respect the roles >>>> and responsibilities of the OCs in defining their own transition plans. The >>>> ICG and the CCWG reports define those wishes, and any changes to the >>>> bylaws were to be to implement those wishes, nothing more. Yet provisions >>>> in sections >>>> 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- >>>> Accountability proposals, and so there has not been appropriate >>>> community involvement or review for those changes. Note: these sections >>>> affect much of the Internet community, as they apply to agreements >>>> between ICANN and the ASO, NRO, IETF, Root Zone Maintainer, and PTI. >>>> >>>> For transparency: the IAB/IETF are also concerned about the overreach and >>>> are drafting their own comments, and as an IAB appointee to the ICG, I am >>>> part of that review as well. >>>> >>>> If there is support for the ICG sending in a comment, I would be happy to >>>> work with Alissa and others to draft something for ICG review. >>>> >>>> Regards, >>>> Lynn >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Apr 12, 2016, at 3:15 PM, Alissa Cooper < alissa at cooperw.in > wrote: >>>> >>>> From the minutes it looks like this was discussed on the CCWG call and >>>> there >>>> >>>> >>>> >>>> will be follow-up. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Apr 12, 2016, at 8:39 AM, Mueller, Milton L < milton at gatech.edu > >>>> >>>> >>>> >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> I sent it yesterday but there has been no response at all. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Alissa Cooper [ mailto:alissa at cooperw.in ] >>>> Sent: Monday, April 11, 2016 4:54 PM >>>> To: Mueller, Milton L < milton at gatech.edu > >>>> Cc: IANA etc etcCoordination Group < internal-cg at ianacg.org > >>>> Subject: Re: [Internal-cg] bylaws feedback >>>> >>>> I think that would be fine. >>>> >>>> Thanks, >>>> Alissa >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Apr 11, 2016, at 1:04 PM, Mueller, Milton L < milton at gatech.edu > >>>> >>>> >>>> >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Alissa >>>> If you don't mind I will just forward your message to the bylaws >>>> and CWG >>>> >>>> >>>> >>>> lists. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> If there is some other way you want me to do this, please let me know. >>>> >>>> --MM >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Internal-cg [ mailto:internal-cg-bounces at ianacg.org ] On >>>> Behalf Of Alissa Cooper >>>> Sent: Monday, April 11, 2016 1:49 PM >>>> To: IANA etc etcCoordination Group < internal-cg at ianacg.org > >>>> Subject: [Internal-cg] bylaws feedback >>>> >>>> I have looked a bit at the draft bylaws and I’d like to ask >>>> Kavouss and Milton to bring the following issue back to the bylaws >>>> >>>> >>>> >>>> drafting group: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Section 1.1(d)(ii) incorporates by reference a number of documents >>>> external to the bylaws as a means to prevent challenges on the >>>> basis that those documents conflict with or violate the bylaws. In >>>> particular, bullet (D) applies this provision to "the IANA Naming >>>> Function Contract between ICANN and PTI effective [October 1, 2016]." >>>> >>>> Given the ICG's historical encouragement of the community to meet >>>> timelines necessary for a successful transition, I find this >>>> provision to be extremely problematic. It incorporates a reference >>>> to a document that does not exist yet and that is unlikely to be >>>> completed by the time the bylaws are supposed to be done (early >>>> June). In fact, it is not even clear at this point whether the new >>>> ICANN affiliate to be setup will be name "PTI" or have some other >>>> name. I don't understand how anyone can reason about whether >>>> 1.1(d)(ii) is an acceptable bylaws provision if it references a >>>> document that has not been written. (This also applies to (B) and >>>> (C) since it could apply to future documents that haven’t been >>>> written >>>> yet.) >>>> >>>> Furthermore, I question whether it is a sound decision to >>>> essentially allow for documents external to the bylaws to be able >>>> to modify the bylaws (under (F)). This section would make more >>>> sense if it was entirely internally specified, without the >>>> references to external documents. At a minimum, I think we should >>>> recommend that (D) be >>>> >>>> >>>> >>>> removed. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Thanks, >>>> Alissa >>>> _______________________________________________ >>>> Internal-cg mailing list >>>> Internal-cg at mm.ianacg.org >>>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >>>> >>>> >>>> _______________________________________________ >>>> Internal-cg mailing list >>>> Internal-cg at mm.ianacg.org >>>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >>>> >>>> _______________________________________________ >>>> Internal-cg mailing list >>>> Internal-cg at mm.ianacg.org >>>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >>> _______________________________________________ >>> Internal-cg mailing list >>> Internal-cg at mm.ianacg.org >>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >> _______________________________________________ >> Internal-cg mailing list >> Internal-cg at mm.ianacg.org >> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org > > _______________________________________________ > Internal-cg mailing list > Internal-cg at mm.ianacg.org > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org > > _______________________________________________ > Internal-cg mailing list > Internal-cg at mm.ianacg.org > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org From wolf-ulrich.knoben at t-online.de Thu May 12 20:31:02 2016 From: wolf-ulrich.knoben at t-online.de (WUKnoben) Date: Thu, 12 May 2016 22:31:02 +0200 Subject: [Internal-cg] bylaws feedback In-Reply-To: <9B260ABE-EA98-4DD3-B8A5-2510C600CFAF@cooperw.in> References: <142976331.139.1462343299764.JavaMail.jjs-mac-2@macbook-air-de-jean-jacques-2.home><7146C0FDA8771A43BEB20E18700C2E4F0181AF71AF3A@ACCAN01.accan.local> <9B260ABE-EA98-4DD3-B8A5-2510C600CFAF@cooperw.in> Message-ID: I agree. Best regards Wolf-Ulrich -----Ursprüngliche Nachricht----- From: Alissa Cooper Sent: Wednesday, May 11, 2016 9:11 PM To: Kavouss Arasteh Cc: Lynn St.Amour ; Milton L Mueller ; IANA etc etcCoordination Group Subject: Re: [Internal-cg] bylaws feedback I’d like us to close out on this. If anyone objects to us submitting the text below as a public comment on the draft bylaws, please say so by Friday, May 13 at 23:59. If there are no objections, I’ll submit it. --- The ICG appreciates the opportunity to comment on the draft ICANN Bylaws. The ICG previously communicated concerns about Section 1.1(d)(ii) to the Bylaws drafting group [1]. However, these concerns were not addressed in the draft Bylaws that were posted for public comment. Section 1.1(d) "grandfathers" a number of agreements into the Bylaws in order to prevent parties from challenging those agreements on the basis that they violate the ICANN Mission statement. Under Section 1.1(d)(ii), (A) applies to RA/RAA agreements; (B)-(D) apply to agreements between ICANN and the NRO, ASO, IETF, RZM, and PTI; and (E) applies to ICANN's Five-Year Strategic Plan and Five-Year Operating Plan. (F) applies the grandfathering to renewals of the agreements appearing in (B)-(E). The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. Regards, Alissa Cooper on behalf of the ICG > On May 6, 2016, at 2:59 AM, Kavouss Arasteh > wrote: > > Jean Jaques > Tks > This is what I and you pushed since long time but have not yet been heard > Kavousd > > Sent from my iPhone > >> On 5 May 2016, at 09:43, Narelle Clark >> wrote: >> >> Jean-Jacques has the rationale exactly. >> >> +1 >> >> Narelle >> >> >>> -----Original Message----- >>> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of >>> Subrenat, Jean-Jacques >>> Sent: Wednesday, 4 May 2016 4:28 PM >>> To: Martin Boyle >>> Cc: Lynn St.Amour; Milton L Mueller; IANA etc etcCoordination Group >>> Subject: Re: [Internal-cg] bylaws feedback >>> >>> Hello Alissa & All, >>> >>> I support the draft as it now stands, in order to >>> - warn against any initiative or mechanism which would endanger the >>> Transition proposal before it has even been thoroughly vetted in >>> Washington, >>> - underline the risk of the ICANN Mission being susceptible to >>> modification >>> by external texts or undertakings, some of which are not yet in >>> existence, >>> - demand the withdrawal of Sections 1.1(d)(ii)(B)-(E), and the >>> modification >>> of Section 1.1(d)(ii)(F) so as to apply only to Section 1.1(d)(ii)(A). >>> >>> Best regards, >>> Jean-Jacques. >>> >>> >>> >>> >>> ----- Mail original ----- >>> De: "Martin Boyle" >>> À: "Alissa Cooper" , "Milton L Mueller" >>> >>> Cc: "Lynn St.Amour" , "IANA etc etcCoordination >>> Group" >>> Envoyé: Mercredi 4 Mai 2016 00:15:40 >>> Objet: Re: [Internal-cg] bylaws feedback >>> >>> >>> >>> >>> >>> Hi Alissa, all, >>> >>> >>> >>> I agree with you, Alissa. This sort of detail does seem to me to go well >>> beyond the remit of the ICG and we should certainly not be seeking to >>> upset areas already agreed in the CCWG-Accountability process. >>> >>> >>> >>> For the rest of this, I am afraid I have not been following the CCWG >>> process >>> carefully enough to have a view of where the text bylaw drafting goes >>> beyond the consensus of the proposal. I’ll try to look at it tomorrow, >>> but on >>> my cursory reading of the arguments below, this does look like a >>> legitimate >>> input from the ICG. >>> >>> >>> >>> Hope this helps >>> >>> >>> >>> Martin >>> >>> >>> >>> >>> >>> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of >>> Alissa Cooper >>> Sent: 03 May 2016 22:10 >>> To: Mueller, Milton L >>> Cc: Lynn St.Amour ; IANA etc etcCoordination Group >>> >>> Subject: Re: [Internal-cg] bylaws feedback >>> >>> >>> >>> >>> I don’t have an opinion about the substance of the RA/RAA renewals, but >>> I >>> don’t think they are within the scope of what the ICG should comment on. >>> >>> >>> >>> >>> >>> The renewal of RA and RAA agreements were discussed on today’s CCWG >>> call (as well as on several previous CCWG calls and the CCWG mailing >>> list). It >>> appears that the CCWG will be commenting on these renewals in its own >>> comments about the Bylaws, and will be supporting the existing language >>> in >>> (F) as it applies to the RA and RAA agreements. Considering that the >>> CCWG >>> appears to have discussed this topic at great length and has consensus >>> on >>> it, I don’t think the same argument we are making about (B)-(E) applies >>> to >>> the RA/RAA renewals. >>> >>> >>> >>> >>> >>> The CCWG is planning to submit its comments by May 10, so there should >>> be more clarity about exactly what they intend to say soon. >>> >>> >>> >>> >>> >>> Alissa >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On May 3, 2016, at 9:59 AM, Mueller, Milton L < milton at gatech.edu > >>> wrote: >>> >>> >>> >>> >>> >>> (F) applies the grandfathering to renewals of the agreements appearing >>> in >>> (B)-(D). >>> >>> >>> >>> >>> >>> MM: not correct: (F) applies the grandfathering to renewals of A – D. It >>> reads: >>> >>> >>> >>> >>> >>> “(F) any renewals of agreements described in subsections (A)-(D) >>> pursuant >>> to their terms and conditions for renewal.” >>> >>> >>> >>> >>> >>> As I said in my initial comment, renewals of RA and RAA agreements are >>> the >>> most susceptible to bypassing mission limitations, because ICANN has the >>> most expansive powers over names and the names community, unlike >>> numbers and protocols, has not created a viable mechanism for changing >>> the IFO. >>> >>> >>> >>> >>> >>> Picture this scenario: ICANN adds a highly regulatory requirement to the >>> .com contract renewal; requiring it to pre-screen content in all .com >>> second- >>> level registrations. We might say, “this obviously violates the >>> prohibition of >>> content regulation in the mission statement,” but ICANN legal replies: >>> “oh >>> no, this is a renewal of the com agreement and therefore it is exempt >>> from >>> any such challenge.” >>> >>> >>> >>> >>> >>> If someone can show me that I am wrong legally about this possibility I’d >>> be >>> happy to drop it. But I haven’t seen any convincing arguments as to how >>> this would not be possible. >>> >>> >>> >>> >>> >>> Therefore it would be extremely difficult for me to sign on to this >>> statement >>> if it does not mention the RA/RAA renewals problem and I frankly think >>> we’d be missing the boat in a big way. >>> >>> >>> >>> >>> >>> --MM >>> >>> >>> >>> >>> >>> >>> >>> The ICG process was fashioned to ensure that the transition plans >>> reflected >>> the consensus of the Internet community and allowed the operational >>> communities to define their own transition plans. The ICG and the CCWG >>> proposals define those wishes, and any changes to the Bylaws were to be >>> to >>> implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are >>> outside the scope of both the ICG and the CCWG proposals. Unlike Section >>> 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is >>> documented in paragraph 147 of the CCWG proposal, the substance of (B)- >>> (E) have not enjoyed appropriate community involvement or review. These >>> sections affect much of the Internet community since they apply to >>> agreements with a variety of external parties, including all of the >>> operational communities. >>> >>> >>> >>> >>> >>> >>> >>> Because several of the referenced agreements have not yet been written >>> and most have not yet been agreed to by the relevant parties, the draft >>> Bylaws essentially allow these external agreements to define ICANN's >>> Mission. This seems like a bad idea for many reasons, not the least of >>> which >>> is that it creates the possibility for the agreements to contradict or >>> circumvent the desires of the community who worked hard to clarify and >>> correctly state ICANN’s Mission throughout the IANA stewardship >>> transition process (see paragraphs 140-147 of the CCWG proposal). >>> >>> >>> >>> >>> >>> >>> >>> The ICG believes that in order for the Bylaws to be considered >>> consistent >>> with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be >>> removed, and >>> Section 1.1(d)(ii)(F) needs to be edited to apply only to Section >>> 1.1(d)(ii)(A). >>> This assumes that (F) is indeed called for by paragraph 147 of the CCWG >>> proposal, which we leave for the CCWG to judge. >>> >>> >>> >>> >>> >>> >>> >>> Regards, >>> >>> >>> >>> >>> >>> >>> >>> Alissa Cooper on behalf of the ICG >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> [1] http://mm.icann.org/pipermail/cwg-stewardship/2016- >>> April/004877.html >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Apr 30, 2016, at 8:16 AM, Mueller, Milton L < milton at gatech.edu > >>> wrote: >>> >>> >>> >>> >>> >>> >>> >>> Ok, I have had time to read the transcript. I am even more strongly >>> committed to developing a comment as ICG. >>> >>> >>> >>> >>> >>> >>> >>> Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that >>> allows all >>> of the work that was done to more precisely define the mission statement >>> of ICANN in these bylaws ...to be completely contravened by whatever >>> gets >>> written into the ICANN PTI contract Because what this is says is that no >>> one >>> in the future will ever be able to challenge that contract on the basis >>> that it >>> contravenes the mission.” >>> >>> >>> >>> >>> >>> >>> >>> [and, I might add, the RZM contract, and renewals of registry >>> contracts]. >>> >>> >>> >>> >>> >>> >>> >>> The only answer I saw to this was that we don’t need to worry about it >>> because the PTI contract will be put up for public comment. >>> >>> >>> >>> >>> >>> >>> >>> Alissa also made the point: >>> >>> >>> >>> "this memo ... seems to imply that ... the most important thing out of >>> all of >>> this is that ICANN can continue to perform the IANA function. And I >>> think >>> what we all learned in (unintelligible) in terms of what the ICG >>> proposal says >>> is that in fact that is not the most important thing. The most important >>> thing is that the IANA functions can continue to be performed by some >>> operator who’s capable of performing them according to the service level >>> agreements that the community ...has. And those two things are not the >>> same. And I certainly –I will put my IETF hat on here for a second and >>> say >>> that I think from an IETF perspective the important thing is that a >>> protocol >>> parameters functions can continue to be performed, not that they can >>> only >>> continue to be performed by ICANN." >>> >>> >>> >>> >>> >>> >>> >>> I don't think this argument of Alissa was ever answered. It seems like >>> there >>> could be ways of drafting these sections that do not commit us to a >>> specific >>> contract but makes it clear that performance of the IANA functions is >>> not >>> challengable as a mission violation so long as the community actually >>> wants >>> ICANN to perform those functions. >>> >>> >>> >>> >>> >>> >>> >>> Indeed, I am having trouble understanding the threat that these sections >>> are supposed to avoid. >>> >>> >>> >>> >>> >>> >>> >>> However, the most dangerous mission-limitation-busting potential is in >>> the >>> renewals section (F). This is problematic partly because the CCWG never >>> agreed to exempt renewals. We agreed to grandfather existing agreements, >>> for the sake of stability. But the assumption was that if anything in >>> these >>> existing agreements contravened the new mission limitations, that they >>> COULD be challenged during a renewal process. A contract renewal with a >>> registry could include all kinds of regulatory measures that exceed the >>> mission, and if these measures are framed as a "renewal of an existing >>> agreement" then ICANN could in principle get away with anything. >>> >>> >>> >>> >>> >>> >>> >>> So I hope we are able to make it clear to ICANN and the CCWG that these >>> provisions need to be changed.. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> From: Alissa Cooper [ mailto:alissa at cooperw.in ] >>> Sent: Friday, April 29, 2016 3:00 PM >>> To: Mueller, Milton L < milton at gatech.edu > >>> Cc: Lynn St.Amour < Lynn at LStAmour.org >; IANA etc etcCoordination >>> Group < internal-cg at ianacg.org > >>> Subject: Re: [Internal-cg] bylaws feedback >>> >>> >>> >>> >>> >>> >>> >>> >>> For folks following this issue, it is definitely worth reading the >>> transcript or >>> listening to the recording of the last CCWG call: >>> https://community.icann.org/pages/viewpage.action?pageId=58730392 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> The more that I have thought about this, it has become clear to me that >>> the >>> core issue here is that there is a portion of bylaws section 1.1(d) that >>> is not >>> called for either by our proposal or by the CCWG proposal, as Lynn says. >>> Had the content of 1.1(d)(ii)(B-E) been discussed as part of the >>> transition >>> proposal development, I think the concerns being raised now would have >>> been raised then, and the whole community would have had time to sort >>> them out. (I note that there was an extended discussion about RA/RAA >>> agreements in the CCWG and that did result in text in its proposal in >>> paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not >>> extend >>> to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been >>> created >>> out of whole cloth by the bylaws drafting team, and that was not within >>> their remit in my opinion. The Bylaws are just supposed to implement the >>> proposals. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I think there are substantive issues too, but from an ICG perspective we >>> may or may not want to focus on those. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I would support sending a comment. We sent a message early on during the >>> bylaws drafting and received no response, and the call to discuss this >>> didn’t >>> even occur until after the bylaws were put out for public comment. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Alissa >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Apr 29, 2016, at 11:17 AM, Mueller, Milton L < milton at gatech.edu > >>> wrote: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I support what you are saying. I take it you are not satisfied with the >>> lawyers' explanation? I was not able to attend the 0:400 call a few days >>> ago >>> so was not able to question them about it or hear their answers. >>> >>> --MM >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Lynn St.Amour [ mailto:Lynn at LStAmour.org ] >>> Sent: Friday, April 29, 2016 1:55 PM >>> To: Alissa Cooper < alissa at cooperw.in >; Mueller, Milton L < >>> milton at gatech.edu >; IANA etc etcCoordination Group >> cg at ianacg.org > >>> Subject: Re: [Internal-cg] bylaws feedback >>> >>> Hi Alissa, Milton, all, >>> >>> I would like to come back to this subject. Specifically, I would like to >>> propose that the ICG send in a statement to the By-laws comment period. >>> >>> Alissa commented on a specific concern (see thread below) and I also >>> believe the ICG should be concerned about the overreach in the draft >>> bylaws. >>> >>> My main concerns are: >>> >>> - the fact that these draft by-laws, through the grand-fathering >>> provisions, >>> allow external agreements to define ICANN's Mission which seems like a >>> bad idea for many reasons. Further, this contradicts the desires of the >>> community (or is a run around the community - intentional or not) who >>> worked hard to clarify and correctly state ICANN’s mission throughout >>> the >>> IANA Transition process (paragraphs 140-144 of the CCWG-Accountability >>> proposal). >>> >>> - the ICG process was fashioned to ensure that the transition plans >>> reflected >>> the consensus of the Internet community. And, it was to respect the >>> roles >>> and responsibilities of the OCs in defining their own transition plans. >>> The >>> ICG and the CCWG reports define those wishes, and any changes to the >>> bylaws were to be to implement those wishes, nothing more. Yet >>> provisions >>> in sections >>> 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- >>> Accountability proposals, and so there has not been appropriate >>> community involvement or review for those changes. Note: these sections >>> affect much of the Internet community, as they apply to agreements >>> between ICANN and the ASO, NRO, IETF, Root Zone Maintainer, and PTI. >>> >>> For transparency: the IAB/IETF are also concerned about the overreach >>> and >>> are drafting their own comments, and as an IAB appointee to the ICG, I >>> am >>> part of that review as well. >>> >>> If there is support for the ICG sending in a comment, I would be happy >>> to >>> work with Alissa and others to draft something for ICG review. >>> >>> Regards, >>> Lynn >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Apr 12, 2016, at 3:15 PM, Alissa Cooper < alissa at cooperw.in > wrote: >>> >>> From the minutes it looks like this was discussed on the CCWG call and >>> there >>> >>> >>> >>> will be follow-up. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Apr 12, 2016, at 8:39 AM, Mueller, Milton L < milton at gatech.edu > >>> >>> >>> >>> wrote: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I sent it yesterday but there has been no response at all. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Alissa Cooper [ mailto:alissa at cooperw.in ] >>> Sent: Monday, April 11, 2016 4:54 PM >>> To: Mueller, Milton L < milton at gatech.edu > >>> Cc: IANA etc etcCoordination Group < internal-cg at ianacg.org > >>> Subject: Re: [Internal-cg] bylaws feedback >>> >>> I think that would be fine. >>> >>> Thanks, >>> Alissa >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Apr 11, 2016, at 1:04 PM, Mueller, Milton L < milton at gatech.edu > >>> >>> >>> >>> wrote: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Alissa >>> If you don't mind I will just forward your message to the bylaws >>> and CWG >>> >>> >>> >>> lists. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> If there is some other way you want me to do this, please let me know. >>> >>> --MM >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Internal-cg [ mailto:internal-cg-bounces at ianacg.org ] On >>> Behalf Of Alissa Cooper >>> Sent: Monday, April 11, 2016 1:49 PM >>> To: IANA etc etcCoordination Group < internal-cg at ianacg.org > >>> Subject: [Internal-cg] bylaws feedback >>> >>> I have looked a bit at the draft bylaws and I’d like to ask >>> Kavouss and Milton to bring the following issue back to the bylaws >>> >>> >>> >>> drafting group: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Section 1.1(d)(ii) incorporates by reference a number of documents >>> external to the bylaws as a means to prevent challenges on the >>> basis that those documents conflict with or violate the bylaws. In >>> particular, bullet (D) applies this provision to "the IANA Naming >>> Function Contract between ICANN and PTI effective [October 1, 2016]." >>> >>> Given the ICG's historical encouragement of the community to meet >>> timelines necessary for a successful transition, I find this >>> provision to be extremely problematic. It incorporates a reference >>> to a document that does not exist yet and that is unlikely to be >>> completed by the time the bylaws are supposed to be done (early >>> June). In fact, it is not even clear at this point whether the new >>> ICANN affiliate to be setup will be name "PTI" or have some other >>> name. I don't understand how anyone can reason about whether >>> 1.1(d)(ii) is an acceptable bylaws provision if it references a >>> document that has not been written. (This also applies to (B) and >>> (C) since it could apply to future documents that haven’t been >>> written >>> yet.) >>> >>> Furthermore, I question whether it is a sound decision to >>> essentially allow for documents external to the bylaws to be able >>> to modify the bylaws (under (F)). This section would make more >>> sense if it was entirely internally specified, without the >>> references to external documents. At a minimum, I think we should >>> recommend that (D) be >>> >>> >>> >>> removed. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Thanks, >>> Alissa >>> _______________________________________________ >>> Internal-cg mailing list >>> Internal-cg at mm.ianacg.org >>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >>> >>> >>> _______________________________________________ >>> Internal-cg mailing list >>> Internal-cg at mm.ianacg.org >>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >>> >>> _______________________________________________ >>> Internal-cg mailing list >>> Internal-cg at mm.ianacg.org >>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >> _______________________________________________ >> Internal-cg mailing list >> Internal-cg at mm.ianacg.org >> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org > > _______________________________________________ > Internal-cg mailing list > Internal-cg at mm.ianacg.org > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org _______________________________________________ Internal-cg mailing list Internal-cg at mm.ianacg.org http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org From housley at vigilsec.com Thu May 12 22:32:06 2016 From: housley at vigilsec.com (Russ Housley) Date: Thu, 12 May 2016 18:32:06 -0400 Subject: [Internal-cg] bylaws feedback In-Reply-To: <9B260ABE-EA98-4DD3-B8A5-2510C600CFAF@cooperw.in> References: <142976331.139.1462343299764.JavaMail.jjs-mac-2@macbook-air-de-jean-jacques-2.home><7146C0FDA8771A43BEB20E18700C2E4F0181AF71AF3A@ACCAN01.accan.local> <9B260ABE-EA98-4DD3-B8A5-2510C600CFAF@cooperw.in> Message-ID: Looks ready for sending to me. Russ -----Ursprüngliche Nachricht----- From: Alissa Cooper Sent: Wednesday, May 11, 2016 9:11 PM To: Kavouss Arasteh Cc: Lynn St.Amour ; Milton L Mueller ; IANA etc etcCoordination Group Subject: Re: [Internal-cg] bylaws feedback I’d like us to close out on this. If anyone objects to us submitting the text below as a public comment on the draft bylaws, please say so by Friday, May 13 at 23:59. If there are no objections, I’ll submit it. --- The ICG appreciates the opportunity to comment on the draft ICANN Bylaws. The ICG previously communicated concerns about Section 1.1(d)(ii) to the Bylaws drafting group [1]. However, these concerns were not addressed in the draft Bylaws that were posted for public comment. Section 1.1(d) "grandfathers" a number of agreements into the Bylaws in order to prevent parties from challenging those agreements on the basis that they violate the ICANN Mission statement. Under Section 1.1(d)(ii), (A) applies to RA/RAA agreements; (B)-(D) apply to agreements between ICANN and the NRO, ASO, IETF, RZM, and PTI; and (E) applies to ICANN's Five-Year Strategic Plan and Five-Year Operating Plan. (F) applies the grandfathering to renewals of the agreements appearing in (B)-(E). The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. Regards, Alissa Cooper on behalf of the ICG From mundy at tislabs.com Fri May 13 02:21:39 2016 From: mundy at tislabs.com (Russ Mundy) Date: Thu, 12 May 2016 22:21:39 -0400 Subject: [Internal-cg] bylaws feedback In-Reply-To: <9B260ABE-EA98-4DD3-B8A5-2510C600CFAF@cooperw.in> References: <142976331.139.1462343299764.JavaMail.jjs-mac-2@macbook-air-de-jean-jacques-2.home> <7146C0FDA8771A43BEB20E18700C2E4F0181AF71AF3A@ACCAN01.accan.local> <9B260ABE-EA98-4DD3-B8A5-2510C600CFAF@cooperw.in> Message-ID: Alissa, I agree - excellent points, please send. Russ M On May 11, 2016, at 3:11 PM, Alissa Cooper wrote: > I’d like us to close out on this. If anyone objects to us submitting the text below as a public comment on the draft bylaws, please say so by Friday, May 13 at 23:59. If there are no objections, I’ll submit it. > > --- > > The ICG appreciates the opportunity to comment on the draft ICANN Bylaws. > > The ICG previously communicated concerns about Section 1.1(d)(ii) to the Bylaws drafting group [1]. However, these concerns were not addressed in the draft Bylaws that were posted for public comment. > > Section 1.1(d) "grandfathers" a number of agreements into the Bylaws in order to prevent parties from challenging those agreements on the basis that they violate the ICANN Mission statement. Under Section 1.1(d)(ii), (A) applies to RA/RAA agreements; (B)-(D) apply to agreements between ICANN and the NRO, ASO, IETF, RZM, and PTI; and (E) applies to ICANN's Five-Year Strategic Plan and Five-Year Operating Plan. (F) applies the grandfathering to renewals of the agreements appearing in (B)-(E). > > The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. > > Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). > > The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. > > Regards, > > Alissa Cooper on behalf of the ICG > > > >> On May 6, 2016, at 2:59 AM, Kavouss Arasteh wrote: >> >> Jean Jaques >> Tks >> This is what I and you pushed since long time but have not yet been heard >> Kavousd >> >> Sent from my iPhone >> >>> On 5 May 2016, at 09:43, Narelle Clark wrote: >>> >>> Jean-Jacques has the rationale exactly. >>> >>> +1 >>> >>> Narelle >>> >>> >>>> -----Original Message----- >>>> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of >>>> Subrenat, Jean-Jacques >>>> Sent: Wednesday, 4 May 2016 4:28 PM >>>> To: Martin Boyle >>>> Cc: Lynn St.Amour; Milton L Mueller; IANA etc etcCoordination Group >>>> Subject: Re: [Internal-cg] bylaws feedback >>>> >>>> Hello Alissa & All, >>>> >>>> I support the draft as it now stands, in order to >>>> - warn against any initiative or mechanism which would endanger the >>>> Transition proposal before it has even been thoroughly vetted in >>>> Washington, >>>> - underline the risk of the ICANN Mission being susceptible to modification >>>> by external texts or undertakings, some of which are not yet in existence, >>>> - demand the withdrawal of Sections 1.1(d)(ii)(B)-(E), and the modification >>>> of Section 1.1(d)(ii)(F) so as to apply only to Section 1.1(d)(ii)(A). >>>> >>>> Best regards, >>>> Jean-Jacques. >>>> >>>> >>>> >>>> >>>> ----- Mail original ----- >>>> De: "Martin Boyle" >>>> À: "Alissa Cooper" , "Milton L Mueller" >>>> >>>> Cc: "Lynn St.Amour" , "IANA etc etcCoordination >>>> Group" >>>> Envoyé: Mercredi 4 Mai 2016 00:15:40 >>>> Objet: Re: [Internal-cg] bylaws feedback >>>> >>>> >>>> >>>> >>>> >>>> Hi Alissa, all, >>>> >>>> >>>> >>>> I agree with you, Alissa. This sort of detail does seem to me to go well >>>> beyond the remit of the ICG and we should certainly not be seeking to >>>> upset areas already agreed in the CCWG-Accountability process. >>>> >>>> >>>> >>>> For the rest of this, I am afraid I have not been following the CCWG process >>>> carefully enough to have a view of where the text bylaw drafting goes >>>> beyond the consensus of the proposal. I’ll try to look at it tomorrow, but on >>>> my cursory reading of the arguments below, this does look like a legitimate >>>> input from the ICG. >>>> >>>> >>>> >>>> Hope this helps >>>> >>>> >>>> >>>> Martin >>>> >>>> >>>> >>>> >>>> >>>> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of >>>> Alissa Cooper >>>> Sent: 03 May 2016 22:10 >>>> To: Mueller, Milton L >>>> Cc: Lynn St.Amour ; IANA etc etcCoordination Group >>>> >>>> Subject: Re: [Internal-cg] bylaws feedback >>>> >>>> >>>> >>>> >>>> I don’t have an opinion about the substance of the RA/RAA renewals, but I >>>> don’t think they are within the scope of what the ICG should comment on. >>>> >>>> >>>> >>>> >>>> >>>> The renewal of RA and RAA agreements were discussed on today’s CCWG >>>> call (as well as on several previous CCWG calls and the CCWG mailing list). It >>>> appears that the CCWG will be commenting on these renewals in its own >>>> comments about the Bylaws, and will be supporting the existing language in >>>> (F) as it applies to the RA and RAA agreements. Considering that the CCWG >>>> appears to have discussed this topic at great length and has consensus on >>>> it, I don’t think the same argument we are making about (B)-(E) applies to >>>> the RA/RAA renewals. >>>> >>>> >>>> >>>> >>>> >>>> The CCWG is planning to submit its comments by May 10, so there should >>>> be more clarity about exactly what they intend to say soon. >>>> >>>> >>>> >>>> >>>> >>>> Alissa >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On May 3, 2016, at 9:59 AM, Mueller, Milton L < milton at gatech.edu > >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> (F) applies the grandfathering to renewals of the agreements appearing in >>>> (B)-(D). >>>> >>>> >>>> >>>> >>>> >>>> MM: not correct: (F) applies the grandfathering to renewals of A – D. It >>>> reads: >>>> >>>> >>>> >>>> >>>> >>>> “(F) any renewals of agreements described in subsections (A)-(D) pursuant >>>> to their terms and conditions for renewal.” >>>> >>>> >>>> >>>> >>>> >>>> As I said in my initial comment, renewals of RA and RAA agreements are the >>>> most susceptible to bypassing mission limitations, because ICANN has the >>>> most expansive powers over names and the names community, unlike >>>> numbers and protocols, has not created a viable mechanism for changing >>>> the IFO. >>>> >>>> >>>> >>>> >>>> >>>> Picture this scenario: ICANN adds a highly regulatory requirement to the >>>> .com contract renewal; requiring it to pre-screen content in all .com second- >>>> level registrations. We might say, “this obviously violates the prohibition of >>>> content regulation in the mission statement,” but ICANN legal replies: “oh >>>> no, this is a renewal of the com agreement and therefore it is exempt from >>>> any such challenge.” >>>> >>>> >>>> >>>> >>>> >>>> If someone can show me that I am wrong legally about this possibility I’d be >>>> happy to drop it. But I haven’t seen any convincing arguments as to how >>>> this would not be possible. >>>> >>>> >>>> >>>> >>>> >>>> Therefore it would be extremely difficult for me to sign on to this statement >>>> if it does not mention the RA/RAA renewals problem and I frankly think >>>> we’d be missing the boat in a big way. >>>> >>>> >>>> >>>> >>>> >>>> --MM >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> The ICG process was fashioned to ensure that the transition plans reflected >>>> the consensus of the Internet community and allowed the operational >>>> communities to define their own transition plans. The ICG and the CCWG >>>> proposals define those wishes, and any changes to the Bylaws were to be to >>>> implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are >>>> outside the scope of both the ICG and the CCWG proposals. Unlike Section >>>> 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is >>>> documented in paragraph 147 of the CCWG proposal, the substance of (B)- >>>> (E) have not enjoyed appropriate community involvement or review. These >>>> sections affect much of the Internet community since they apply to >>>> agreements with a variety of external parties, including all of the >>>> operational communities. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Because several of the referenced agreements have not yet been written >>>> and most have not yet been agreed to by the relevant parties, the draft >>>> Bylaws essentially allow these external agreements to define ICANN's >>>> Mission. This seems like a bad idea for many reasons, not the least of which >>>> is that it creates the possibility for the agreements to contradict or >>>> circumvent the desires of the community who worked hard to clarify and >>>> correctly state ICANN’s Mission throughout the IANA stewardship >>>> transition process (see paragraphs 140-147 of the CCWG proposal). >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> The ICG believes that in order for the Bylaws to be considered consistent >>>> with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and >>>> Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). >>>> This assumes that (F) is indeed called for by paragraph 147 of the CCWG >>>> proposal, which we leave for the CCWG to judge. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Regards, >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Alissa Cooper on behalf of the ICG >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> [1] http://mm.icann.org/pipermail/cwg-stewardship/2016- >>>> April/004877.html >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Apr 30, 2016, at 8:16 AM, Mueller, Milton L < milton at gatech.edu > >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Ok, I have had time to read the transcript. I am even more strongly >>>> committed to developing a comment as ICG. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that allows all >>>> of the work that was done to more precisely define the mission statement >>>> of ICANN in these bylaws ...to be completely contravened by whatever gets >>>> written into the ICANN PTI contract Because what this is says is that no one >>>> in the future will ever be able to challenge that contract on the basis that it >>>> contravenes the mission.” >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> [and, I might add, the RZM contract, and renewals of registry contracts]. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> The only answer I saw to this was that we don’t need to worry about it >>>> because the PTI contract will be put up for public comment. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Alissa also made the point: >>>> >>>> >>>> >>>> "this memo ... seems to imply that ... the most important thing out of all of >>>> this is that ICANN can continue to perform the IANA function. And I think >>>> what we all learned in (unintelligible) in terms of what the ICG proposal says >>>> is that in fact that is not the most important thing. The most important >>>> thing is that the IANA functions can continue to be performed by some >>>> operator who’s capable of performing them according to the service level >>>> agreements that the community ...has. And those two things are not the >>>> same. And I certainly –I will put my IETF hat on here for a second and say >>>> that I think from an IETF perspective the important thing is that a protocol >>>> parameters functions can continue to be performed, not that they can only >>>> continue to be performed by ICANN." >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> I don't think this argument of Alissa was ever answered. It seems like there >>>> could be ways of drafting these sections that do not commit us to a specific >>>> contract but makes it clear that performance of the IANA functions is not >>>> challengable as a mission violation so long as the community actually wants >>>> ICANN to perform those functions. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Indeed, I am having trouble understanding the threat that these sections >>>> are supposed to avoid. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> However, the most dangerous mission-limitation-busting potential is in the >>>> renewals section (F). This is problematic partly because the CCWG never >>>> agreed to exempt renewals. We agreed to grandfather existing agreements, >>>> for the sake of stability. But the assumption was that if anything in these >>>> existing agreements contravened the new mission limitations, that they >>>> COULD be challenged during a renewal process. A contract renewal with a >>>> registry could include all kinds of regulatory measures that exceed the >>>> mission, and if these measures are framed as a "renewal of an existing >>>> agreement" then ICANN could in principle get away with anything. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> So I hope we are able to make it clear to ICANN and the CCWG that these >>>> provisions need to be changed.. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> From: Alissa Cooper [ mailto:alissa at cooperw.in ] >>>> Sent: Friday, April 29, 2016 3:00 PM >>>> To: Mueller, Milton L < milton at gatech.edu > >>>> Cc: Lynn St.Amour < Lynn at LStAmour.org >; IANA etc etcCoordination >>>> Group < internal-cg at ianacg.org > >>>> Subject: Re: [Internal-cg] bylaws feedback >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> For folks following this issue, it is definitely worth reading the transcript or >>>> listening to the recording of the last CCWG call: >>>> https://community.icann.org/pages/viewpage.action?pageId=58730392 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> The more that I have thought about this, it has become clear to me that the >>>> core issue here is that there is a portion of bylaws section 1.1(d) that is not >>>> called for either by our proposal or by the CCWG proposal, as Lynn says. >>>> Had the content of 1.1(d)(ii)(B-E) been discussed as part of the transition >>>> proposal development, I think the concerns being raised now would have >>>> been raised then, and the whole community would have had time to sort >>>> them out. (I note that there was an extended discussion about RA/RAA >>>> agreements in the CCWG and that did result in text in its proposal in >>>> paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not extend >>>> to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been created >>>> out of whole cloth by the bylaws drafting team, and that was not within >>>> their remit in my opinion. The Bylaws are just supposed to implement the >>>> proposals. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> I think there are substantive issues too, but from an ICG perspective we >>>> may or may not want to focus on those. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> I would support sending a comment. We sent a message early on during the >>>> bylaws drafting and received no response, and the call to discuss this didn’t >>>> even occur until after the bylaws were put out for public comment. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Alissa >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Apr 29, 2016, at 11:17 AM, Mueller, Milton L < milton at gatech.edu > >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> I support what you are saying. I take it you are not satisfied with the >>>> lawyers' explanation? I was not able to attend the 0:400 call a few days ago >>>> so was not able to question them about it or hear their answers. >>>> >>>> --MM >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Lynn St.Amour [ mailto:Lynn at LStAmour.org ] >>>> Sent: Friday, April 29, 2016 1:55 PM >>>> To: Alissa Cooper < alissa at cooperw.in >; Mueller, Milton L < >>>> milton at gatech.edu >; IANA etc etcCoordination Group >>> cg at ianacg.org > >>>> Subject: Re: [Internal-cg] bylaws feedback >>>> >>>> Hi Alissa, Milton, all, >>>> >>>> I would like to come back to this subject. Specifically, I would like to >>>> propose that the ICG send in a statement to the By-laws comment period. >>>> >>>> Alissa commented on a specific concern (see thread below) and I also >>>> believe the ICG should be concerned about the overreach in the draft >>>> bylaws. >>>> >>>> My main concerns are: >>>> >>>> - the fact that these draft by-laws, through the grand-fathering provisions, >>>> allow external agreements to define ICANN's Mission which seems like a >>>> bad idea for many reasons. Further, this contradicts the desires of the >>>> community (or is a run around the community - intentional or not) who >>>> worked hard to clarify and correctly state ICANN’s mission throughout the >>>> IANA Transition process (paragraphs 140-144 of the CCWG-Accountability >>>> proposal). >>>> >>>> - the ICG process was fashioned to ensure that the transition plans reflected >>>> the consensus of the Internet community. And, it was to respect the roles >>>> and responsibilities of the OCs in defining their own transition plans. The >>>> ICG and the CCWG reports define those wishes, and any changes to the >>>> bylaws were to be to implement those wishes, nothing more. Yet provisions >>>> in sections >>>> 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- >>>> Accountability proposals, and so there has not been appropriate >>>> community involvement or review for those changes. Note: these sections >>>> affect much of the Internet community, as they apply to agreements >>>> between ICANN and the ASO, NRO, IETF, Root Zone Maintainer, and PTI. >>>> >>>> For transparency: the IAB/IETF are also concerned about the overreach and >>>> are drafting their own comments, and as an IAB appointee to the ICG, I am >>>> part of that review as well. >>>> >>>> If there is support for the ICG sending in a comment, I would be happy to >>>> work with Alissa and others to draft something for ICG review. >>>> >>>> Regards, >>>> Lynn >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Apr 12, 2016, at 3:15 PM, Alissa Cooper < alissa at cooperw.in > wrote: >>>> >>>> From the minutes it looks like this was discussed on the CCWG call and >>>> there >>>> >>>> >>>> >>>> will be follow-up. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Apr 12, 2016, at 8:39 AM, Mueller, Milton L < milton at gatech.edu > >>>> >>>> >>>> >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> I sent it yesterday but there has been no response at all. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Alissa Cooper [ mailto:alissa at cooperw.in ] >>>> Sent: Monday, April 11, 2016 4:54 PM >>>> To: Mueller, Milton L < milton at gatech.edu > >>>> Cc: IANA etc etcCoordination Group < internal-cg at ianacg.org > >>>> Subject: Re: [Internal-cg] bylaws feedback >>>> >>>> I think that would be fine. >>>> >>>> Thanks, >>>> Alissa >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Apr 11, 2016, at 1:04 PM, Mueller, Milton L < milton at gatech.edu > >>>> >>>> >>>> >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Alissa >>>> If you don't mind I will just forward your message to the bylaws >>>> and CWG >>>> >>>> >>>> >>>> lists. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> If there is some other way you want me to do this, please let me know. >>>> >>>> --MM >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Internal-cg [ mailto:internal-cg-bounces at ianacg.org ] On >>>> Behalf Of Alissa Cooper >>>> Sent: Monday, April 11, 2016 1:49 PM >>>> To: IANA etc etcCoordination Group < internal-cg at ianacg.org > >>>> Subject: [Internal-cg] bylaws feedback >>>> >>>> I have looked a bit at the draft bylaws and I’d like to ask >>>> Kavouss and Milton to bring the following issue back to the bylaws >>>> >>>> >>>> >>>> drafting group: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Section 1.1(d)(ii) incorporates by reference a number of documents >>>> external to the bylaws as a means to prevent challenges on the >>>> basis that those documents conflict with or violate the bylaws. In >>>> particular, bullet (D) applies this provision to "the IANA Naming >>>> Function Contract between ICANN and PTI effective [October 1, 2016]." >>>> >>>> Given the ICG's historical encouragement of the community to meet >>>> timelines necessary for a successful transition, I find this >>>> provision to be extremely problematic. It incorporates a reference >>>> to a document that does not exist yet and that is unlikely to be >>>> completed by the time the bylaws are supposed to be done (early >>>> June). In fact, it is not even clear at this point whether the new >>>> ICANN affiliate to be setup will be name "PTI" or have some other >>>> name. I don't understand how anyone can reason about whether >>>> 1.1(d)(ii) is an acceptable bylaws provision if it references a >>>> document that has not been written. (This also applies to (B) and >>>> (C) since it could apply to future documents that haven’t been >>>> written >>>> yet.) >>>> >>>> Furthermore, I question whether it is a sound decision to >>>> essentially allow for documents external to the bylaws to be able >>>> to modify the bylaws (under (F)). This section would make more >>>> sense if it was entirely internally specified, without the >>>> references to external documents. At a minimum, I think we should >>>> recommend that (D) be >>>> >>>> >>>> >>>> removed. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Thanks, >>>> Alissa >>>> _______________________________________________ >>>> Internal-cg mailing list >>>> Internal-cg at mm.ianacg.org >>>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >>>> >>>> >>>> _______________________________________________ >>>> Internal-cg mailing list >>>> Internal-cg at mm.ianacg.org >>>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >>>> >>>> _______________________________________________ >>>> Internal-cg mailing list >>>> Internal-cg at mm.ianacg.org >>>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >>> _______________________________________________ >>> Internal-cg mailing list >>> Internal-cg at mm.ianacg.org >>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >> >> _______________________________________________ >> Internal-cg mailing list >> Internal-cg at mm.ianacg.org >> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org > > > _______________________________________________ > Internal-cg mailing list > Internal-cg at mm.ianacg.org > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org From Lynn at LStAmour.org Fri May 13 02:36:04 2016 From: Lynn at LStAmour.org (Lynn St.Amour) Date: Thu, 12 May 2016 22:36:04 -0400 Subject: [Internal-cg] bylaws feedback In-Reply-To: <9B260ABE-EA98-4DD3-B8A5-2510C600CFAF@cooperw.in> References: <142976331.139.1462343299764.JavaMail.jjs-mac-2@macbook-air-de-jean-jacques-2.home> <7146C0FDA8771A43BEB20E18700C2E4F0181AF71AF3A@ACCAN01.accan.local> <9B260ABE-EA98-4DD3-B8A5-2510C600CFAF@cooperw.in> Message-ID: <244ED00C-AF53-40C9-8AF8-7FF8D7C96851@LStAmour.org> Hi Alissa, I fully support sending it. Lynn > On May 11, 2016, at 3:11 PM, Alissa Cooper wrote: > > I’d like us to close out on this. If anyone objects to us submitting the text below as a public comment on the draft bylaws, please say so by Friday, May 13 at 23:59. If there are no objections, I’ll submit it. > > --- > > The ICG appreciates the opportunity to comment on the draft ICANN Bylaws. > > The ICG previously communicated concerns about Section 1.1(d)(ii) to the Bylaws drafting group [1]. However, these concerns were not addressed in the draft Bylaws that were posted for public comment. > > Section 1.1(d) "grandfathers" a number of agreements into the Bylaws in order to prevent parties from challenging those agreements on the basis that they violate the ICANN Mission statement. Under Section 1.1(d)(ii), (A) applies to RA/RAA agreements; (B)-(D) apply to agreements between ICANN and the NRO, ASO, IETF, RZM, and PTI; and (E) applies to ICANN's Five-Year Strategic Plan and Five-Year Operating Plan. (F) applies the grandfathering to renewals of the agreements appearing in (B)-(E). > > The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. > > Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). > > The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. > > Regards, > > Alissa Cooper on behalf of the ICG > > > >> On May 6, 2016, at 2:59 AM, Kavouss Arasteh wrote: >> >> Jean Jaques >> Tks >> This is what I and you pushed since long time but have not yet been heard >> Kavousd >> >> Sent from my iPhone >> >>> On 5 May 2016, at 09:43, Narelle Clark wrote: >>> >>> Jean-Jacques has the rationale exactly. >>> >>> +1 >>> >>> Narelle >>> >>> >>>> -----Original Message----- >>>> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of >>>> Subrenat, Jean-Jacques >>>> Sent: Wednesday, 4 May 2016 4:28 PM >>>> To: Martin Boyle >>>> Cc: Lynn St.Amour; Milton L Mueller; IANA etc etcCoordination Group >>>> Subject: Re: [Internal-cg] bylaws feedback >>>> >>>> Hello Alissa & All, >>>> >>>> I support the draft as it now stands, in order to >>>> - warn against any initiative or mechanism which would endanger the >>>> Transition proposal before it has even been thoroughly vetted in >>>> Washington, >>>> - underline the risk of the ICANN Mission being susceptible to modification >>>> by external texts or undertakings, some of which are not yet in existence, >>>> - demand the withdrawal of Sections 1.1(d)(ii)(B)-(E), and the modification >>>> of Section 1.1(d)(ii)(F) so as to apply only to Section 1.1(d)(ii)(A). >>>> >>>> Best regards, >>>> Jean-Jacques. >>>> >>>> >>>> >>>> >>>> ----- Mail original ----- >>>> De: "Martin Boyle" >>>> À: "Alissa Cooper" , "Milton L Mueller" >>>> >>>> Cc: "Lynn St.Amour" , "IANA etc etcCoordination >>>> Group" >>>> Envoyé: Mercredi 4 Mai 2016 00:15:40 >>>> Objet: Re: [Internal-cg] bylaws feedback >>>> >>>> >>>> >>>> >>>> >>>> Hi Alissa, all, >>>> >>>> >>>> >>>> I agree with you, Alissa. This sort of detail does seem to me to go well >>>> beyond the remit of the ICG and we should certainly not be seeking to >>>> upset areas already agreed in the CCWG-Accountability process. >>>> >>>> >>>> >>>> For the rest of this, I am afraid I have not been following the CCWG process >>>> carefully enough to have a view of where the text bylaw drafting goes >>>> beyond the consensus of the proposal. I’ll try to look at it tomorrow, but on >>>> my cursory reading of the arguments below, this does look like a legitimate >>>> input from the ICG. >>>> >>>> >>>> >>>> Hope this helps >>>> >>>> >>>> >>>> Martin >>>> >>>> >>>> >>>> >>>> >>>> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of >>>> Alissa Cooper >>>> Sent: 03 May 2016 22:10 >>>> To: Mueller, Milton L >>>> Cc: Lynn St.Amour ; IANA etc etcCoordination Group >>>> >>>> Subject: Re: [Internal-cg] bylaws feedback >>>> >>>> >>>> >>>> >>>> I don’t have an opinion about the substance of the RA/RAA renewals, but I >>>> don’t think they are within the scope of what the ICG should comment on. >>>> >>>> >>>> >>>> >>>> >>>> The renewal of RA and RAA agreements were discussed on today’s CCWG >>>> call (as well as on several previous CCWG calls and the CCWG mailing list). It >>>> appears that the CCWG will be commenting on these renewals in its own >>>> comments about the Bylaws, and will be supporting the existing language in >>>> (F) as it applies to the RA and RAA agreements. Considering that the CCWG >>>> appears to have discussed this topic at great length and has consensus on >>>> it, I don’t think the same argument we are making about (B)-(E) applies to >>>> the RA/RAA renewals. >>>> >>>> >>>> >>>> >>>> >>>> The CCWG is planning to submit its comments by May 10, so there should >>>> be more clarity about exactly what they intend to say soon. >>>> >>>> >>>> >>>> >>>> >>>> Alissa >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On May 3, 2016, at 9:59 AM, Mueller, Milton L < milton at gatech.edu > >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> (F) applies the grandfathering to renewals of the agreements appearing in >>>> (B)-(D). >>>> >>>> >>>> >>>> >>>> >>>> MM: not correct: (F) applies the grandfathering to renewals of A – D. It >>>> reads: >>>> >>>> >>>> >>>> >>>> >>>> “(F) any renewals of agreements described in subsections (A)-(D) pursuant >>>> to their terms and conditions for renewal.” >>>> >>>> >>>> >>>> >>>> >>>> As I said in my initial comment, renewals of RA and RAA agreements are the >>>> most susceptible to bypassing mission limitations, because ICANN has the >>>> most expansive powers over names and the names community, unlike >>>> numbers and protocols, has not created a viable mechanism for changing >>>> the IFO. >>>> >>>> >>>> >>>> >>>> >>>> Picture this scenario: ICANN adds a highly regulatory requirement to the >>>> .com contract renewal; requiring it to pre-screen content in all .com second- >>>> level registrations. We might say, “this obviously violates the prohibition of >>>> content regulation in the mission statement,” but ICANN legal replies: “oh >>>> no, this is a renewal of the com agreement and therefore it is exempt from >>>> any such challenge.” >>>> >>>> >>>> >>>> >>>> >>>> If someone can show me that I am wrong legally about this possibility I’d be >>>> happy to drop it. But I haven’t seen any convincing arguments as to how >>>> this would not be possible. >>>> >>>> >>>> >>>> >>>> >>>> Therefore it would be extremely difficult for me to sign on to this statement >>>> if it does not mention the RA/RAA renewals problem and I frankly think >>>> we’d be missing the boat in a big way. >>>> >>>> >>>> >>>> >>>> >>>> --MM >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> The ICG process was fashioned to ensure that the transition plans reflected >>>> the consensus of the Internet community and allowed the operational >>>> communities to define their own transition plans. The ICG and the CCWG >>>> proposals define those wishes, and any changes to the Bylaws were to be to >>>> implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are >>>> outside the scope of both the ICG and the CCWG proposals. Unlike Section >>>> 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is >>>> documented in paragraph 147 of the CCWG proposal, the substance of (B)- >>>> (E) have not enjoyed appropriate community involvement or review. These >>>> sections affect much of the Internet community since they apply to >>>> agreements with a variety of external parties, including all of the >>>> operational communities. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Because several of the referenced agreements have not yet been written >>>> and most have not yet been agreed to by the relevant parties, the draft >>>> Bylaws essentially allow these external agreements to define ICANN's >>>> Mission. This seems like a bad idea for many reasons, not the least of which >>>> is that it creates the possibility for the agreements to contradict or >>>> circumvent the desires of the community who worked hard to clarify and >>>> correctly state ICANN’s Mission throughout the IANA stewardship >>>> transition process (see paragraphs 140-147 of the CCWG proposal). >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> The ICG believes that in order for the Bylaws to be considered consistent >>>> with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and >>>> Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). >>>> This assumes that (F) is indeed called for by paragraph 147 of the CCWG >>>> proposal, which we leave for the CCWG to judge. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Regards, >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Alissa Cooper on behalf of the ICG >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> [1] http://mm.icann.org/pipermail/cwg-stewardship/2016- >>>> April/004877.html >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Apr 30, 2016, at 8:16 AM, Mueller, Milton L < milton at gatech.edu > >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Ok, I have had time to read the transcript. I am even more strongly >>>> committed to developing a comment as ICG. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that allows all >>>> of the work that was done to more precisely define the mission statement >>>> of ICANN in these bylaws ...to be completely contravened by whatever gets >>>> written into the ICANN PTI contract Because what this is says is that no one >>>> in the future will ever be able to challenge that contract on the basis that it >>>> contravenes the mission.” >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> [and, I might add, the RZM contract, and renewals of registry contracts]. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> The only answer I saw to this was that we don’t need to worry about it >>>> because the PTI contract will be put up for public comment. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Alissa also made the point: >>>> >>>> >>>> >>>> "this memo ... seems to imply that ... the most important thing out of all of >>>> this is that ICANN can continue to perform the IANA function. And I think >>>> what we all learned in (unintelligible) in terms of what the ICG proposal says >>>> is that in fact that is not the most important thing. The most important >>>> thing is that the IANA functions can continue to be performed by some >>>> operator who’s capable of performing them according to the service level >>>> agreements that the community ...has. And those two things are not the >>>> same. And I certainly –I will put my IETF hat on here for a second and say >>>> that I think from an IETF perspective the important thing is that a protocol >>>> parameters functions can continue to be performed, not that they can only >>>> continue to be performed by ICANN." >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> I don't think this argument of Alissa was ever answered. It seems like there >>>> could be ways of drafting these sections that do not commit us to a specific >>>> contract but makes it clear that performance of the IANA functions is not >>>> challengable as a mission violation so long as the community actually wants >>>> ICANN to perform those functions. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Indeed, I am having trouble understanding the threat that these sections >>>> are supposed to avoid. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> However, the most dangerous mission-limitation-busting potential is in the >>>> renewals section (F). This is problematic partly because the CCWG never >>>> agreed to exempt renewals. We agreed to grandfather existing agreements, >>>> for the sake of stability. But the assumption was that if anything in these >>>> existing agreements contravened the new mission limitations, that they >>>> COULD be challenged during a renewal process. A contract renewal with a >>>> registry could include all kinds of regulatory measures that exceed the >>>> mission, and if these measures are framed as a "renewal of an existing >>>> agreement" then ICANN could in principle get away with anything. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> So I hope we are able to make it clear to ICANN and the CCWG that these >>>> provisions need to be changed.. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> From: Alissa Cooper [ mailto:alissa at cooperw.in ] >>>> Sent: Friday, April 29, 2016 3:00 PM >>>> To: Mueller, Milton L < milton at gatech.edu > >>>> Cc: Lynn St.Amour < Lynn at LStAmour.org >; IANA etc etcCoordination >>>> Group < internal-cg at ianacg.org > >>>> Subject: Re: [Internal-cg] bylaws feedback >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> For folks following this issue, it is definitely worth reading the transcript or >>>> listening to the recording of the last CCWG call: >>>> https://community.icann.org/pages/viewpage.action?pageId=58730392 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> The more that I have thought about this, it has become clear to me that the >>>> core issue here is that there is a portion of bylaws section 1.1(d) that is not >>>> called for either by our proposal or by the CCWG proposal, as Lynn says. >>>> Had the content of 1.1(d)(ii)(B-E) been discussed as part of the transition >>>> proposal development, I think the concerns being raised now would have >>>> been raised then, and the whole community would have had time to sort >>>> them out. (I note that there was an extended discussion about RA/RAA >>>> agreements in the CCWG and that did result in text in its proposal in >>>> paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not extend >>>> to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been created >>>> out of whole cloth by the bylaws drafting team, and that was not within >>>> their remit in my opinion. The Bylaws are just supposed to implement the >>>> proposals. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> I think there are substantive issues too, but from an ICG perspective we >>>> may or may not want to focus on those. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> I would support sending a comment. We sent a message early on during the >>>> bylaws drafting and received no response, and the call to discuss this didn’t >>>> even occur until after the bylaws were put out for public comment. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Alissa >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Apr 29, 2016, at 11:17 AM, Mueller, Milton L < milton at gatech.edu > >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> I support what you are saying. I take it you are not satisfied with the >>>> lawyers' explanation? I was not able to attend the 0:400 call a few days ago >>>> so was not able to question them about it or hear their answers. >>>> >>>> --MM >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Lynn St.Amour [ mailto:Lynn at LStAmour.org ] >>>> Sent: Friday, April 29, 2016 1:55 PM >>>> To: Alissa Cooper < alissa at cooperw.in >; Mueller, Milton L < >>>> milton at gatech.edu >; IANA etc etcCoordination Group >>> cg at ianacg.org > >>>> Subject: Re: [Internal-cg] bylaws feedback >>>> >>>> Hi Alissa, Milton, all, >>>> >>>> I would like to come back to this subject. Specifically, I would like to >>>> propose that the ICG send in a statement to the By-laws comment period. >>>> >>>> Alissa commented on a specific concern (see thread below) and I also >>>> believe the ICG should be concerned about the overreach in the draft >>>> bylaws. >>>> >>>> My main concerns are: >>>> >>>> - the fact that these draft by-laws, through the grand-fathering provisions, >>>> allow external agreements to define ICANN's Mission which seems like a >>>> bad idea for many reasons. Further, this contradicts the desires of the >>>> community (or is a run around the community - intentional or not) who >>>> worked hard to clarify and correctly state ICANN’s mission throughout the >>>> IANA Transition process (paragraphs 140-144 of the CCWG-Accountability >>>> proposal). >>>> >>>> - the ICG process was fashioned to ensure that the transition plans reflected >>>> the consensus of the Internet community. And, it was to respect the roles >>>> and responsibilities of the OCs in defining their own transition plans. The >>>> ICG and the CCWG reports define those wishes, and any changes to the >>>> bylaws were to be to implement those wishes, nothing more. Yet provisions >>>> in sections >>>> 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- >>>> Accountability proposals, and so there has not been appropriate >>>> community involvement or review for those changes. Note: these sections >>>> affect much of the Internet community, as they apply to agreements >>>> between ICANN and the ASO, NRO, IETF, Root Zone Maintainer, and PTI. >>>> >>>> For transparency: the IAB/IETF are also concerned about the overreach and >>>> are drafting their own comments, and as an IAB appointee to the ICG, I am >>>> part of that review as well. >>>> >>>> If there is support for the ICG sending in a comment, I would be happy to >>>> work with Alissa and others to draft something for ICG review. >>>> >>>> Regards, >>>> Lynn >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Apr 12, 2016, at 3:15 PM, Alissa Cooper < alissa at cooperw.in > wrote: >>>> >>>> From the minutes it looks like this was discussed on the CCWG call and >>>> there >>>> >>>> >>>> >>>> will be follow-up. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Apr 12, 2016, at 8:39 AM, Mueller, Milton L < milton at gatech.edu > >>>> >>>> >>>> >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> I sent it yesterday but there has been no response at all. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Alissa Cooper [ mailto:alissa at cooperw.in ] >>>> Sent: Monday, April 11, 2016 4:54 PM >>>> To: Mueller, Milton L < milton at gatech.edu > >>>> Cc: IANA etc etcCoordination Group < internal-cg at ianacg.org > >>>> Subject: Re: [Internal-cg] bylaws feedback >>>> >>>> I think that would be fine. >>>> >>>> Thanks, >>>> Alissa >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Apr 11, 2016, at 1:04 PM, Mueller, Milton L < milton at gatech.edu > >>>> >>>> >>>> >>>> wrote: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Alissa >>>> If you don't mind I will just forward your message to the bylaws >>>> and CWG >>>> >>>> >>>> >>>> lists. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> If there is some other way you want me to do this, please let me know. >>>> >>>> --MM >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Internal-cg [ mailto:internal-cg-bounces at ianacg.org ] On >>>> Behalf Of Alissa Cooper >>>> Sent: Monday, April 11, 2016 1:49 PM >>>> To: IANA etc etcCoordination Group < internal-cg at ianacg.org > >>>> Subject: [Internal-cg] bylaws feedback >>>> >>>> I have looked a bit at the draft bylaws and I’d like to ask >>>> Kavouss and Milton to bring the following issue back to the bylaws >>>> >>>> >>>> >>>> drafting group: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Section 1.1(d)(ii) incorporates by reference a number of documents >>>> external to the bylaws as a means to prevent challenges on the >>>> basis that those documents conflict with or violate the bylaws. In >>>> particular, bullet (D) applies this provision to "the IANA Naming >>>> Function Contract between ICANN and PTI effective [October 1, 2016]." >>>> >>>> Given the ICG's historical encouragement of the community to meet >>>> timelines necessary for a successful transition, I find this >>>> provision to be extremely problematic. It incorporates a reference >>>> to a document that does not exist yet and that is unlikely to be >>>> completed by the time the bylaws are supposed to be done (early >>>> June). In fact, it is not even clear at this point whether the new >>>> ICANN affiliate to be setup will be name "PTI" or have some other >>>> name. I don't understand how anyone can reason about whether >>>> 1.1(d)(ii) is an acceptable bylaws provision if it references a >>>> document that has not been written. (This also applies to (B) and >>>> (C) since it could apply to future documents that haven’t been >>>> written >>>> yet.) >>>> >>>> Furthermore, I question whether it is a sound decision to >>>> essentially allow for documents external to the bylaws to be able >>>> to modify the bylaws (under (F)). This section would make more >>>> sense if it was entirely internally specified, without the >>>> references to external documents. At a minimum, I think we should >>>> recommend that (D) be >>>> >>>> >>>> >>>> removed. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Thanks, >>>> Alissa >>>> _______________________________________________ >>>> Internal-cg mailing list >>>> Internal-cg at mm.ianacg.org >>>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >>>> >>>> >>>> _______________________________________________ >>>> Internal-cg mailing list >>>> Internal-cg at mm.ianacg.org >>>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >>>> >>>> _______________________________________________ >>>> Internal-cg mailing list >>>> Internal-cg at mm.ianacg.org >>>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >>> _______________________________________________ >>> Internal-cg mailing list >>> Internal-cg at mm.ianacg.org >>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >> >> _______________________________________________ >> Internal-cg mailing list >> Internal-cg at mm.ianacg.org >> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org > > > _______________________________________________ > Internal-cg mailing list > Internal-cg at mm.ianacg.org > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org From paf at frobbit.se Fri May 13 04:32:44 2016 From: paf at frobbit.se (Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=) Date: Fri, 13 May 2016 06:32:44 +0200 Subject: [Internal-cg] bylaws feedback In-Reply-To: References: <142976331.139.1462343299764.JavaMail.jjs-mac-2@macbook-air-de-jean-jacques-2.home> <7146C0FDA8771A43BEB20E18700C2E4F0181AF71AF3A@ACCAN01.accan.local> <9B260ABE-EA98-4DD3-B8A5-2510C600CFAF@cooperw.in> Message-ID: <0291789C-0A46-4C00-A5A8-2B767D273D3F@frobbit.se> Support from me and SSAC. paf On 13 May 2016, at 4:21, Russ Mundy wrote: > Alissa, I agree - excellent points, please send. Russ M > > On May 11, 2016, at 3:11 PM, Alissa Cooper wrote: > >> I’d like us to close out on this. If anyone objects to us submitting the text below as a public comment on the draft bylaws, please say so by Friday, May 13 at 23:59. If there are no objections, I’ll submit it. >> >> --- >> >> The ICG appreciates the opportunity to comment on the draft ICANN Bylaws. >> >> The ICG previously communicated concerns about Section 1.1(d)(ii) to the Bylaws drafting group [1]. However, these concerns were not addressed in the draft Bylaws that were posted for public comment. >> >> Section 1.1(d) "grandfathers" a number of agreements into the Bylaws in order to prevent parties from challenging those agreements on the basis that they violate the ICANN Mission statement. Under Section 1.1(d)(ii), (A) applies to RA/RAA agreements; (B)-(D) apply to agreements between ICANN and the NRO, ASO, IETF, RZM, and PTI; and (E) applies to ICANN's Five-Year Strategic Plan and Five-Year Operating Plan. (F) applies the grandfathering to renewals of the agreements appearing in (B)-(E). >> >> The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. >> >> Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). >> >> The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. >> >> Regards, >> >> Alissa Cooper on behalf of the ICG >> >> >> >>> On May 6, 2016, at 2:59 AM, Kavouss Arasteh wrote: >>> >>> Jean Jaques >>> Tks >>> This is what I and you pushed since long time but have not yet been heard >>> Kavousd >>> >>> Sent from my iPhone >>> >>>> On 5 May 2016, at 09:43, Narelle Clark wrote: >>>> >>>> Jean-Jacques has the rationale exactly. >>>> >>>> +1 >>>> >>>> Narelle >>>> >>>> >>>>> -----Original Message----- >>>>> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of >>>>> Subrenat, Jean-Jacques >>>>> Sent: Wednesday, 4 May 2016 4:28 PM >>>>> To: Martin Boyle >>>>> Cc: Lynn St.Amour; Milton L Mueller; IANA etc etcCoordination Group >>>>> Subject: Re: [Internal-cg] bylaws feedback >>>>> >>>>> Hello Alissa & All, >>>>> >>>>> I support the draft as it now stands, in order to >>>>> - warn against any initiative or mechanism which would endanger the >>>>> Transition proposal before it has even been thoroughly vetted in >>>>> Washington, >>>>> - underline the risk of the ICANN Mission being susceptible to modification >>>>> by external texts or undertakings, some of which are not yet in existence, >>>>> - demand the withdrawal of Sections 1.1(d)(ii)(B)-(E), and the modification >>>>> of Section 1.1(d)(ii)(F) so as to apply only to Section 1.1(d)(ii)(A). >>>>> >>>>> Best regards, >>>>> Jean-Jacques. >>>>> >>>>> >>>>> >>>>> >>>>> ----- Mail original ----- >>>>> De: "Martin Boyle" >>>>> À: "Alissa Cooper" , "Milton L Mueller" >>>>> >>>>> Cc: "Lynn St.Amour" , "IANA etc etcCoordination >>>>> Group" >>>>> Envoyé: Mercredi 4 Mai 2016 00:15:40 >>>>> Objet: Re: [Internal-cg] bylaws feedback >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Hi Alissa, all, >>>>> >>>>> >>>>> >>>>> I agree with you, Alissa. This sort of detail does seem to me to go well >>>>> beyond the remit of the ICG and we should certainly not be seeking to >>>>> upset areas already agreed in the CCWG-Accountability process. >>>>> >>>>> >>>>> >>>>> For the rest of this, I am afraid I have not been following the CCWG process >>>>> carefully enough to have a view of where the text bylaw drafting goes >>>>> beyond the consensus of the proposal. I’ll try to look at it tomorrow, but on >>>>> my cursory reading of the arguments below, this does look like a legitimate >>>>> input from the ICG. >>>>> >>>>> >>>>> >>>>> Hope this helps >>>>> >>>>> >>>>> >>>>> Martin >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of >>>>> Alissa Cooper >>>>> Sent: 03 May 2016 22:10 >>>>> To: Mueller, Milton L >>>>> Cc: Lynn St.Amour ; IANA etc etcCoordination Group >>>>> >>>>> Subject: Re: [Internal-cg] bylaws feedback >>>>> >>>>> >>>>> >>>>> >>>>> I don’t have an opinion about the substance of the RA/RAA renewals, but I >>>>> don’t think they are within the scope of what the ICG should comment on. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The renewal of RA and RAA agreements were discussed on today’s CCWG >>>>> call (as well as on several previous CCWG calls and the CCWG mailing list). It >>>>> appears that the CCWG will be commenting on these renewals in its own >>>>> comments about the Bylaws, and will be supporting the existing language in >>>>> (F) as it applies to the RA and RAA agreements. Considering that the CCWG >>>>> appears to have discussed this topic at great length and has consensus on >>>>> it, I don’t think the same argument we are making about (B)-(E) applies to >>>>> the RA/RAA renewals. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The CCWG is planning to submit its comments by May 10, so there should >>>>> be more clarity about exactly what they intend to say soon. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Alissa >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On May 3, 2016, at 9:59 AM, Mueller, Milton L < milton at gatech.edu > >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> (F) applies the grandfathering to renewals of the agreements appearing in >>>>> (B)-(D). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> MM: not correct: (F) applies the grandfathering to renewals of A – D. It >>>>> reads: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> “(F) any renewals of agreements described in subsections (A)-(D) pursuant >>>>> to their terms and conditions for renewal.” >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> As I said in my initial comment, renewals of RA and RAA agreements are the >>>>> most susceptible to bypassing mission limitations, because ICANN has the >>>>> most expansive powers over names and the names community, unlike >>>>> numbers and protocols, has not created a viable mechanism for changing >>>>> the IFO. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Picture this scenario: ICANN adds a highly regulatory requirement to the >>>>> .com contract renewal; requiring it to pre-screen content in all .com second- >>>>> level registrations. We might say, “this obviously violates the prohibition of >>>>> content regulation in the mission statement,” but ICANN legal replies: “oh >>>>> no, this is a renewal of the com agreement and therefore it is exempt from >>>>> any such challenge.” >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> If someone can show me that I am wrong legally about this possibility I’d be >>>>> happy to drop it. But I haven’t seen any convincing arguments as to how >>>>> this would not be possible. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Therefore it would be extremely difficult for me to sign on to this statement >>>>> if it does not mention the RA/RAA renewals problem and I frankly think >>>>> we’d be missing the boat in a big way. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> --MM >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The ICG process was fashioned to ensure that the transition plans reflected >>>>> the consensus of the Internet community and allowed the operational >>>>> communities to define their own transition plans. The ICG and the CCWG >>>>> proposals define those wishes, and any changes to the Bylaws were to be to >>>>> implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are >>>>> outside the scope of both the ICG and the CCWG proposals. Unlike Section >>>>> 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is >>>>> documented in paragraph 147 of the CCWG proposal, the substance of (B)- >>>>> (E) have not enjoyed appropriate community involvement or review. These >>>>> sections affect much of the Internet community since they apply to >>>>> agreements with a variety of external parties, including all of the >>>>> operational communities. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Because several of the referenced agreements have not yet been written >>>>> and most have not yet been agreed to by the relevant parties, the draft >>>>> Bylaws essentially allow these external agreements to define ICANN's >>>>> Mission. This seems like a bad idea for many reasons, not the least of which >>>>> is that it creates the possibility for the agreements to contradict or >>>>> circumvent the desires of the community who worked hard to clarify and >>>>> correctly state ICANN’s Mission throughout the IANA stewardship >>>>> transition process (see paragraphs 140-147 of the CCWG proposal). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The ICG believes that in order for the Bylaws to be considered consistent >>>>> with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and >>>>> Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). >>>>> This assumes that (F) is indeed called for by paragraph 147 of the CCWG >>>>> proposal, which we leave for the CCWG to judge. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Alissa Cooper on behalf of the ICG >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> [1] http://mm.icann.org/pipermail/cwg-stewardship/2016- >>>>> April/004877.html >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Apr 30, 2016, at 8:16 AM, Mueller, Milton L < milton at gatech.edu > >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Ok, I have had time to read the transcript. I am even more strongly >>>>> committed to developing a comment as ICG. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Alissa said on the call that 1.1.d.(ii) “creates a giant loophole that allows all >>>>> of the work that was done to more precisely define the mission statement >>>>> of ICANN in these bylaws ...to be completely contravened by whatever gets >>>>> written into the ICANN PTI contract Because what this is says is that no one >>>>> in the future will ever be able to challenge that contract on the basis that it >>>>> contravenes the mission.” >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> [and, I might add, the RZM contract, and renewals of registry contracts]. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The only answer I saw to this was that we don’t need to worry about it >>>>> because the PTI contract will be put up for public comment. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Alissa also made the point: >>>>> >>>>> >>>>> >>>>> "this memo ... seems to imply that ... the most important thing out of all of >>>>> this is that ICANN can continue to perform the IANA function. And I think >>>>> what we all learned in (unintelligible) in terms of what the ICG proposal says >>>>> is that in fact that is not the most important thing. The most important >>>>> thing is that the IANA functions can continue to be performed by some >>>>> operator who’s capable of performing them according to the service level >>>>> agreements that the community ...has. And those two things are not the >>>>> same. And I certainly –I will put my IETF hat on here for a second and say >>>>> that I think from an IETF perspective the important thing is that a protocol >>>>> parameters functions can continue to be performed, not that they can only >>>>> continue to be performed by ICANN." >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I don't think this argument of Alissa was ever answered. It seems like there >>>>> could be ways of drafting these sections that do not commit us to a specific >>>>> contract but makes it clear that performance of the IANA functions is not >>>>> challengable as a mission violation so long as the community actually wants >>>>> ICANN to perform those functions. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Indeed, I am having trouble understanding the threat that these sections >>>>> are supposed to avoid. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> However, the most dangerous mission-limitation-busting potential is in the >>>>> renewals section (F). This is problematic partly because the CCWG never >>>>> agreed to exempt renewals. We agreed to grandfather existing agreements, >>>>> for the sake of stability. But the assumption was that if anything in these >>>>> existing agreements contravened the new mission limitations, that they >>>>> COULD be challenged during a renewal process. A contract renewal with a >>>>> registry could include all kinds of regulatory measures that exceed the >>>>> mission, and if these measures are framed as a "renewal of an existing >>>>> agreement" then ICANN could in principle get away with anything. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> So I hope we are able to make it clear to ICANN and the CCWG that these >>>>> provisions need to be changed.. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> From: Alissa Cooper [ mailto:alissa at cooperw.in ] >>>>> Sent: Friday, April 29, 2016 3:00 PM >>>>> To: Mueller, Milton L < milton at gatech.edu > >>>>> Cc: Lynn St.Amour < Lynn at LStAmour.org >; IANA etc etcCoordination >>>>> Group < internal-cg at ianacg.org > >>>>> Subject: Re: [Internal-cg] bylaws feedback >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> For folks following this issue, it is definitely worth reading the transcript or >>>>> listening to the recording of the last CCWG call: >>>>> https://community.icann.org/pages/viewpage.action?pageId=58730392 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The more that I have thought about this, it has become clear to me that the >>>>> core issue here is that there is a portion of bylaws section 1.1(d) that is not >>>>> called for either by our proposal or by the CCWG proposal, as Lynn says. >>>>> Had the content of 1.1(d)(ii)(B-E) been discussed as part of the transition >>>>> proposal development, I think the concerns being raised now would have >>>>> been raised then, and the whole community would have had time to sort >>>>> them out. (I note that there was an extended discussion about RA/RAA >>>>> agreements in the CCWG and that did result in text in its proposal in >>>>> paragraph 147, which is reflected in 1.1(d)(ii)(A). But that does not extend >>>>> to any other agreements.) Sections 1.1(d)(ii)(B-E) seem to have been created >>>>> out of whole cloth by the bylaws drafting team, and that was not within >>>>> their remit in my opinion. The Bylaws are just supposed to implement the >>>>> proposals. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I think there are substantive issues too, but from an ICG perspective we >>>>> may or may not want to focus on those. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I would support sending a comment. We sent a message early on during the >>>>> bylaws drafting and received no response, and the call to discuss this didn’t >>>>> even occur until after the bylaws were put out for public comment. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Alissa >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Apr 29, 2016, at 11:17 AM, Mueller, Milton L < milton at gatech.edu > >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I support what you are saying. I take it you are not satisfied with the >>>>> lawyers' explanation? I was not able to attend the 0:400 call a few days ago >>>>> so was not able to question them about it or hear their answers. >>>>> >>>>> --MM >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Lynn St.Amour [ mailto:Lynn at LStAmour.org ] >>>>> Sent: Friday, April 29, 2016 1:55 PM >>>>> To: Alissa Cooper < alissa at cooperw.in >; Mueller, Milton L < >>>>> milton at gatech.edu >; IANA etc etcCoordination Group >>>> cg at ianacg.org > >>>>> Subject: Re: [Internal-cg] bylaws feedback >>>>> >>>>> Hi Alissa, Milton, all, >>>>> >>>>> I would like to come back to this subject. Specifically, I would like to >>>>> propose that the ICG send in a statement to the By-laws comment period. >>>>> >>>>> Alissa commented on a specific concern (see thread below) and I also >>>>> believe the ICG should be concerned about the overreach in the draft >>>>> bylaws. >>>>> >>>>> My main concerns are: >>>>> >>>>> - the fact that these draft by-laws, through the grand-fathering provisions, >>>>> allow external agreements to define ICANN's Mission which seems like a >>>>> bad idea for many reasons. Further, this contradicts the desires of the >>>>> community (or is a run around the community - intentional or not) who >>>>> worked hard to clarify and correctly state ICANN’s mission throughout the >>>>> IANA Transition process (paragraphs 140-144 of the CCWG-Accountability >>>>> proposal). >>>>> >>>>> - the ICG process was fashioned to ensure that the transition plans reflected >>>>> the consensus of the Internet community. And, it was to respect the roles >>>>> and responsibilities of the OCs in defining their own transition plans. The >>>>> ICG and the CCWG reports define those wishes, and any changes to the >>>>> bylaws were to be to implement those wishes, nothing more. Yet provisions >>>>> in sections >>>>> 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the CCWG- >>>>> Accountability proposals, and so there has not been appropriate >>>>> community involvement or review for those changes. Note: these sections >>>>> affect much of the Internet community, as they apply to agreements >>>>> between ICANN and the ASO, NRO, IETF, Root Zone Maintainer, and PTI. >>>>> >>>>> For transparency: the IAB/IETF are also concerned about the overreach and >>>>> are drafting their own comments, and as an IAB appointee to the ICG, I am >>>>> part of that review as well. >>>>> >>>>> If there is support for the ICG sending in a comment, I would be happy to >>>>> work with Alissa and others to draft something for ICG review. >>>>> >>>>> Regards, >>>>> Lynn >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Apr 12, 2016, at 3:15 PM, Alissa Cooper < alissa at cooperw.in > wrote: >>>>> >>>>> From the minutes it looks like this was discussed on the CCWG call and >>>>> there >>>>> >>>>> >>>>> >>>>> will be follow-up. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Apr 12, 2016, at 8:39 AM, Mueller, Milton L < milton at gatech.edu > >>>>> >>>>> >>>>> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I sent it yesterday but there has been no response at all. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Alissa Cooper [ mailto:alissa at cooperw.in ] >>>>> Sent: Monday, April 11, 2016 4:54 PM >>>>> To: Mueller, Milton L < milton at gatech.edu > >>>>> Cc: IANA etc etcCoordination Group < internal-cg at ianacg.org > >>>>> Subject: Re: [Internal-cg] bylaws feedback >>>>> >>>>> I think that would be fine. >>>>> >>>>> Thanks, >>>>> Alissa >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Apr 11, 2016, at 1:04 PM, Mueller, Milton L < milton at gatech.edu > >>>>> >>>>> >>>>> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Alissa >>>>> If you don't mind I will just forward your message to the bylaws >>>>> and CWG >>>>> >>>>> >>>>> >>>>> lists. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> If there is some other way you want me to do this, please let me know. >>>>> >>>>> --MM >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Internal-cg [ mailto:internal-cg-bounces at ianacg.org ] On >>>>> Behalf Of Alissa Cooper >>>>> Sent: Monday, April 11, 2016 1:49 PM >>>>> To: IANA etc etcCoordination Group < internal-cg at ianacg.org > >>>>> Subject: [Internal-cg] bylaws feedback >>>>> >>>>> I have looked a bit at the draft bylaws and I’d like to ask >>>>> Kavouss and Milton to bring the following issue back to the bylaws >>>>> >>>>> >>>>> >>>>> drafting group: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Section 1.1(d)(ii) incorporates by reference a number of documents >>>>> external to the bylaws as a means to prevent challenges on the >>>>> basis that those documents conflict with or violate the bylaws. In >>>>> particular, bullet (D) applies this provision to "the IANA Naming >>>>> Function Contract between ICANN and PTI effective [October 1, 2016]." >>>>> >>>>> Given the ICG's historical encouragement of the community to meet >>>>> timelines necessary for a successful transition, I find this >>>>> provision to be extremely problematic. It incorporates a reference >>>>> to a document that does not exist yet and that is unlikely to be >>>>> completed by the time the bylaws are supposed to be done (early >>>>> June). In fact, it is not even clear at this point whether the new >>>>> ICANN affiliate to be setup will be name "PTI" or have some other >>>>> name. I don't understand how anyone can reason about whether >>>>> 1.1(d)(ii) is an acceptable bylaws provision if it references a >>>>> document that has not been written. (This also applies to (B) and >>>>> (C) since it could apply to future documents that haven’t been >>>>> written >>>>> yet.) >>>>> >>>>> Furthermore, I question whether it is a sound decision to >>>>> essentially allow for documents external to the bylaws to be able >>>>> to modify the bylaws (under (F)). This section would make more >>>>> sense if it was entirely internally specified, without the >>>>> references to external documents. At a minimum, I think we should >>>>> recommend that (D) be >>>>> >>>>> >>>>> >>>>> removed. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> Alissa >>>>> _______________________________________________ >>>>> Internal-cg mailing list >>>>> Internal-cg at mm.ianacg.org >>>>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >>>>> >>>>> >>>>> _______________________________________________ >>>>> Internal-cg mailing list >>>>> Internal-cg at mm.ianacg.org >>>>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >>>>> >>>>> _______________________________________________ >>>>> Internal-cg mailing list >>>>> Internal-cg at mm.ianacg.org >>>>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >>>> _______________________________________________ >>>> Internal-cg mailing list >>>> Internal-cg at mm.ianacg.org >>>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >>> >>> _______________________________________________ >>> Internal-cg mailing list >>> Internal-cg at mm.ianacg.org >>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >> >> >> _______________________________________________ >> Internal-cg mailing list >> Internal-cg at mm.ianacg.org >> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org > > > _______________________________________________ > Internal-cg mailing list > Internal-cg at mm.ianacg.org > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From narelle.clark at accan.org.au Fri May 13 07:29:13 2016 From: narelle.clark at accan.org.au (Narelle Clark) Date: Fri, 13 May 2016 17:29:13 +1000 Subject: [Internal-cg] bylaws feedback In-Reply-To: <9B260ABE-EA98-4DD3-B8A5-2510C600CFAF@cooperw.in> References: <142976331.139.1462343299764.JavaMail.jjs-mac-2@macbook-air-de-jean-jacques-2.home> <7146C0FDA8771A43BEB20E18700C2E4F0181AF71AF3A@ACCAN01.accan.local> <9B260ABE-EA98-4DD3-B8A5-2510C600CFAF@cooperw.in> Message-ID: <7146C0FDA8771A43BEB20E18700C2E4F0181AF71B2F4@ACCAN01.accan.local> This message looks ready to send. As they say "ship it". Narelle Clark > -----Original Message----- > From: Alissa Cooper [mailto:alissa at cooperw.in] > Sent: Thursday, 12 May 2016 5:11 AM > To: Kavouss Arasteh > Cc: Narelle Clark; IANA etc etcCoordination Group; Milton L Mueller; Lynn > St.Amour > Subject: Re: [Internal-cg] bylaws feedback > > I’d like us to close out on this. If anyone objects to us submitting the text > below as a public comment on the draft bylaws, please say so by Friday, > May 13 at 23:59. If there are no objections, I’ll submit it. > > --- > > The ICG appreciates the opportunity to comment on the draft ICANN > Bylaws. > > The ICG previously communicated concerns about Section 1.1(d)(ii) to the > Bylaws drafting group [1]. However, these concerns were not addressed in > the draft Bylaws that were posted for public comment. > > Section 1.1(d) "grandfathers" a number of agreements into the Bylaws in > order to prevent parties from challenging those agreements on the basis > that they violate the ICANN Mission statement. Under Section 1.1(d)(ii), (A) > applies to RA/RAA agreements; (B)-(D) apply to agreements between ICANN > and the NRO, ASO, IETF, RZM, and PTI; and (E) applies to ICANN's Five-Year > Strategic Plan and Five-Year Operating Plan. (F) applies the grandfathering > to renewals of the agreements appearing in (B)-(E). > > The ICG process was fashioned to ensure that the transition plans reflected > the consensus of the Internet community and allowed the operational > communities to define their own transition plans. The ICG and the CCWG > proposals define those wishes, and any changes to the Bylaws were to be to > implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are > outside the scope of both the ICG and the CCWG proposals. Unlike Section > 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is > documented in paragraph 147 of the CCWG proposal, the substance of (B)- > (E) have not enjoyed appropriate community involvement or review. These > sections affect much of the Internet community since they apply to > agreements with a variety of external parties, including all of the > operational communities. > > Because several of the referenced agreements have not yet been written > and most have not yet been agreed to by the relevant parties, the draft > Bylaws essentially allow these external agreements to define ICANN's > Mission. This seems like a bad idea for many reasons, not the least of which > is that it creates the possibility for the agreements to contradict or > circumvent the desires of the community who worked hard to clarify and > correctly state ICANN’s Mission throughout the IANA stewardship > transition process (see paragraphs 140-147 of the CCWG proposal). > > The ICG believes that in order for the Bylaws to be considered consistent > with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and > Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). > This assumes that (F) is indeed called for by paragraph 147 of the CCWG > proposal, which we leave for the CCWG to judge. > > Regards, > > Alissa Cooper on behalf of the ICG > > > > > On May 6, 2016, at 2:59 AM, Kavouss Arasteh > wrote: > > > > Jean Jaques > > Tks > > This is what I and you pushed since long time but have not yet been > > heard Kavousd > > > > Sent from my iPhone > > > >> On 5 May 2016, at 09:43, Narelle Clark > wrote: > >> > >> Jean-Jacques has the rationale exactly. > >> > >> +1 > >> > >> Narelle > >> > >> > >>> -----Original Message----- > >>> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf > >>> Of Subrenat, Jean-Jacques > >>> Sent: Wednesday, 4 May 2016 4:28 PM > >>> To: Martin Boyle > >>> Cc: Lynn St.Amour; Milton L Mueller; IANA etc etcCoordination Group > >>> Subject: Re: [Internal-cg] bylaws feedback > >>> > >>> Hello Alissa & All, > >>> > >>> I support the draft as it now stands, in order to > >>> - warn against any initiative or mechanism which would endanger the > >>> Transition proposal before it has even been thoroughly vetted in > >>> Washington, > >>> - underline the risk of the ICANN Mission being susceptible to > >>> modification by external texts or undertakings, some of which are > >>> not yet in existence, > >>> - demand the withdrawal of Sections 1.1(d)(ii)(B)-(E), and the > >>> modification of Section 1.1(d)(ii)(F) so as to apply only to Section > 1.1(d)(ii)(A). > >>> > >>> Best regards, > >>> Jean-Jacques. > >>> > >>> > >>> > >>> > >>> ----- Mail original ----- > >>> De: "Martin Boyle" > >>> À: "Alissa Cooper" , "Milton L Mueller" > >>> > >>> Cc: "Lynn St.Amour" , "IANA etc > etcCoordination > >>> Group" > >>> Envoyé: Mercredi 4 Mai 2016 00:15:40 > >>> Objet: Re: [Internal-cg] bylaws feedback > >>> > >>> > >>> > >>> > >>> > >>> Hi Alissa, all, > >>> > >>> > >>> > >>> I agree with you, Alissa. This sort of detail does seem to me to go > >>> well beyond the remit of the ICG and we should certainly not be > >>> seeking to upset areas already agreed in the CCWG-Accountability > process. > >>> > >>> > >>> > >>> For the rest of this, I am afraid I have not been following the CCWG > >>> process carefully enough to have a view of where the text bylaw > >>> drafting goes beyond the consensus of the proposal. I’ll try to look > >>> at it tomorrow, but on my cursory reading of the arguments below, > >>> this does look like a legitimate input from the ICG. > >>> > >>> > >>> > >>> Hope this helps > >>> > >>> > >>> > >>> Martin > >>> > >>> > >>> > >>> > >>> > >>> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf > >>> Of Alissa Cooper > >>> Sent: 03 May 2016 22:10 > >>> To: Mueller, Milton L > >>> Cc: Lynn St.Amour ; IANA etc etcCoordination > >>> Group > >>> Subject: Re: [Internal-cg] bylaws feedback > >>> > >>> > >>> > >>> > >>> I don’t have an opinion about the substance of the RA/RAA renewals, > >>> but I don’t think they are within the scope of what the ICG should > comment on. > >>> > >>> > >>> > >>> > >>> > >>> The renewal of RA and RAA agreements were discussed on today’s > CCWG > >>> call (as well as on several previous CCWG calls and the CCWG mailing > >>> list). It appears that the CCWG will be commenting on these renewals > >>> in its own comments about the Bylaws, and will be supporting the > >>> existing language in > >>> (F) as it applies to the RA and RAA agreements. Considering that the > >>> CCWG appears to have discussed this topic at great length and has > >>> consensus on it, I don’t think the same argument we are making about > >>> (B)-(E) applies to the RA/RAA renewals. > >>> > >>> > >>> > >>> > >>> > >>> The CCWG is planning to submit its comments by May 10, so there > >>> should be more clarity about exactly what they intend to say soon. > >>> > >>> > >>> > >>> > >>> > >>> Alissa > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> On May 3, 2016, at 9:59 AM, Mueller, Milton L < milton at gatech.edu > > >>> wrote: > >>> > >>> > >>> > >>> > >>> > >>> (F) applies the grandfathering to renewals of the agreements > >>> appearing in (B)-(D). > >>> > >>> > >>> > >>> > >>> > >>> MM: not correct: (F) applies the grandfathering to renewals of A – > >>> D. It > >>> reads: > >>> > >>> > >>> > >>> > >>> > >>> “(F) any renewals of agreements described in subsections (A)-(D) > >>> pursuant to their terms and conditions for renewal.” > >>> > >>> > >>> > >>> > >>> > >>> As I said in my initial comment, renewals of RA and RAA agreements > >>> are the most susceptible to bypassing mission limitations, because > >>> ICANN has the most expansive powers over names and the names > >>> community, unlike numbers and protocols, has not created a viable > >>> mechanism for changing the IFO. > >>> > >>> > >>> > >>> > >>> > >>> Picture this scenario: ICANN adds a highly regulatory requirement to > >>> the .com contract renewal; requiring it to pre-screen content in all > >>> .com second- level registrations. We might say, “this obviously > >>> violates the prohibition of content regulation in the mission > >>> statement,” but ICANN legal replies: “oh no, this is a renewal of > >>> the com agreement and therefore it is exempt from any such > challenge.” > >>> > >>> > >>> > >>> > >>> > >>> If someone can show me that I am wrong legally about this > >>> possibility I’d be happy to drop it. But I haven’t seen any > >>> convincing arguments as to how this would not be possible. > >>> > >>> > >>> > >>> > >>> > >>> Therefore it would be extremely difficult for me to sign on to this > >>> statement if it does not mention the RA/RAA renewals problem and I > >>> frankly think we’d be missing the boat in a big way. > >>> > >>> > >>> > >>> > >>> > >>> --MM > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> The ICG process was fashioned to ensure that the transition plans > >>> reflected the consensus of the Internet community and allowed the > >>> operational communities to define their own transition plans. The > >>> ICG and the CCWG proposals define those wishes, and any changes to > >>> the Bylaws were to be to implement those wishes, nothing more. Yet > >>> Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and > >>> the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of > >>> which was debated in the CCWG and is documented in paragraph 147 > of > >>> the CCWG proposal, the substance of (B)- > >>> (E) have not enjoyed appropriate community involvement or review. > >>> These sections affect much of the Internet community since they > >>> apply to agreements with a variety of external parties, including > >>> all of the operational communities. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Because several of the referenced agreements have not yet been > >>> written and most have not yet been agreed to by the relevant > >>> parties, the draft Bylaws essentially allow these external > >>> agreements to define ICANN's Mission. This seems like a bad idea for > >>> many reasons, not the least of which is that it creates the > >>> possibility for the agreements to contradict or circumvent the > >>> desires of the community who worked hard to clarify and correctly > >>> state ICANN’s Mission throughout the IANA stewardship transition > process (see paragraphs 140-147 of the CCWG proposal). > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> The ICG believes that in order for the Bylaws to be considered > >>> consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) > >>> need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to > apply only to Section 1.1(d)(ii)(A). > >>> This assumes that (F) is indeed called for by paragraph 147 of the > >>> CCWG proposal, which we leave for the CCWG to judge. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Regards, > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Alissa Cooper on behalf of the ICG > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> [1] http://mm.icann.org/pipermail/cwg-stewardship/2016- > >>> April/004877.html > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> On Apr 30, 2016, at 8:16 AM, Mueller, Milton L < milton at gatech.edu > > >>> wrote: > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Ok, I have had time to read the transcript. I am even more strongly > >>> committed to developing a comment as ICG. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Alissa said on the call that 1.1.d.(ii) “creates a giant loophole > >>> that allows all of the work that was done to more precisely define > >>> the mission statement of ICANN in these bylaws ...to be completely > >>> contravened by whatever gets written into the ICANN PTI contract > >>> Because what this is says is that no one in the future will ever be > >>> able to challenge that contract on the basis that it contravenes the > mission.” > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> [and, I might add, the RZM contract, and renewals of registry > contracts]. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> The only answer I saw to this was that we don’t need to worry about > >>> it because the PTI contract will be put up for public comment. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Alissa also made the point: > >>> > >>> > >>> > >>> "this memo ... seems to imply that ... the most important thing out > >>> of all of this is that ICANN can continue to perform the IANA > >>> function. And I think what we all learned in (unintelligible) in > >>> terms of what the ICG proposal says is that in fact that is not the > >>> most important thing. The most important thing is that the IANA > >>> functions can continue to be performed by some operator who’s > >>> capable of performing them according to the service level agreements > >>> that the community ...has. And those two things are not the same. > >>> And I certainly –I will put my IETF hat on here for a second and say > >>> that I think from an IETF perspective the important thing is that a > >>> protocol parameters functions can continue to be performed, not that > they can only continue to be performed by ICANN." > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> I don't think this argument of Alissa was ever answered. It seems > >>> like there could be ways of drafting these sections that do not > >>> commit us to a specific contract but makes it clear that performance > >>> of the IANA functions is not challengable as a mission violation so > >>> long as the community actually wants ICANN to perform those > functions. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Indeed, I am having trouble understanding the threat that these > >>> sections are supposed to avoid. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> However, the most dangerous mission-limitation-busting potential is > >>> in the renewals section (F). This is problematic partly because the > >>> CCWG never agreed to exempt renewals. We agreed to grandfather > >>> existing agreements, for the sake of stability. But the assumption > >>> was that if anything in these existing agreements contravened the > >>> new mission limitations, that they COULD be challenged during a > >>> renewal process. A contract renewal with a registry could include > >>> all kinds of regulatory measures that exceed the mission, and if > >>> these measures are framed as a "renewal of an existing agreement" > then ICANN could in principle get away with anything. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> So I hope we are able to make it clear to ICANN and the CCWG that > >>> these provisions need to be changed.. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> From: Alissa Cooper [ mailto:alissa at cooperw.in ] > >>> Sent: Friday, April 29, 2016 3:00 PM > >>> To: Mueller, Milton L < milton at gatech.edu > > >>> Cc: Lynn St.Amour < Lynn at LStAmour.org >; IANA etc etcCoordination > >>> Group < internal-cg at ianacg.org > > >>> Subject: Re: [Internal-cg] bylaws feedback > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> For folks following this issue, it is definitely worth reading the > >>> transcript or listening to the recording of the last CCWG call: > >>> > https://community.icann.org/pages/viewpage.action?pageId=58730392 > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> The more that I have thought about this, it has become clear to me > >>> that the core issue here is that there is a portion of bylaws > >>> section 1.1(d) that is not called for either by our proposal or by the > CCWG proposal, as Lynn says. > >>> Had the content of 1.1(d)(ii)(B-E) been discussed as part of the > >>> transition proposal development, I think the concerns being raised > >>> now would have been raised then, and the whole community would > have > >>> had time to sort them out. (I note that there was an extended > >>> discussion about RA/RAA agreements in the CCWG and that did result > >>> in text in its proposal in paragraph 147, which is reflected in > >>> 1.1(d)(ii)(A). But that does not extend to any other agreements.) > >>> Sections 1.1(d)(ii)(B-E) seem to have been created out of whole > >>> cloth by the bylaws drafting team, and that was not within their > >>> remit in my opinion. The Bylaws are just supposed to implement the > proposals. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> I think there are substantive issues too, but from an ICG > >>> perspective we may or may not want to focus on those. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> I would support sending a comment. We sent a message early on > during > >>> the bylaws drafting and received no response, and the call to > >>> discuss this didn’t even occur until after the bylaws were put out for > public comment. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Alissa > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> On Apr 29, 2016, at 11:17 AM, Mueller, Milton L < milton at gatech.edu > >>> > > >>> wrote: > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> I support what you are saying. I take it you are not satisfied with > >>> the lawyers' explanation? I was not able to attend the 0:400 call a > >>> few days ago so was not able to question them about it or hear their > answers. > >>> > >>> --MM > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Lynn St.Amour [ mailto:Lynn at LStAmour.org ] > >>> Sent: Friday, April 29, 2016 1:55 PM > >>> To: Alissa Cooper < alissa at cooperw.in >; Mueller, Milton L < > >>> milton at gatech.edu >; IANA etc etcCoordination Group >>> cg at ianacg.org > > >>> Subject: Re: [Internal-cg] bylaws feedback > >>> > >>> Hi Alissa, Milton, all, > >>> > >>> I would like to come back to this subject. Specifically, I would > >>> like to propose that the ICG send in a statement to the By-laws > comment period. > >>> > >>> Alissa commented on a specific concern (see thread below) and I also > >>> believe the ICG should be concerned about the overreach in the draft > >>> bylaws. > >>> > >>> My main concerns are: > >>> > >>> - the fact that these draft by-laws, through the grand-fathering > >>> provisions, allow external agreements to define ICANN's Mission > >>> which seems like a bad idea for many reasons. Further, this > >>> contradicts the desires of the community (or is a run around the > >>> community - intentional or not) who worked hard to clarify and > >>> correctly state ICANN’s mission throughout the IANA Transition > >>> process (paragraphs 140-144 of the CCWG-Accountability proposal). > >>> > >>> - the ICG process was fashioned to ensure that the transition plans > >>> reflected the consensus of the Internet community. And, it was to > >>> respect the roles and responsibilities of the OCs in defining their > >>> own transition plans. The ICG and the CCWG reports define those > >>> wishes, and any changes to the bylaws were to be to implement those > >>> wishes, nothing more. Yet provisions in sections > >>> 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the > >>> CCWG- Accountability proposals, and so there has not been > >>> appropriate community involvement or review for those changes. > Note: > >>> these sections affect much of the Internet community, as they apply > >>> to agreements between ICANN and the ASO, NRO, IETF, Root Zone > Maintainer, and PTI. > >>> > >>> For transparency: the IAB/IETF are also concerned about the > >>> overreach and are drafting their own comments, and as an IAB > >>> appointee to the ICG, I am part of that review as well. > >>> > >>> If there is support for the ICG sending in a comment, I would be > >>> happy to work with Alissa and others to draft something for ICG > review. > >>> > >>> Regards, > >>> Lynn > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> On Apr 12, 2016, at 3:15 PM, Alissa Cooper < alissa at cooperw.in > > wrote: > >>> > >>> From the minutes it looks like this was discussed on the CCWG call > >>> and there > >>> > >>> > >>> > >>> will be follow-up. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> On Apr 12, 2016, at 8:39 AM, Mueller, Milton L < milton at gatech.edu > > >>> > >>> > >>> > >>> wrote: > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> I sent it yesterday but there has been no response at all. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Alissa Cooper [ mailto:alissa at cooperw.in ] > >>> Sent: Monday, April 11, 2016 4:54 PM > >>> To: Mueller, Milton L < milton at gatech.edu > > >>> Cc: IANA etc etcCoordination Group < internal-cg at ianacg.org > > >>> Subject: Re: [Internal-cg] bylaws feedback > >>> > >>> I think that would be fine. > >>> > >>> Thanks, > >>> Alissa > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> On Apr 11, 2016, at 1:04 PM, Mueller, Milton L < milton at gatech.edu > > >>> > >>> > >>> > >>> wrote: > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Alissa > >>> If you don't mind I will just forward your message to the bylaws and > >>> CWG > >>> > >>> > >>> > >>> lists. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> If there is some other way you want me to do this, please let me know. > >>> > >>> --MM > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Internal-cg [ mailto:internal-cg-bounces at ianacg.org ] On > >>> Behalf Of Alissa Cooper > >>> Sent: Monday, April 11, 2016 1:49 PM > >>> To: IANA etc etcCoordination Group < internal-cg at ianacg.org > > >>> Subject: [Internal-cg] bylaws feedback > >>> > >>> I have looked a bit at the draft bylaws and I’d like to ask Kavouss > >>> and Milton to bring the following issue back to the bylaws > >>> > >>> > >>> > >>> drafting group: > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Section 1.1(d)(ii) incorporates by reference a number of documents > >>> external to the bylaws as a means to prevent challenges on the basis > >>> that those documents conflict with or violate the bylaws. In > >>> particular, bullet (D) applies this provision to "the IANA Naming > >>> Function Contract between ICANN and PTI effective [October 1, 2016]." > >>> > >>> Given the ICG's historical encouragement of the community to meet > >>> timelines necessary for a successful transition, I find this > >>> provision to be extremely problematic. It incorporates a reference > >>> to a document that does not exist yet and that is unlikely to be > >>> completed by the time the bylaws are supposed to be done (early > >>> June). In fact, it is not even clear at this point whether the new > >>> ICANN affiliate to be setup will be name "PTI" or have some other > >>> name. I don't understand how anyone can reason about whether > >>> 1.1(d)(ii) is an acceptable bylaws provision if it references a > >>> document that has not been written. (This also applies to (B) and > >>> (C) since it could apply to future documents that haven’t been > >>> written > >>> yet.) > >>> > >>> Furthermore, I question whether it is a sound decision to > >>> essentially allow for documents external to the bylaws to be able to > >>> modify the bylaws (under (F)). This section would make more sense if > >>> it was entirely internally specified, without the references to > >>> external documents. At a minimum, I think we should recommend that > >>> (D) be > >>> > >>> > >>> > >>> removed. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> Thanks, > >>> Alissa > >>> _______________________________________________ > >>> Internal-cg mailing list > >>> Internal-cg at mm.ianacg.org > >>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org > >>> > >>> > >>> _______________________________________________ > >>> Internal-cg mailing list > >>> Internal-cg at mm.ianacg.org > >>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org > >>> > >>> _______________________________________________ > >>> Internal-cg mailing list > >>> Internal-cg at mm.ianacg.org > >>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org > >> _______________________________________________ > >> Internal-cg mailing list > >> Internal-cg at mm.ianacg.org > >> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org > > > > _______________________________________________ > > Internal-cg mailing list > > Internal-cg at mm.ianacg.org > > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org From alissa at cooperw.in Fri May 13 23:21:04 2016 From: alissa at cooperw.in (Alissa Cooper) Date: Fri, 13 May 2016 16:21:04 -0700 Subject: [Internal-cg] bylaws feedback In-Reply-To: <7146C0FDA8771A43BEB20E18700C2E4F0181AF71B2F4@ACCAN01.accan.local> References: <142976331.139.1462343299764.JavaMail.jjs-mac-2@macbook-air-de-jean-jacques-2.home> <7146C0FDA8771A43BEB20E18700C2E4F0181AF71AF3A@ACCAN01.accan.local> <9B260ABE-EA98-4DD3-B8A5-2510C600CFAF@cooperw.in> <7146C0FDA8771A43BEB20E18700C2E4F0181AF71B2F4@ACCAN01.accan.local> Message-ID: <26484619-C6AE-4206-856C-D18F1323BDCF@cooperw.in> Sent. https://forum.icann.org/lists/comments-draft-new-bylaws-21apr16/msg00006.html Thanks all. Alissa > On May 13, 2016, at 12:29 AM, Narelle Clark wrote: > > This message looks ready to send. > > As they say "ship it". > > > Narelle Clark > > >> -----Original Message----- >> From: Alissa Cooper [mailto:alissa at cooperw.in] >> Sent: Thursday, 12 May 2016 5:11 AM >> To: Kavouss Arasteh >> Cc: Narelle Clark; IANA etc etcCoordination Group; Milton L Mueller; Lynn >> St.Amour >> Subject: Re: [Internal-cg] bylaws feedback >> >> I’d like us to close out on this. If anyone objects to us submitting the text >> below as a public comment on the draft bylaws, please say so by Friday, >> May 13 at 23:59. If there are no objections, I’ll submit it. >> >> --- >> >> The ICG appreciates the opportunity to comment on the draft ICANN >> Bylaws. >> >> The ICG previously communicated concerns about Section 1.1(d)(ii) to the >> Bylaws drafting group [1]. However, these concerns were not addressed in >> the draft Bylaws that were posted for public comment. >> >> Section 1.1(d) "grandfathers" a number of agreements into the Bylaws in >> order to prevent parties from challenging those agreements on the basis >> that they violate the ICANN Mission statement. Under Section 1.1(d)(ii), (A) >> applies to RA/RAA agreements; (B)-(D) apply to agreements between ICANN >> and the NRO, ASO, IETF, RZM, and PTI; and (E) applies to ICANN's Five-Year >> Strategic Plan and Five-Year Operating Plan. (F) applies the grandfathering >> to renewals of the agreements appearing in (B)-(E). >> >> The ICG process was fashioned to ensure that the transition plans reflected >> the consensus of the Internet community and allowed the operational >> communities to define their own transition plans. The ICG and the CCWG >> proposals define those wishes, and any changes to the Bylaws were to be to >> implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are >> outside the scope of both the ICG and the CCWG proposals. Unlike Section >> 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is >> documented in paragraph 147 of the CCWG proposal, the substance of (B)- >> (E) have not enjoyed appropriate community involvement or review. These >> sections affect much of the Internet community since they apply to >> agreements with a variety of external parties, including all of the >> operational communities. >> >> Because several of the referenced agreements have not yet been written >> and most have not yet been agreed to by the relevant parties, the draft >> Bylaws essentially allow these external agreements to define ICANN's >> Mission. This seems like a bad idea for many reasons, not the least of which >> is that it creates the possibility for the agreements to contradict or >> circumvent the desires of the community who worked hard to clarify and >> correctly state ICANN’s Mission throughout the IANA stewardship >> transition process (see paragraphs 140-147 of the CCWG proposal). >> >> The ICG believes that in order for the Bylaws to be considered consistent >> with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and >> Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). >> This assumes that (F) is indeed called for by paragraph 147 of the CCWG >> proposal, which we leave for the CCWG to judge. >> >> Regards, >> >> Alissa Cooper on behalf of the ICG >> >> >> >>> On May 6, 2016, at 2:59 AM, Kavouss Arasteh >> wrote: >>> >>> Jean Jaques >>> Tks >>> This is what I and you pushed since long time but have not yet been >>> heard Kavousd >>> >>> Sent from my iPhone >>> >>>> On 5 May 2016, at 09:43, Narelle Clark >> wrote: >>>> >>>> Jean-Jacques has the rationale exactly. >>>> >>>> +1 >>>> >>>> Narelle >>>> >>>> >>>>> -----Original Message----- >>>>> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf >>>>> Of Subrenat, Jean-Jacques >>>>> Sent: Wednesday, 4 May 2016 4:28 PM >>>>> To: Martin Boyle >>>>> Cc: Lynn St.Amour; Milton L Mueller; IANA etc etcCoordination Group >>>>> Subject: Re: [Internal-cg] bylaws feedback >>>>> >>>>> Hello Alissa & All, >>>>> >>>>> I support the draft as it now stands, in order to >>>>> - warn against any initiative or mechanism which would endanger the >>>>> Transition proposal before it has even been thoroughly vetted in >>>>> Washington, >>>>> - underline the risk of the ICANN Mission being susceptible to >>>>> modification by external texts or undertakings, some of which are >>>>> not yet in existence, >>>>> - demand the withdrawal of Sections 1.1(d)(ii)(B)-(E), and the >>>>> modification of Section 1.1(d)(ii)(F) so as to apply only to Section >> 1.1(d)(ii)(A). >>>>> >>>>> Best regards, >>>>> Jean-Jacques. >>>>> >>>>> >>>>> >>>>> >>>>> ----- Mail original ----- >>>>> De: "Martin Boyle" >>>>> À: "Alissa Cooper" , "Milton L Mueller" >>>>> >>>>> Cc: "Lynn St.Amour" , "IANA etc >> etcCoordination >>>>> Group" >>>>> Envoyé: Mercredi 4 Mai 2016 00:15:40 >>>>> Objet: Re: [Internal-cg] bylaws feedback >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Hi Alissa, all, >>>>> >>>>> >>>>> >>>>> I agree with you, Alissa. This sort of detail does seem to me to go >>>>> well beyond the remit of the ICG and we should certainly not be >>>>> seeking to upset areas already agreed in the CCWG-Accountability >> process. >>>>> >>>>> >>>>> >>>>> For the rest of this, I am afraid I have not been following the CCWG >>>>> process carefully enough to have a view of where the text bylaw >>>>> drafting goes beyond the consensus of the proposal. I’ll try to look >>>>> at it tomorrow, but on my cursory reading of the arguments below, >>>>> this does look like a legitimate input from the ICG. >>>>> >>>>> >>>>> >>>>> Hope this helps >>>>> >>>>> >>>>> >>>>> Martin >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf >>>>> Of Alissa Cooper >>>>> Sent: 03 May 2016 22:10 >>>>> To: Mueller, Milton L >>>>> Cc: Lynn St.Amour ; IANA etc etcCoordination >>>>> Group >>>>> Subject: Re: [Internal-cg] bylaws feedback >>>>> >>>>> >>>>> >>>>> >>>>> I don’t have an opinion about the substance of the RA/RAA renewals, >>>>> but I don’t think they are within the scope of what the ICG should >> comment on. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The renewal of RA and RAA agreements were discussed on today’s >> CCWG >>>>> call (as well as on several previous CCWG calls and the CCWG mailing >>>>> list). It appears that the CCWG will be commenting on these renewals >>>>> in its own comments about the Bylaws, and will be supporting the >>>>> existing language in >>>>> (F) as it applies to the RA and RAA agreements. Considering that the >>>>> CCWG appears to have discussed this topic at great length and has >>>>> consensus on it, I don’t think the same argument we are making about >>>>> (B)-(E) applies to the RA/RAA renewals. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The CCWG is planning to submit its comments by May 10, so there >>>>> should be more clarity about exactly what they intend to say soon. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Alissa >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On May 3, 2016, at 9:59 AM, Mueller, Milton L < milton at gatech.edu > >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> (F) applies the grandfathering to renewals of the agreements >>>>> appearing in (B)-(D). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> MM: not correct: (F) applies the grandfathering to renewals of A – >>>>> D. It >>>>> reads: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> “(F) any renewals of agreements described in subsections (A)-(D) >>>>> pursuant to their terms and conditions for renewal.” >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> As I said in my initial comment, renewals of RA and RAA agreements >>>>> are the most susceptible to bypassing mission limitations, because >>>>> ICANN has the most expansive powers over names and the names >>>>> community, unlike numbers and protocols, has not created a viable >>>>> mechanism for changing the IFO. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Picture this scenario: ICANN adds a highly regulatory requirement to >>>>> the .com contract renewal; requiring it to pre-screen content in all >>>>> .com second- level registrations. We might say, “this obviously >>>>> violates the prohibition of content regulation in the mission >>>>> statement,” but ICANN legal replies: “oh no, this is a renewal of >>>>> the com agreement and therefore it is exempt from any such >> challenge.” >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> If someone can show me that I am wrong legally about this >>>>> possibility I’d be happy to drop it. But I haven’t seen any >>>>> convincing arguments as to how this would not be possible. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Therefore it would be extremely difficult for me to sign on to this >>>>> statement if it does not mention the RA/RAA renewals problem and I >>>>> frankly think we’d be missing the boat in a big way. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> --MM >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The ICG process was fashioned to ensure that the transition plans >>>>> reflected the consensus of the Internet community and allowed the >>>>> operational communities to define their own transition plans. The >>>>> ICG and the CCWG proposals define those wishes, and any changes to >>>>> the Bylaws were to be to implement those wishes, nothing more. Yet >>>>> Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and >>>>> the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of >>>>> which was debated in the CCWG and is documented in paragraph 147 >> of >>>>> the CCWG proposal, the substance of (B)- >>>>> (E) have not enjoyed appropriate community involvement or review. >>>>> These sections affect much of the Internet community since they >>>>> apply to agreements with a variety of external parties, including >>>>> all of the operational communities. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Because several of the referenced agreements have not yet been >>>>> written and most have not yet been agreed to by the relevant >>>>> parties, the draft Bylaws essentially allow these external >>>>> agreements to define ICANN's Mission. This seems like a bad idea for >>>>> many reasons, not the least of which is that it creates the >>>>> possibility for the agreements to contradict or circumvent the >>>>> desires of the community who worked hard to clarify and correctly >>>>> state ICANN’s Mission throughout the IANA stewardship transition >> process (see paragraphs 140-147 of the CCWG proposal). >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The ICG believes that in order for the Bylaws to be considered >>>>> consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) >>>>> need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to >> apply only to Section 1.1(d)(ii)(A). >>>>> This assumes that (F) is indeed called for by paragraph 147 of the >>>>> CCWG proposal, which we leave for the CCWG to judge. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Alissa Cooper on behalf of the ICG >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> [1] http://mm.icann.org/pipermail/cwg-stewardship/2016- >>>>> April/004877.html >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Apr 30, 2016, at 8:16 AM, Mueller, Milton L < milton at gatech.edu > >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Ok, I have had time to read the transcript. I am even more strongly >>>>> committed to developing a comment as ICG. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Alissa said on the call that 1.1.d.(ii) “creates a giant loophole >>>>> that allows all of the work that was done to more precisely define >>>>> the mission statement of ICANN in these bylaws ...to be completely >>>>> contravened by whatever gets written into the ICANN PTI contract >>>>> Because what this is says is that no one in the future will ever be >>>>> able to challenge that contract on the basis that it contravenes the >> mission.” >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> [and, I might add, the RZM contract, and renewals of registry >> contracts]. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The only answer I saw to this was that we don’t need to worry about >>>>> it because the PTI contract will be put up for public comment. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Alissa also made the point: >>>>> >>>>> >>>>> >>>>> "this memo ... seems to imply that ... the most important thing out >>>>> of all of this is that ICANN can continue to perform the IANA >>>>> function. And I think what we all learned in (unintelligible) in >>>>> terms of what the ICG proposal says is that in fact that is not the >>>>> most important thing. The most important thing is that the IANA >>>>> functions can continue to be performed by some operator who’s >>>>> capable of performing them according to the service level agreements >>>>> that the community ...has. And those two things are not the same. >>>>> And I certainly –I will put my IETF hat on here for a second and say >>>>> that I think from an IETF perspective the important thing is that a >>>>> protocol parameters functions can continue to be performed, not that >> they can only continue to be performed by ICANN." >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I don't think this argument of Alissa was ever answered. It seems >>>>> like there could be ways of drafting these sections that do not >>>>> commit us to a specific contract but makes it clear that performance >>>>> of the IANA functions is not challengable as a mission violation so >>>>> long as the community actually wants ICANN to perform those >> functions. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Indeed, I am having trouble understanding the threat that these >>>>> sections are supposed to avoid. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> However, the most dangerous mission-limitation-busting potential is >>>>> in the renewals section (F). This is problematic partly because the >>>>> CCWG never agreed to exempt renewals. We agreed to grandfather >>>>> existing agreements, for the sake of stability. But the assumption >>>>> was that if anything in these existing agreements contravened the >>>>> new mission limitations, that they COULD be challenged during a >>>>> renewal process. A contract renewal with a registry could include >>>>> all kinds of regulatory measures that exceed the mission, and if >>>>> these measures are framed as a "renewal of an existing agreement" >> then ICANN could in principle get away with anything. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> So I hope we are able to make it clear to ICANN and the CCWG that >>>>> these provisions need to be changed.. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> From: Alissa Cooper [ mailto:alissa at cooperw.in ] >>>>> Sent: Friday, April 29, 2016 3:00 PM >>>>> To: Mueller, Milton L < milton at gatech.edu > >>>>> Cc: Lynn St.Amour < Lynn at LStAmour.org >; IANA etc etcCoordination >>>>> Group < internal-cg at ianacg.org > >>>>> Subject: Re: [Internal-cg] bylaws feedback >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> For folks following this issue, it is definitely worth reading the >>>>> transcript or listening to the recording of the last CCWG call: >>>>> >> https://community.icann.org/pages/viewpage.action?pageId=58730392 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The more that I have thought about this, it has become clear to me >>>>> that the core issue here is that there is a portion of bylaws >>>>> section 1.1(d) that is not called for either by our proposal or by the >> CCWG proposal, as Lynn says. >>>>> Had the content of 1.1(d)(ii)(B-E) been discussed as part of the >>>>> transition proposal development, I think the concerns being raised >>>>> now would have been raised then, and the whole community would >> have >>>>> had time to sort them out. (I note that there was an extended >>>>> discussion about RA/RAA agreements in the CCWG and that did result >>>>> in text in its proposal in paragraph 147, which is reflected in >>>>> 1.1(d)(ii)(A). But that does not extend to any other agreements.) >>>>> Sections 1.1(d)(ii)(B-E) seem to have been created out of whole >>>>> cloth by the bylaws drafting team, and that was not within their >>>>> remit in my opinion. The Bylaws are just supposed to implement the >> proposals. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I think there are substantive issues too, but from an ICG >>>>> perspective we may or may not want to focus on those. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I would support sending a comment. We sent a message early on >> during >>>>> the bylaws drafting and received no response, and the call to >>>>> discuss this didn’t even occur until after the bylaws were put out for >> public comment. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Alissa >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Apr 29, 2016, at 11:17 AM, Mueller, Milton L < milton at gatech.edu >>>>>> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I support what you are saying. I take it you are not satisfied with >>>>> the lawyers' explanation? I was not able to attend the 0:400 call a >>>>> few days ago so was not able to question them about it or hear their >> answers. >>>>> >>>>> --MM >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Lynn St.Amour [ mailto:Lynn at LStAmour.org ] >>>>> Sent: Friday, April 29, 2016 1:55 PM >>>>> To: Alissa Cooper < alissa at cooperw.in >; Mueller, Milton L < >>>>> milton at gatech.edu >; IANA etc etcCoordination Group >>>> cg at ianacg.org > >>>>> Subject: Re: [Internal-cg] bylaws feedback >>>>> >>>>> Hi Alissa, Milton, all, >>>>> >>>>> I would like to come back to this subject. Specifically, I would >>>>> like to propose that the ICG send in a statement to the By-laws >> comment period. >>>>> >>>>> Alissa commented on a specific concern (see thread below) and I also >>>>> believe the ICG should be concerned about the overreach in the draft >>>>> bylaws. >>>>> >>>>> My main concerns are: >>>>> >>>>> - the fact that these draft by-laws, through the grand-fathering >>>>> provisions, allow external agreements to define ICANN's Mission >>>>> which seems like a bad idea for many reasons. Further, this >>>>> contradicts the desires of the community (or is a run around the >>>>> community - intentional or not) who worked hard to clarify and >>>>> correctly state ICANN’s mission throughout the IANA Transition >>>>> process (paragraphs 140-144 of the CCWG-Accountability proposal). >>>>> >>>>> - the ICG process was fashioned to ensure that the transition plans >>>>> reflected the consensus of the Internet community. And, it was to >>>>> respect the roles and responsibilities of the OCs in defining their >>>>> own transition plans. The ICG and the CCWG reports define those >>>>> wishes, and any changes to the bylaws were to be to implement those >>>>> wishes, nothing more. Yet provisions in sections >>>>> 1.1(d)(ii)(B)-(D) are outside the scope of both the ICG and the >>>>> CCWG- Accountability proposals, and so there has not been >>>>> appropriate community involvement or review for those changes. >> Note: >>>>> these sections affect much of the Internet community, as they apply >>>>> to agreements between ICANN and the ASO, NRO, IETF, Root Zone >> Maintainer, and PTI. >>>>> >>>>> For transparency: the IAB/IETF are also concerned about the >>>>> overreach and are drafting their own comments, and as an IAB >>>>> appointee to the ICG, I am part of that review as well. >>>>> >>>>> If there is support for the ICG sending in a comment, I would be >>>>> happy to work with Alissa and others to draft something for ICG >> review. >>>>> >>>>> Regards, >>>>> Lynn >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Apr 12, 2016, at 3:15 PM, Alissa Cooper < alissa at cooperw.in > >> wrote: >>>>> >>>>> From the minutes it looks like this was discussed on the CCWG call >>>>> and there >>>>> >>>>> >>>>> >>>>> will be follow-up. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Apr 12, 2016, at 8:39 AM, Mueller, Milton L < milton at gatech.edu > >>>>> >>>>> >>>>> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I sent it yesterday but there has been no response at all. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Alissa Cooper [ mailto:alissa at cooperw.in ] >>>>> Sent: Monday, April 11, 2016 4:54 PM >>>>> To: Mueller, Milton L < milton at gatech.edu > >>>>> Cc: IANA etc etcCoordination Group < internal-cg at ianacg.org > >>>>> Subject: Re: [Internal-cg] bylaws feedback >>>>> >>>>> I think that would be fine. >>>>> >>>>> Thanks, >>>>> Alissa >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Apr 11, 2016, at 1:04 PM, Mueller, Milton L < milton at gatech.edu > >>>>> >>>>> >>>>> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Alissa >>>>> If you don't mind I will just forward your message to the bylaws and >>>>> CWG >>>>> >>>>> >>>>> >>>>> lists. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> If there is some other way you want me to do this, please let me know. >>>>> >>>>> --MM >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Internal-cg [ mailto:internal-cg-bounces at ianacg.org ] On >>>>> Behalf Of Alissa Cooper >>>>> Sent: Monday, April 11, 2016 1:49 PM >>>>> To: IANA etc etcCoordination Group < internal-cg at ianacg.org > >>>>> Subject: [Internal-cg] bylaws feedback >>>>> >>>>> I have looked a bit at the draft bylaws and I’d like to ask Kavouss >>>>> and Milton to bring the following issue back to the bylaws >>>>> >>>>> >>>>> >>>>> drafting group: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Section 1.1(d)(ii) incorporates by reference a number of documents >>>>> external to the bylaws as a means to prevent challenges on the basis >>>>> that those documents conflict with or violate the bylaws. In >>>>> particular, bullet (D) applies this provision to "the IANA Naming >>>>> Function Contract between ICANN and PTI effective [October 1, 2016]." >>>>> >>>>> Given the ICG's historical encouragement of the community to meet >>>>> timelines necessary for a successful transition, I find this >>>>> provision to be extremely problematic. It incorporates a reference >>>>> to a document that does not exist yet and that is unlikely to be >>>>> completed by the time the bylaws are supposed to be done (early >>>>> June). In fact, it is not even clear at this point whether the new >>>>> ICANN affiliate to be setup will be name "PTI" or have some other >>>>> name. I don't understand how anyone can reason about whether >>>>> 1.1(d)(ii) is an acceptable bylaws provision if it references a >>>>> document that has not been written. (This also applies to (B) and >>>>> (C) since it could apply to future documents that haven’t been >>>>> written >>>>> yet.) >>>>> >>>>> Furthermore, I question whether it is a sound decision to >>>>> essentially allow for documents external to the bylaws to be able to >>>>> modify the bylaws (under (F)). This section would make more sense if >>>>> it was entirely internally specified, without the references to >>>>> external documents. At a minimum, I think we should recommend that >>>>> (D) be >>>>> >>>>> >>>>> >>>>> removed. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> Alissa >>>>> _______________________________________________ >>>>> Internal-cg mailing list >>>>> Internal-cg at mm.ianacg.org >>>>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >>>>> >>>>> >>>>> _______________________________________________ >>>>> Internal-cg mailing list >>>>> Internal-cg at mm.ianacg.org >>>>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >>>>> >>>>> _______________________________________________ >>>>> Internal-cg mailing list >>>>> Internal-cg at mm.ianacg.org >>>>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >>>> _______________________________________________ >>>> Internal-cg mailing list >>>> Internal-cg at mm.ianacg.org >>>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org >>> >>> _______________________________________________ >>> Internal-cg mailing list >>> Internal-cg at mm.ianacg.org >>> http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjs at dyalog.net Tue May 17 10:04:08 2016 From: jjs at dyalog.net (Subrenat, Jean-Jacques) Date: Tue, 17 May 2016 12:04:08 +0200 (CEST) Subject: [Internal-cg] bylaws feedback In-Reply-To: Message-ID: <148977631.3.1463479443672.JavaMail.jjs-mac-2@MacBook-Air-de-Jean-Jacques-2.local> All, this is to inform you that my email by default, jjs at dyalog.net , had a problem but has now been reset properly. If there have been any emails exchanged on this list over the past 5 days, would you be kind enough to send me a copy? Thank you. Best regards, Jean-Jacques. ----- Mail original ----- De: "Russ Housley" À: "Alissa Cooper" Cc: "ICG Group" Envoyé: Vendredi 13 Mai 2016 00:32:06 Objet: Re: [Internal-cg] bylaws feedback Looks ready for sending to me. Russ -----Ursprüngliche Nachricht----- From: Alissa Cooper Sent: Wednesday, May 11, 2016 9:11 PM To: Kavouss Arasteh Cc: Lynn St.Amour ; Milton L Mueller ; IANA etc etcCoordination Group Subject: Re: [Internal-cg] bylaws feedback I’d like us to close out on this. If anyone objects to us submitting the text below as a public comment on the draft bylaws, please say so by Friday, May 13 at 23:59. If there are no objections, I’ll submit it. --- The ICG appreciates the opportunity to comment on the draft ICANN Bylaws. The ICG previously communicated concerns about Section 1.1(d)(ii) to the Bylaws drafting group [1]. However, these concerns were not addressed in the draft Bylaws that were posted for public comment. Section 1.1(d) "grandfathers" a number of agreements into the Bylaws in order to prevent parties from challenging those agreements on the basis that they violate the ICANN Mission statement. Under Section 1.1(d)(ii), (A) applies to RA/RAA agreements; (B)-(D) apply to agreements between ICANN and the NRO, ASO, IETF, RZM, and PTI; and (E) applies to ICANN's Five-Year Strategic Plan and Five-Year Operating Plan. (F) applies the grandfathering to renewals of the agreements appearing in (B)-(E). The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. Regards, Alissa Cooper on behalf of the ICG _______________________________________________ Internal-cg mailing list Internal-cg at mm.ianacg.org http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org From jen at icgsec.asia Tue May 17 12:24:10 2016 From: jen at icgsec.asia (Jennifer Chung) Date: Tue, 17 May 2016 14:24:10 +0200 Subject: [Internal-cg] bylaws feedback In-Reply-To: <148977631.3.1463479443672.JavaMail.jjs-mac-2@MacBook-Air-de-Jean-Jacques-2.local> References: <148977631.3.1463479443672.JavaMail.jjs-mac-2@MacBook-Air-de-Jean-Jacques-2.local> Message-ID: <003001d1b037$051c84e0$0f558ea0$@icgsec.asia> Dear Jean-Jacques, Thank you for letting us know, I'll be forwarding you the emails you have missed off-list. If you experience any further problems with receiving emails from the ICG lists, please do not hesitate to let me know. Best Regards, Jennifer -----Original Message----- From: Internal-cg [mailto:internal-cg-bounces at ianacg.org] On Behalf Of Subrenat, Jean-Jacques Sent: Tuesday, May 17, 2016 12:04 PM To: Russ Housley Cc: ICG Group Subject: Re: [Internal-cg] bylaws feedback All, this is to inform you that my email by default, jjs at dyalog.net , had a problem but has now been reset properly. If there have been any emails exchanged on this list over the past 5 days, would you be kind enough to send me a copy? Thank you. Best regards, Jean-Jacques. ----- Mail original ----- De: "Russ Housley" À: "Alissa Cooper" Cc: "ICG Group" Envoyé: Vendredi 13 Mai 2016 00:32:06 Objet: Re: [Internal-cg] bylaws feedback Looks ready for sending to me. Russ -----Ursprüngliche Nachricht----- From: Alissa Cooper Sent: Wednesday, May 11, 2016 9:11 PM To: Kavouss Arasteh Cc: Lynn St.Amour ; Milton L Mueller ; IANA etc etcCoordination Group Subject: Re: [Internal-cg] bylaws feedback I’d like us to close out on this. If anyone objects to us submitting the text below as a public comment on the draft bylaws, please say so by Friday, May 13 at 23:59. If there are no objections, I’ll submit it. --- The ICG appreciates the opportunity to comment on the draft ICANN Bylaws. The ICG previously communicated concerns about Section 1.1(d)(ii) to the Bylaws drafting group [1]. However, these concerns were not addressed in the draft Bylaws that were posted for public comment. Section 1.1(d) "grandfathers" a number of agreements into the Bylaws in order to prevent parties from challenging those agreements on the basis that they violate the ICANN Mission statement. Under Section 1.1(d)(ii), (A) applies to RA/RAA agreements; (B)-(D) apply to agreements between ICANN and the NRO, ASO, IETF, RZM, and PTI; and (E) applies to ICANN's Five-Year Strategic Plan and Five-Year Operating Plan. (F) applies the grandfathering to renewals of the agreements appearing in (B)-(E). The ICG process was fashioned to ensure that the transition plans reflected the consensus of the Internet community and allowed the operational communities to define their own transition plans. The ICG and the CCWG proposals define those wishes, and any changes to the Bylaws were to be to implement those wishes, nothing more. Yet Sections 1.1(d)(ii)(B)-(E) are outside the scope of both the ICG and the CCWG proposals. Unlike Section 1.1(d)(ii)(A), the substance of which was debated in the CCWG and is documented in paragraph 147 of the CCWG proposal, the substance of (B)-(E) have not enjoyed appropriate community involvement or review. These sections affect much of the Internet community since they apply to agreements with a variety of external parties, including all of the operational communities. Because several of the referenced agreements have not yet been written and most have not yet been agreed to by the relevant parties, the draft Bylaws essentially allow these external agreements to define ICANN's Mission. This seems like a bad idea for many reasons, not the least of which is that it creates the possibility for the agreements to contradict or circumvent the desires of the community who worked hard to clarify and correctly state ICANN’s Mission throughout the IANA stewardship transition process (see paragraphs 140-147 of the CCWG proposal). The ICG believes that in order for the Bylaws to be considered consistent with the transition plans, Sections 1.1(d)(ii)(B)-(E) need to be removed, and Section 1.1(d)(ii)(F) needs to be edited to apply only to Section 1.1(d)(ii)(A). This assumes that (F) is indeed called for by paragraph 147 of the CCWG proposal, which we leave for the CCWG to judge. Regards, Alissa Cooper on behalf of the ICG _______________________________________________ Internal-cg mailing list Internal-cg at mm.ianacg.org http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org _______________________________________________ Internal-cg mailing list Internal-cg at mm.ianacg.org http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org