[CCWG-ACCT] proposed language for Mission statement on contract enforcement

Mon Nov 2 17:34:08 UTC 2015

Agree with James.  Furthermore, it is a bit of a stretch to think bylaws language is able to define the legal term "regulation" - that is something courts and legislatures do.  While we at ICANN often make-up new definitions of words to suit various objectives, that doesn't mean those definitions have any binding power on a court.  If a court or legislature finds this to be a form of regulation, all of our saying it isn't in ICANN-sacred texts does not change the fact that it is.

Robin

On Nov 2, 2015, at 9:14 AM, James Gannon wrote:

> This wouldn’t solve the concerns that many of us have Greg about the potential misuse of ICANNs compliance role to enforce content regulation, something that the CEO and staff are now fully in agreement with the parts of the community that have been expressing this risk for years with, as we discussed in Dublin. This merely adds the problem back into the text.
> 
> -jg
> 
> From: <accountability-cross-community-bounces at icann.org> on behalf of Greg Shatan <gregshatanipc at gmail.com>
> Date: Monday 2 November 2015 at 5:11 p.m.
> To: Dr Eberhard W Lisse <el at lisse.na>
> Cc: Lisse Eberhard <directors at omadhina.net>, "accountability-cross-community at icann.org" <accountability-cross-community at icann.org>
> Subject: Re: [CCWG-ACCT] proposed language for Mission statement on contract enforcement
> 
> Becky and all,
> 
> I think the language proposed (in blue) meets some, but not all of the concerns expressed in Dublin.  Specifically, it does, as you state, state the stage for "a new mechanism whereby registries and registrars are permitted to sign RAs and RAAs subject to a public reservation that they intend to challenge one or more specified provisions of such agreements on the grounds that the provision(s) would exceed the scope of ICANN’s Mission."
> 
> In order to meet the remaining concerns expressed in Dublin, I would propose the following further addition (in red)
> 
> ICANN shall have no power to act other than in accordance with, and as reasonably appropriate to achieve its Mission. Without in any way limiting the foregoing absolute prohibition, ICANN shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide.  ICANN and contracted parties entering into, complying with and enforcing agreements does not constitute regulation.  In service of its Mission, ICANN shall have the ability to enforce agreements with contracted parties, subject to established means of community input on those agreements and reasonable checks and balances on its ability to impose obligations exceeding ICANN’s Mission on registries and registrars.
> 
> 
> I think this should meet the remaining concerns expressed in Dublin, but look forward to further comments.
> 
> Greg
> 
> On Fri, Oct 30, 2015 at 2:45 PM, Dr Eberhard W Lisse <el at lisse.na> wrote:
> Nigel,
> 
> don't worry he'll loose interest in the WG again soon. As usual.
> 
> el
> 
> On 2015-10-30 19:31 , Eric Brunner-Williams wrote:
> > Nigel,
> >
> > If your "strong argument that 'addressing the wildcard problem' was
> > corporate overreach" comes down to "because I said so", then I'm
> > satisfied that I've gotten all the information available.
> >
> > So, yes, marvelously happy now, thanks!
> >
> > Eric
> >
> >
> > On 10/30/15 11:27 AM, Nigel Roberts wrote:
> >> Articulation?
> >>
> >> "I submit that for ICANN to regulate the behaviour of DNS resolvers is
> >> overreaching its limited mission"
> >>
> >> Happy now?
> >>
> >>
> >>
> >> On 10/30/2015 06:21 PM, Eric Brunner-Williams wrote:
> >>> Nigel,
> >>>
> >>> Um, you alluded to "a strong argument that ..."
> >>>
> >>> I asked for an articulation of that "strong argument that ..."
> >>>
> >>> Your own resolver and your own network aren't quite what I expected.
> >>>
> >>> Eric
> >>>
> >>> On 10/30/15 11:07 AM, Nigel Roberts wrote:
> >>>> You can't guarantee uniqueness if I run my own resolver.
> >>>>
> >>>> I could make MICROSOFT.COM resolve to SEX.COM on my network if I chose
> >>>> so to do (obviously I don't).
> >>>>
> >>>>
> >>>>
> >>>> On 10/30/2015 05:32 PM, Eric Brunner-Williams wrote:
> >>>>> Nigel,
> >>>>>
> >>>>> I'm unaware of that argument. Could you point to an articulation of
> >>>>> it?
> >>>>>
> >>>>> You do appreciate that if resolver return values -- that is,
> >>>>> associations between names and addresses -- are ... unpredictable,
> >>>>> then
> >>>>> "technical co-ordination" may reasonably include allocations, of names
> >>>>> and addresses, with uniqueness guaranteed, but not the means of
> >>>>> association of names and addresses.
> >>>>>
> >>>>> Eric
> >>>>>
> >>>>> On 10/30/15 9:35 AM, Nigel Roberts wrote:
> >>>>>> Eric
> >>>>>>
> >>>>>> There's a strong argument that "addressing the wildcard problem" was
> >>>>>> corporate overreach.
> >>>>>>
> >>>>>> I know some will disagree, but it's nothing to do with the technical
> >>>>>> co-ordination of internet identifies, and everything to do with
> >>>>>> economic regulation.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 30/10/15 16:31, Eric Brunner-Williams wrote:
> >>>>>>> Becky,
> >>>>>>>
> >>>>>>> "shall not regulate services that use the Internet's unique
> >>>>>>> identifiers"
> >>>>>>> -- had this language been in place a decade ago how could the
> >>>>>>> corporation have addressed the wildcard problem? Who would be the
> >>>>>>> regulator(s) of monitized synthetic returns? These are things that
> >>>>>>> actually broke the net, and an appeal to Vixie's patch seems ...
> >>>>>>> well
> >>>>>>> ... to court risk of repetition.
> >>>>>>>
> >>>>>>> Where do we go in the future when VGRS initiates another disruptive
> >>>>>>> service unforeseen in contract? When the Egyptian government next
> >>>>>>> withdraws all prefixes can we keep the last authoritative
> >>>>>>> nameserver for
> >>>>>>> Egypt running after its data expires?
> >>>>>>>
> >>>>>>> Also, assuming for the moment that ICANN currently exercises
> >>>>>>> delegated
> >>>>>>> rule making authority, if ICANN explicitly abandons this authority,
> >>>>>>> does
> >>>>>>> that authority revert to the delegating agency?
> >>>>>>>
> >>>>>>> If I may, to regulate, or not regulate, stub-, recursive- and
> >>>>>>> authoritative-resolvers and their resolutions via port 53 of
> >>>>>>> delegated
> >>>>>>> name spaces to allocated address spaces, is more on-point, and
> >>>>>>> vastly
> >>>>>>> narrower, than "services that use ..."
> >>>>>>>
> >>>>>>> Eric
> >>>>>>>
> >>>>>>> On 10/30/15 6:19 AM, Burr, Becky wrote:
> >>>>>>>>
> >>>>>>>> In Dublin we discussed, both in our working meetings and over two
> >>>>>>>> brown bag lunches, an approach to addressing concerns about the
> >>>>>>>> Mission Statement prohibition on regulation of services that use
> >>>>>>>> the
> >>>>>>>> Internet’s unique identifiers, or the content that such services
> >>>>>>>> carry
> >>>>>>>> or provide.  The following language (in blue) is proposed to
> >>>>>>>> address
> >>>>>>>> this concern:
> >>>>>>>>
> >>>>>>>> ICANN shall have no power to act other than in accordance with,
> >>>>>>>> and as
> >>>>>>>> reasonably appropriate to achieve its Mission. Without in any way
> >>>>>>>> limiting the foregoing absolute prohibition, ICANN shall not
> >>>>>>>> regulate
> >>>>>>>> services that use the Internet's unique identifiers, or the content
> >>>>>>>> that such services carry or provide.  In service of its Mission,
> >>>>>>>> ICANN
> >>>>>>>> shall have the ability to enforce agreements with contracted
> >>>>>>>> parties,
> >>>>>>>> subject to established means of community input on those agreements
> >>>>>>>> and reasonable checks and balances on its ability to impose
> >>>>>>>> obligations exceeding ICANN’s Mission on registries and registrars.
> >>>>>>>>
> >>>>>>>> What we discussed (over the lunches) as a reasonable check and
> >>>>>>>> balance
> >>>>>>>>  (in addition to existing mechanisms such as public comment,
> >>>>>>>> etc.) is
> >>>>>>>> a new mechanism whereby registries and registrars are permitted to
> >>>>>>>> sign RAs and RAAs subject to a public reservation that they
> >>>>>>>> intend to
> >>>>>>>> challenge one or more specified provisions of such agreements on
> >>>>>>>> the
> >>>>>>>> grounds that the provision(s) would exceed the scope of ICANN’s
> >>>>>>>> Mission.   This mechanism will need to be developed.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> J. Beckwith Burr
> >>>>>>>> Deputy General Counsel & Chief Privacy Officer
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>>>> Accountability-Cross-Community mailing list
> >>>>>>>> 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
> >>>>>>>
> >>>>>> _______________________________________________
> >>>>>> Accountability-Cross-Community mailing list
> >>>>>> 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
> >>>>>
> >>>> _______________________________________________
> >>>> Accountability-Cross-Community mailing list
> >>>> 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
> >>>
> >> _______________________________________________
> >> Accountability-Cross-Community mailing list
> >> 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
> 
> 
> _______________________________________________
> Accountability-Cross-Community mailing list
> 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/20151102/35a4179b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20151102/35a4179b/signature.asc>