[Internal-cg] bylaws feedback

Narelle Clark narelle.clark at accan.org.au
Thu May 5 07:43:37 UTC 2016


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


More information about the Internal-cg mailing list