Thanks so much, Robin, I wanted to be sure that we did not agree to include renewals.
So I will send my comments to the CCWG list, and to avoid Avri getting crabby I will not say anything about NCSG but you can chime in and agree with them.
--MM
> -----Original Message-----
> From: Robin Gross [mailto:[log in to unmask]]
> Sent: Tuesday, April 5, 2016 11:18 AM
> To: Mueller, Milton L <[log in to unmask]>
> Cc: [log in to unmask]
> Subject: Re: [NCSG-Discuss] HR activists take note: A review of the draft
> bylaws on the mission, core values and commitments
>
> Hi Milton,
>
> Thanks very much for your review of the draft bylaws. I agree that the issue
> of mission limitation is a crucial one and we need to be sure that what CCWG
> agreed to is in fact what makes its way into the bylaws.
>
> After reviewing the materials, I’m concerned that ICANN’s lawyers are using
> “renewals” of the gtld agreement as a way to circumvent the CCWG’s
> carefully crafted mission limitations on ICANN, which was not something that
> CCWG agreed to in our deliberations regarding how to structure the
> “grandfathering” of out-of-mission policies that exist in today's ICANN
> agreements. The “compromise” of permitting those existing agreements to
> go unchallenged for their mission-creep is being stretched to the point of
> cancelling out the mission limitations on ICANN.
>
> There was also a question raised as to whether the "GAC carve-out" should
> apply in a board member removal process when the board member is
> subject to a removal process because of a vote in support of a GAC
> Consensus Resolution. As the intent of the GAC carve-out is to prevent “two
> bites at the apple” by GAC on a single issue, giving GAC a vote to remove a
> board member who doesn’t comply with GAC advice seems to go against the
> intent of the GAC carve-out. While CCWG didn’t explicitly deal with this issue
> one way or the other, now that it has been noticed, it needs to be thought
> through before we decide one way or the other.
>
> But overall, from my initial read, the draft bylaws are pretty good in terms of
> being faithful to what CCWG agreed to.
>
> Best,
> Robin
>
>
> > On Apr 5, 2016, at 7:08 AM, Mueller, Milton L <[log in to unmask]>
> wrote:
> >
> > Let me reply to Avri, Ed and Niels in the same message.
> >
> > Niels: good to know the HR language seems ok to you. Does Tatiana agree
> with you? Do you have any concerns about the mission limitation exemptions
> I identified?
> >
> > Avri: The language about what was acceptable to NCSG was suggested, and
> comments sent to the list to see if people agreed.
> >
> > Avri and Ed: I am focused exclusively on the mission limitations language in
> Article 1. To provide feedback on that, you do not need to read every little
> detail in the 200+ page bylaws, e.g., how the escalation process works or how
> a SCWG is formed. Are you able to give me a sense of whether the mission
> has been limited properly or whether Appendix G exemptions are too
> broad?
> >
> > --MM
> >
> >> -----Original Message-----
> >> From: Niels ten Oever [mailto:[log in to unmask]]
> >> Sent: Monday, April 4, 2016 1:57 PM
> >> To: Mueller, Milton L <[log in to unmask]>; NCSG-
> >> [log in to unmask]
> >> Subject: Re: HR activists take note: A review of the draft bylaws on
> >> the mission, core values and commitments
> >>
> >> Hi Milton,
> >>
> >> Am at IETF meeting so have a bit of limited time, so I focused on the HR
> work.
> >> I don't see any changes between the HR langugage suggested in CCWG
> >> report and the proposed bylaw language. So, no comments from me.
> >>
> >> Best,
> >>
> >> Niels
> >>
> >> On 04/04/2016 07:21 PM, Mueller, Milton L wrote:
> >>> I want to send these comments to the bylaws coordination group soon.
> >>> There have been no substantive comments so far but I know it's only
> >>> 24 hours. Should I wait? Is anyone planning to comment?
> >>>
> >>> --MM
> >>>
> >>>
> >>>
> >>> *From:* NCSG-Discuss [mailto:[log in to unmask]] *On
> >> Behalf
> >>> Of *Mueller, Milton L
> >>> *Sent:* Sunday, April 3, 2016 1:56 PM
> >>> *To:* [log in to unmask]
> >>> *Subject:* HR activists take note: A review of the draft bylaws on
> >>> the mission, core values and commitments
> >>>
> >>>
> >>>
> >>> THE PROPOSED NEW BYLAWS ON MISSION, CORE VALUES AND
> >> COMMITMENTS
> >>>
> >>>
> >>>
> >>> We received the draft bylaws this morning. I have only had time to
> >>> review Article 1, which is important because it contains the
> >>> mission, etc. I advance my initial ideas and will get feedback here
> >>> before posting to the CCWG or bylaws-coord list.
> >>>
> >>>
> >>>
> >>> In general, the Mission, Core Values and Commitments bylaw language
> >>> has been faithfully drafted to reflect the concerns of the CCWG.
> >>> There are three major exceptions/problems. One is the section on
> >>> renewals [Section 1.1, (d) (ii) F], the other two are Appendices G1 and
> G2.
> >>>
> >>>
> >>>
> >>> Section 1.1 (d) (ii) F
> >>>
> >>>
> >>>
> >>> "any renewals of agreements described in subsections (A)-(D)
> >>> pursuant to their terms and conditions for renewal." This is an
> >>> unacceptable deviation from the agreement we had regarding
> >>> grandfathering. The idea was that _existing_ agreements would not be
> >>> constrained by the new mission limitations, but that anything in the
> >>> future would be subject to the new mission limitations. By extending
> >>> existing exceptions or ambiguities into the future via renewals, we
> >>> are making the new mission limitations practically irrelevant. We need to
> push to change this.
> >>>
> >>>
> >>>
> >>> APPENDICES G1 and G2
> >>>
> >>>
> >>>
> >>> The items in Appendix G are carve-outs from the mission limitations.
> >>> That is, they expressly authorize certain actions as authorized and
> >>> thus not challengable under the mission limitations. Therefore, we
> >>> need to be extremely careful about what is included there. G1 refers
> >>> to registrars,
> >>> G2 to registries.
> >>>
> >>>
> >>>
> >>> In G1, the bullet point on resolution of disputes exempts any and
> >>> all ICANN policies regarding the USE of domain names. This broad
> >>> exemption is unacceptable to NCSG. Furthermore, its meaning is
> >>> unclear. I do not know what it means to say that dispute resolution
> >>> is limited to disputes "regarding the registration of domain names
> >>> (as opposed to the use of such domain names" and then to add "but
> >>> including where such policies take into account use of the domain
> >>> names)." The meaaning is unclear but we suspect it will be construed
> >>> as a blanket exemption for imposing on registrars any policies
> >>> regarding how domains are used, which could include content. I note
> >>> that Appendix G2 applicable to registries does not contain this
> >>> language. We want to get rid
> >> of it in G1 also.
> >>>
> >>>
> >>>
> >>> The bullet point on cross-ownership restrictions needs to make it
> >>> clear that restrictions are allowed only insofar as cross ownership
> >>> affects the core values of security, stability or competition. That
> >>> is, I see no basis for giving ICANN or the community a blanket right
> >>> to restrict cross-ownership for any reason they want; such
> >>> restrictions should only be used if they are a means to the end of
> >>> promoting or preserving the mission or other core values, such as
> >>> security, stability or competition. The best option would be to
> >>> delete this part of the G! and
> >>> G2 and make all cross-ownership policies subject to a mission challenge.
> >>> Cross ownership policies that demonstrably advance the core vales of
> >>> competition, security, stability, etc. should have no trouble
> >>> passing this test; cross-ownership limitations that do not clearly
> >>> meet this test should be subject to challenge.
> >>>
> >>>
> >>>
> >>> The bullet points on "reservation of registered names" MUST be
> >>> conditioned on respect for freedom of expression rights. I have no
> >>> trouble with leaving names reservations in as a general exemption
> >>> from mission challenges, but only if that power, which obviously can
> >>> be abused or over-extended, is limited by concerns about openness,
> >>> freedom and innovation on the Internet. Along these lines, we need
> >>> to clarify the term "intellectual property" to say "legally
> >>> recognized intellectual property rights."
> >>>
> >>>
> >>>
> >>> Other Substantive issues
> >>>
> >>> ------------------
> >>>
> >>>
> >>>
> >>> Section 1.1 (a) (iii)
> >>>
> >>> "Coordinates the allocation and assignment at the top-most level of
> >>> Internet Protocol numbers and Autonomous System numbers." I
> thought
> >>> IANA and IETF, not ICANN, do this. ICANN does it only insofar as it
> >>> is contracted to be the IFO. Does this belong here?
> >>>
> >>>
> >>>
> >>> Section 1.2 (a) (vi)
> >>>
> >>> Please delete the words "that enhance ICANN's effectiveness." I
> >>> don't see why these words are needed. They seem to undercut or make
> >>> conditional the clear meaning of the first part of the sentence,
> >>> which states that ICANN is accountable to its community through the
> >>> mechanisms defined in the bylaws.
> >>>
> >>>
> >>>
> >>> Section 1.2 (b) (vi)
> >>>
> >>> modify the sentence to read: "governments and public authorities are
> >>> responsible for public policy IN THEIR OWN JURISDICTION.."
> >>>
> >>>
> >>>
> >>> Clarity, copy editing and redundancy issues:
> >>>
> >>> -------------------------------------------
> >>>
> >>> Section 1.1 (a) (i), first bullet point:
> >>>
> >>> it says "facilitate the openness, interoperability, resilience,
> >>> security and/or stability". No reason to have an "and/or" here, it
> >>> should just be "and". We want them all, and in other parts of the
> >>> bylaws where substantially the same list exists there is an "and."
> >>>
> >>>
> >>>
> >>> Section 1.1 (a) (i), second bullet point:
> >>>
> >>> "That are developed through a bottom-up consensus-based
> >>> multistakeholder process and designed to ensure the stable and
> >>> secure operation of the Internet's unique names systems." This
> >>> sentence should end at "multistakeholder process." The addition of
> >>> "and designed to ensure the stable and secure operation of the
> >>> Internet's unique names systems" is redundant, it is already stated
> >>> in the first bullet
> >> point.
> >>>
> >>>
> >>>
> >>> Section 1.2 (a) (i)
> >>>
> >>> Needlessly awkward and confusing wording. Why not just say
> >>> "Administer the DNS in a way that preserves and enhances its
> >>> operational stability, reliability, security, global
> >>> interoperability, resilience and
> >> openness." ?
> >>>
> >>>
> >>>
> >>> Dr. Milton L. Mueller
> >>>
> >>> Professor, School of Public Policy
> >>>
> >>> Georgia Institute of Technology
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >> --
> >> Niels ten Oever
> >> Head of Digital
> >>
> >> Article 19
> >> www.article19.org
> >>
> >> PGP fingerprint 8D9F C567 BEE4 A431 56C4
> >> 678B 08B5 A0F2 636D 68E9
> >
|
