[CCWG-ACCT] [bylaws-coord] Comments on Article 1 of the draft bylaws

Wed Apr 6 20:01:53 UTC 2016

Dear Milton,

Thank you for your detailed review. This is really important and we must
be extremely cautious. Becky has responded on the "picket fence" issue you
raise, and given the level of detail we have been to during the
Recommendation 5 discussions, I don't think the approval of our
recommendations was understood or expected to imply amendments (which
would be undefined at this stage) of these annexes.

I also want to ensure you get a response to the 3 substantive issues you
mention.

We can share the  clarity and edit issues with the lawyers but I think we
have agreed that this should be left to their judgment.

Best,
Mathieu

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? Looking forward to the
comments of numbers and protocol communities here.

>>>> It is my understanding that the numbers and protocol communities have
provided their input, which was taken into account, through the Bylaws
Coordination Group. Indeed, should there be any issue, it should be
raised.

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.

>>>> These words are part of the CCWG Recommendation 5. Paragraph 20, page
5. As a consequence, I don't believe it is in our mandate to change them
at this point.

Section 1.2 (b) (vi)
modify the sentence to read: "governments and public authorities are
responsible for public policy IN THEIR OWN JURISDICTION." This is just a
legal fact. Governments have no legal mandate for global public policy.

>>>> As above, this formulation is part of the CCWG Recommendation 5.
Paragraph 22 page 5. As a consequence, I don't believe it is in our
mandate to change them at this point.

-----Message d'origine-----
De : bylaws-coord-bounces at icann.org
[mailto:bylaws-coord-bounces at icann.org] De la part de Mueller, Milton L
via bylaws-coord
Envoyé : mercredi 6 avril 2016 18:36
À : CCWG Accountability
Cc : 'bylaws-coord at icann.org'
Objet : [bylaws-coord] Comments on Article 1 of the draft bylaws

In general, the Mission, Core Values and Commitments bylaw language
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. Additionally, I flag some
unclear, awkward or redundant wording that needs to be fixed.

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.

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 exemption is too
broad. 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 meaning 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
should 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 values 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? Looking forward to the
comments of numbers and protocol communities 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." This is just a
legal fact. Governments have no legal mandate for global public policy.

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, as 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

Internet Governance Project
http://internetgovernance.org

_______________________________________________
bylaws-coord mailing list
bylaws-coord at icann.org
https://mm.icann.org/mailman/listinfo/bylaws-coord