[CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract

Dr. Tatiana Tropina t.tropina at mpicc.de
Wed Nov 11 18:47:28 UTC 2015


+1 to Milton
Greg, thanks for the attempt to re-formulate, but I think the proposed
definition is (1) not technology neutral and (2) doesn't really make
much sense in terms of regulation. I have hard time to imagine what
regulation of "mail servers" might mean in legal and regulatory terms.
Best regards
Tanya


On 11/11/15 19:19, Mueller, Milton L wrote:
>
> Greg:
>
> Alas, it is not an accurate formulation. It is far too specific,
> invokes technologies that may be superseded or not conform to future
> architectures, etc. What does it mean to regulate a “web server”
> anyway? Configure its technology? ICANN could do all kinds of things
> we don’t want it to do without doing that.
>
>  
>
> There is nothing wrong with the concept of “services”  as the thing
> that we don’t want ICANN to regulate, with the obvious exception of
> domain name registry and registrar services.
>
>  
>
> --MM
>
>  
>
> *From:*accountability-cross-community-bounces at icann.org
> [mailto:accountability-cross-community-bounces at icann.org] *On Behalf
> Of *Greg Shatan
> *Sent:* Wednesday, November 11, 2015 12:33 PM
> *To:* Malcolm Hutty <malcolm at linx.net>
> *Cc:* Accountability Community
> <accountability-cross-community at icann.org>; ACCT-Staff
> <acct-staff at icann.org>
> *Subject:* Re: [CCWG-ACCT] Attempt to summarize discussion regarding
> Mission and Contract
>
>  
>
> Based on Malcolm's explanations, here's a possible alternate formulation:
>
>  
>
> *"ICANN shall not regulate web servers, mail servers and other devices
> that are located using the Internet's unique identifiers, or the
> content they carry."*
>
>  
>
>   * This clarifies what was meant by "service" by using more concrete
>     terminology (It's clear that "service" isn't working here, just
>     based on the limited responses on this thread.)
>   * It also clarifies what is meant by "use" in a way that I think is
>     more clear than an earlier offering by Malcolm intended to do the
>     same thing (the "reachability" proposal)
>   *  I removed the word "provide," since it's not entirely clear to me
>     what is being referred to as the "content" "provided" by an
>     Internet-connected device.  I thought about substituting
>     "generate," but if we are talking about "device-generated" data,
>     then there may be some need for "regulation" (or at least
>     "standardization") by ICANN (and IETF) in order to maintain data
>     flow (and thus SSR).  Also, I think the current draft formulation,
>     which essentially refers to regulating "services" that "provide"
>     "content", is the basis for much of the misunderstanding we have
>     about the meaning of this proposal, and thus should be avoided.
>
> I'm not saying I "agree" with this formulation, but I think it's a
> clearer statement (and I support my changes in that regard).  If there
> are those that fundamentally disagree that this is an accurate
> statement of the current proposal, it's important to know that.
>
>  
>
> Greg
>
>  
>
> On Wed, Nov 11, 2015 at 11:14 AM, Malcolm Hutty <malcolm at linx.net
> <mailto:malcolm at linx.net>> wrote:
>
>
>
>     On 11/11/2015 15:45, Silver, Bradley wrote:
>     > Malcolm, even if ICANN's ability to enforce agreements with
>     > contracted parties is enshrined in the language below, how would we
>     > address an argument that the prohibition against regulation
>     precludes
>     > such contracts having a downstream effect on non-contracted parties
>     > (and content)?  As Becky alludes, the URDP and WHOIS
>     requirements are
>     > examples of those downstream effects.
>
>     When answering such a question, it's very important to analyse the
>     text
>     itself, not various loose paraphrasings of the text we have all been
>     using in more casual conversation. While "the prohibition against
>     regulation" and "precludes contracts having a downstream effect on
>     non-contracted parties" are broad descriptions of the kind of
>     thing this
>     clause is intended to prohibit, they are not sufficiently precise to
>     give an accurate answer to your question. To answer it, we have to
>     look
>     at the precise wording itself.
>
>     The text as proposed only says that ICANN may not:
>
>     "regulate of services that use the Internet's unique identifiers [to
>     enable or facilitate their reachability over the Internet], nor
>     shall it
>     regulate the content that those services carry or provide"
>
>     When we analyse this closely, we will see that this prohibition is not
>     as broad as the paraphrasing.
>
>     So let's split this into parts:
>
>     1. Who does this apply to?
>        "The services that use the Internet's unique identifiers to
>     enable or
>     facilitate their reachability over the Internet".
>
>     These services are things like web servers, mail servers and so forth.
>     Services are a technical thing. They're not companies: companies
>     are the
>     *providers* of such services.
>
>     2. What is ICANN prohibited from doing?
>       a) regulating those services; or
>       b) regulating the content that those services carry or provide
>
>     So ICANN is, by this text, precluded from regulating the services
>     themselves, but is not explicitly prohibited from regulating the
>     providers of those services in ways that do not entail the
>     regulation of
>     those services (although it will have to find authorisation for doing
>     that elsewhere in its mission)*.
>
>     Now, let's apply that to WHOIS requirements.
>
>     "WHOIS requirements", loosely stated, require registrants to disclose
>     certain information for publication in the WHOIS system.
>
>     You could argue about whether that's a form of "regulation" of
>     registrants, but even if it is, it's not regulation of a web
>     service or
>     a mail service. It doesn't say "the web service must do this" or "the
>     web service must not do that". Web services don't register domains;
>     companies and individuals do.
>
>     Nor is this regulation of the content that those services carry or
>     provide. The things you do when you register a domain are not web
>     content, they're actions taken by the registrant. The WHOIS
>     requirement
>     says things like "If ACME corporation wishes to register ACME.com, it
>     must disclose its name and address for WHOIS publication". Nothing in
>     that is regulation of what appears on ACME's web site, in any way.
>
>     It would be up to someone who wanted to challenge the UDRP or the
>     WHOIS
>     requirements to prove that this text precludes those requirements.
>     They
>     will be unable to do so.
>
>     If you would like me to walk you through the same analysis with
>     UDRP, I
>     can do so, but I think the above answers your question.
>
>     Kind Regards,
>
>     Malcolm.
>
>     * NB: This is an important point, with important ramifications.
>     ICANN is
>     not prohibited by this clause from any form of regulation of domain
>     registrants at all. That may disappoint some (perhaps in civil
>     society).
>     I think it shows that this clause is balanced.
>
>
>
>     > -----Original Message----- From:
>     > accountability-cross-community-bounces at icann.org
>     <mailto:accountability-cross-community-bounces at icann.org>
>     > [mailto:accountability-cross-community-bounces at icann.org
>     <mailto:accountability-cross-community-bounces at icann.org>] On Behalf
>     > Of Malcolm Hutty Sent: Wednesday, November 11, 2015 10:26 AM To:
>     > Burr, Becky; Robin Gross Cc: ACCT-Staff; Accountability Community
>     > Subject: Re: [CCWG-ACCT] Attempt to summarize discussion regarding
>     > Mission and Contract
>     >
>     >
>     >
>     > On 11/11/2015 14:47, Burr, Becky wrote:
>     >> Could I get you to expand on one point Robin, Paul and others?  To
>     >> the extent ICANN obligates registrars to make registrants agree to
>     >> submit to a UDRP, is that regulation of parties not in privity of
>     >> contract with ICANN?  What about the requirement that registrants
>     >> provide accurate WHOIS Information.
>     >
>     > Perhaps I can take that.
>     >
>     > The proposal that we frame this as a prohibition on "regulation of
>     > parties not in privity of contract with ICANN" is a proposal from BC
>     > and USCIB. It is one form of wording that aims at the same basic
>     > intent as the original wording.
>     >
>     > For myself, I think this alternative wording is intended to resolve
>     > one fear (that an excessively broad interpretation of "regulate"
>     > might result in ICANN being unable to form contracts of any sort),
>     > but it introduces problems of its own. If the BC's wording were
>     used,
>     > I think UDRP and WHOIS requirements would be in jeopardy. I wouldn't
>     > want to do that, not do I see any public comment that suggests this
>     > is anybody's aim, least of all BC. That's why, when we sought a
>     > compromise that would address that concern, we did not adopt the BC
>     > wording, but instead added the following:
>     >
>     > "ICANN shall have the ability to negotiate, enter into and enforce
>     > agreements with contracted parties in service of its Mission."
>     >
>     > I think this is a good faith effort to accomodate the point that BC
>     > and USCIB raised, without reneging on the basic attempt to prevent
>     > the downstream content regulation, a principle that BC, USCIB have
>     > been clear that they also support. In other words, if we keep the
>     > Second Draft Report text and adopt the above sentence in addition, I
>     > believe we can in good conscience say that we have accommodated BOTH
>     > those that supported the original language AND the BC/USCIB input.
>     > Such reconciliation is surely what we should be aiming at, is it
>     > not?
>     >
>     > So the answer to your question is that if we go with the Second
>     Draft
>     > Report language (with or without the additional sentence), I don't
>     > think there is any problem with continuing UDRP or WHOIS. If we
>     > adopted the BC text as an alternative solution, I think that would
>     > make the UDRP ultra vires (which is surely accidental on BC's part).
>     >
>     >> What about the new gTLD applicant guidebook prohibition on Strings
>     >> at the top level that advocate behavior that violateS globally
>     >> accepted human rights standards?
>     >
>     >> These examples are things that ICANN does right now. Are they ultra
>     >>  vires under the regulatory prohibition? If not, why not?
>     >
>     >
>     > Again, we need to distinguish between the BC text and the Second
>     > Draft Report text.
>     >
>     > I think that BC text would create a conflict here too.
>     >
>     > The Second Draft Report text (with or without the additional
>     sentence
>     > quoted above) would not conflict with those rules. The reason is
>     that
>     > the text does not restrain ICANN in its choices as to which
>     top-level
>     > domains to approve or decline to approve in any way.
>     >
>     > The text only restricts ICANN from seeking to regulate the services
>     > (such as web servers) that use the DNS. Declining to approve the
>     > delegation of a controversial string could not credibly be said
>     to be
>     > an example of regulating the services (such as web servers) that use
>     > the DNS. Any attempt to mount such a claim in an IRP challenge would
>     > be doomed to failure. Indeed, assuming the IRP adopts procedures for
>     > the swift dismissal of claims with no reasonable prospect of
>     success,
>     > as we recommend elsewhere in our report, such an ill-founded claim
>     > would be dismissed rapidly.
>     >
>     > That said, Alan Greenberg has said he doesn't consider this point to
>     > be as unequivocally clear as I claim. Alan and I are entirely in
>     > agreement that this clause should not restrain ICANN's unlimited
>     > discretion as to which strings to approve as new gTLDs, but Alan
>     > thinks there is room for confusion on whether our text successfully
>     > achieves that. I would be happy to add a drafting note to our
>     lawyers
>     > that the final text must not bring this into question.
>     >
>     > In conclusion, as long as we proceed with the text that has been
>     > published, scrutinised, commented upon and widely suppored, we need
>     > have no fear concerning the points you raise.
>     >
>     > Your questions do, however, point up the dangers of unforeseen
>     > consequences in making, at this late stage, substantial changes to
>     > the text we have previously published.
>     >
>     > Kind Regards,
>     >
>     > Malcolm.
>     >
>     >
>     >> Sent from my iPad
>     >>
>     >>> On Nov 11, 2015, at 8:30 AM, Robin Gross <robin at ipjustice.org
>     <mailto:robin at ipjustice.org>>
>     >>> wrote:
>     >>>
>     >>> I do not agree that there lacks consensus on including the text
>     >>> which states ICANN won't regulate content.  There IS consensus on
>     >>> that point, but not full consensus because a small minority
>     >>> disagrees with that position (IPC).  Some in the BC don't even
>     >>> take this extreme IPC position.
>     >>>
>     >>> Many different parts of the community have commented that this is
>     >>> a crucial component to our proposed accountability plan, so
>     >>> taking it out at this stage, simply because the IPC won't relent
>     >>> is unacceptable.  The other parts of the community have to accept
>     >>> that we don't always get everything we want, and I find it
>     >>> difficult to understand why the same standard doesn't apply to
>     >>> the IPC - why we continue to go in circles until the IPC is
>     >>> satisfied.  These extra bites at the apple must stop.  We need
>     >>> some strength and backbone in our chairs and rapporteurs to not
>     >>> allow a small minority to impose this on the rest of the
>     >>> community, simply by refusing to relent until time runs out.
>     >>>
>     >>> Deleting this point, which has been repeatedly stated as crucial
>     >>> for such a wide segment of the community will create much more
>     >>> trouble for the acceptance of our report than not allowing the
>     >>> IPC to get everything it wants.
>     >>>
>     >>> Robin
>     >>>
>     >>>> On Nov 10, 2015, at 7:19 PM, Malcolm Hutty wrote:
>     >>>>
>     >>>>
>     >>>>
>     >>>>> On 11/11/2015 02:10, Burr, Becky wrote: Malcolm et al:
>     >>>>>
>     >>>>> I have to agree that the 11 comments appended by Malcolm
>     >>>>> express strong support for the notion that ICANN should not
>     >>>>> use its contractual authority to ³regulate services that use
>     >>>>> the DNS or the regulation of content these services carry or
>     >>>>> provide² and that ICANN should not attempt to establish
>     >>>>> obligations on non-contracted parties.² But the very
>     >>>>> commenters cited (BC, USCIB, etc.)
>     >>>>
>     >>>> Do you mean to imply that more than those two did?
>     >>>>
>     >>>>> also request clarification regarding ICANN¹s authority to
>     >>>>> enforce its contracts.  What are we to make of this?
>     >>>>
>     >>>> That's misleading. They didn't make a generalised, open-ended
>     >>>> request for clarification that opens the door to you to
>     >>>> construct an entirely new principle inconsistent with the main
>     >>>> principle. They had a proposal of their own.
>     >>>>
>     >>>> BC said:
>     >>>>
>     >>>> BC strongly support the proposition that ICANN should not
>     >>>> attempt to establish obligations on non-contracted parties.
>     >>>> Paragraph 60 should be clarified and we propose that it should
>     >>>> read as follows: "ICANN shall not engage in or use its powers
>     >>>> to attempt to establish contractual obligations on companies
>     >>>> with which it is not in privity of contract and shall not
>     >>>> attempt to establish contractual obligations on contracted
>     >>>> parties that are not agreed by such parties."
>     >>>>
>     >>>> Similarly, USCIB said:
>     >>>>
>     >>>> Indeed, ICANN's entire multi-stakeholder structure is built on
>     >>>> a self-regulatory system implemented through contractual
>     >>>> obligations and thus ICANN can only establish contractual
>     >>>> obligations on parties with which it has privity through a
>     >>>> negotiated and mutually agreeable contract/amendment with such
>     >>>> parties. Therefore, para 60 should be clarified and we propose
>     >>>> that it should read as follows: "ICANN shall not engage in or
>     >>>> use its powers to attempt to establish contractual obligations
>     >>>> on companies with which it is not in privity of contract and
>     >>>> shall not attempt to establish contractual obligations on
>     >>>> contracted parties that are not agreed by such parties."
>     >>>>
>     >>>>
>     >>>> This new language is simply not consistent with the proposition
>     >>>> that ICANN should have any ability to enter into contracts with
>     >>>>  Registries for the purpose of regulating (or controlling, or
>     >>>> any-of-a-number-of-other-verbs) the companies who register
>     >>>> domain names, their business models or the content those
>     >>>> companies carry on their web sites. Doing any of those things
>     >>>> would entail "establishing contractual obligations on companies
>     >>>> with which it [ICANN] is not in privity of contract", which is
>     >>>> precisely what they say ICANN must not do.
>     >>>>
>     >>>>
>     >>>>> With all due respect Malcolm, I will take a back seat to no
>     >>>>> one as a consistent and ardent defender of ICANN¹s limited
>     >>>>> mission.
>     >>>>
>     >>>> Take care, Becky. You are starting to make it sound as though
>     >>>> your own self-image as the defender of ICANN's limited mission
>     >>>> is getting in the way of recognising other input with that same
>     >>>> aim, but with which you personally disagree.
>     >>>>
>     >>>>> So I will restate the specific questions for the CCWG:
>     >>>>>
>     >>>>> 1. Do you agree or disagree with the following statement: "To
>     >>>>> the extent that registry operators voluntarily assume
>     >>>>> obligations with respect to registry operations as part of
>     >>>>> the application process, ICANN should have the authority to
>     >>>>> enforce those commitments.²
>     >>>>
>     >>>> The expressed view of these 11 commenters (including, I note,
>     >>>> the formal submission of the BC) clearly gives their answer to
>     >>>> this question as "disagree", at least inasmuch as those
>     >>>> obligations impose further obligations on third parties
>     >>>> (registrants) that limit what content they may carry or provide
>     >>>> on their web sites and suchlike services.
>     >>>>
>     >>>> There is simply no fair reading of these 11 commenters'
>     >>>> submissions that could answer this question as "agree", without
>     >>>>  first adding very substantial qualifications to the generality
>     >>>> of your proposition.
>     >>>>
>     >>>>> 2. Do you agree or disagree with the following statement:
>     >>>>> "ICANN shall not regulate services that use the Internet's
>     >>>>> unique identifiers, or the content that such services carry
>     >>>>> or provide.² - Wherever you land, please explain what you
>     >>>>> mean by ³regulate² and ³services."
>     >>>>
>     >>>> 9 of these 11 have said they agree, and accept the wording - so
>     >>>> they don't accept your suggestion that the words "regulate" or
>     >>>> "services" are unclear in the context used in the Draft
>     >>>> Report.
>     >>>>
>     >>>> 2 of these 11 have also said they agree, but propose alternate
>     >>>>  wording to achieve that; you may consider this wording, quoted
>     >>>>  above, as responsive to your question about defining
>     >>>> "regulate" and "services".
>     >>>>
>     >>>>
>     >>>>> I would be very interested in responses to these specific an
>     >>>>>  limited questions.
>     >>>>
>     >>>> -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs
>     >>>> | Read the LINX Public Affairs blog London Internet Exchange |
>     >>>>  http://publicaffairs.linx.net/
>     >>>>
>     >>>> London Internet Exchange Ltd Monument Place, 24 Monument
>     >>>> Street, London EC3R 8AJ
>     >>>>
>     >>>> Company Registered in England No. 3137929 Trinity Court,
>     >>>> Trinity Street, Peterborough PE1 1DA
>     >>>>
>     >>>>
>     >>>> _______________________________________________
>     >>>> Accountability-Cross-Community mailing list
>     >>>> Accountability-Cross-Community at icann.org
>     <mailto:Accountability-Cross-Community at icann.org>
>     >>>>
>     https://mm.icann.org/mailman/listinfo/accountability-cross-community
>     >>>
>     >
>     >>>>
>     > --
>     >>>>
>     > Malcolm Hutty | tel: +44 20 7645 3523
>     <tel:%2B44%2020%207645%203523> Head of Public Affairs | Read
>     > the LINX Public Affairs blog  London Internet Exchange |
>     > http://publicaffairs.linx.net/
>     >
>     > London Internet Exchange Ltd Monument Place, 24 Monument Street,
>     > London EC3R 8AJ
>     >
>     > Company Registered in England No. 3137929 Trinity Court, Trinity
>     > Street, Peterborough PE1 1DA
>     >
>     >
>     > _______________________________________________
>     > Accountability-Cross-Community mailing list
>     > Accountability-Cross-Community at icann.org
>     <mailto:Accountability-Cross-Community at icann.org>
>     > https://mm.icann.org/mailman/listinfo/accountability-cross-community
>     >
>     > =================================================================
>     > This message is the property of Time Warner Inc. and is intended
>     only
>     > for the use of the addressee(s) and may be legally privileged and/or
>     > confidential. If the reader of this message is not the intended
>     > recipient, or the employee or agent responsible to deliver it to the
>     > intended recipient, he or she is hereby notified that any
>     > dissemination, distribution, printing, forwarding, or any method of
>     > copying of this information, and/or the taking of any action in
>     > reliance on the information herein is strictly prohibited except by
>     > the intended recipient or those to whom he or she intentionally
>     > distributes this message. If you have received this communication in
>     > error, please immediately notify the sender, and delete the original
>     > message and any copies from your computer or storage system. Thank
>     > you.
>     > =================================================================
>     >
>
>     --
>                 Malcolm Hutty | tel: +44 20 7645 3523
>     <tel:%2B44%2020%207645%203523>
>        Head of Public Affairs | Read the LINX Public Affairs blog
>      London Internet Exchange | http://publicaffairs.linx.net/
>     <http://publicaffairs.linx.net/>
>
>                      London Internet Exchange Ltd
>            Monument Place, 24 Monument Street, London EC3R 8AJ
>
>              Company Registered in England No. 3137929
>            Trinity Court, Trinity Street, Peterborough PE1 1DA
>
>
>     _______________________________________________
>     Accountability-Cross-Community mailing list
>     Accountability-Cross-Community at icann.org
>     <mailto:Accountability-Cross-Community at icann.org>
>     https://mm.icann.org/mailman/listinfo/accountability-cross-community
>
>  
>
>
>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20151111/1dfab72a/attachment-0001.html>


More information about the Accountability-Cross-Community mailing list