[Internal-cg] bylaws feedback

Kavouss Arasteh kavouss.arasteh at gmail.com
Fri May 6 06:59:16 UTC 2016


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 <narelle.clark at accan.org.au> 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" <Martin.Boyle at nominet.uk>
>> À: "Alissa Cooper" <alissa at cooperw.in>, "Milton L Mueller"
>> <milton at gatech.edu>
>> Cc: "Lynn St.Amour" <Lynn at LStAmour.org>, "IANA etc etcCoordination
>> Group" <internal-cg at ianacg.org>
>> 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 <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
>> 
>> 
>> 
>> 
>> 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 <internal-
>> 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



More information about the Internal-cg mailing list