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

Greg Shatan gregshatanipc at gmail.com
Mon Nov 2 17:11:26 UTC 2015


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20151102/9643d923/attachment.html>


More information about the Accountability-Cross-Community mailing list