[Internal-cg] bylaws feedback

[Narelle Clark]

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
> <kavouss.arasteh at gmail.com> 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 <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
> >
> > _______________________________________________
> > Internal-cg mailing list
> > Internal-cg at mm.ianacg.org
> > http://mm.ianacg.org/mailman/listinfo/internal-cg_ianacg.org