[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