ICANN ICANN Email List Archives

[gnso-policyimpl-wg]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [gnso-policyimpl-wg] Updated public comment review tool and proposed "hierarchy" language

  • To: Amr Elsadr <aelsadr@xxxxxxxxxxx>
  • Subject: Re: [gnso-policyimpl-wg] Updated public comment review tool and proposed "hierarchy" language
  • From: Greg Shatan <gregshatanipc@xxxxxxxxx>
  • Date: Wed, 29 Apr 2015 14:57:28 -0400

I find it somewhat easier to support the revised language proposed by Amr
(below), but I think there are still issues.  My first concern is that it
begs the question of how to identify when something is a new "Consensus
Policy" (which is kind of where we started...).  My second concern is that
this could be misconstrued, so that the GGP cannot be used during the
implementation process of a "new Consensus Policy".

A GGP may be initiated by the GNSO Council when a request for input
relating to gTLDs (either a new issue or in relation to previous policy
recommendations) has been received from the ICANN Board or a gTLD issue has
been identified by the GNSO Council that would benefit from GNSO Guidance,
and it has determined that the intended outcome is not expected to result
in new *“Consensus Policies” including, but not limited to, any new*
contractual
obligations for contracted parties (in which case a PDP would need to be
initiated).


The original language regarding no new obligations on registrants I found
troubling, especially in the context of the UDRP and the URS.  These are
both proceedings with two parties -- the registrant and the complainant.
It would be rather odd to have a prohibition against imposing new
obligations on one type of party, but not on the other type of party.
Indeed, I would object to such a dichotomy.  This also raises the question
whether there should be a prohibition against removing obligations, or does
this only work in one way?  I can't see why it would.  Thus, following this
logic, we should say that that GGP cannot change the obligations of any
party.  However, that may be so restrictive as to leave the GGP unusable.
I'm glad we are not pursuing this path.

Greg

On Wed, Apr 29, 2015 at 10:49 AM, Amr Elsadr <aelsadr@xxxxxxxxxxx> wrote:

> Yes…, I think something to that effect would do nicely.
>
> Thanks.
>
> Amr
>
> On Apr 28, 2015, at 10:37 PM, Gomes, Chuck <cgomes@xxxxxxxxxxxx> wrote:
>
> Would it make sense to add something like the following to the EDRP:  “The
> EDRP should not be used as a tool to reopen a previously explored policy
> issue only because a stakeholder didn’t like the conclusion of a previously
> held process on the same policy.”?
>
> Chuck
>
> *From:* Amr Elsadr [mailto:aelsadr@xxxxxxxxxxx <aelsadr@xxxxxxxxxxx>]
> *Sent:* Tuesday, April 28, 2015 11:11 AM
> *To:* Marika Konings
> *Cc:* Gomes, Chuck; Mary Wong; gnso-policyimpl-wg@xxxxxxxxx
> *Subject:* Re: [gnso-policyimpl-wg] Updated public comment review tool
> and proposed "hierarchy" language
>
> Hi,
>
> On Apr 28, 2015, at 4:21 PM, Marika Konings <marika.konings@xxxxxxxxx>
> wrote:
>
>
> Hi Amr,
>
> In relation to your question concerning the GGP, Annex D specifically says
> 'and it has determined that the intended outcome is not expected to
> result in new contractual obligations for contracted parties (in which case
> a PDP would need to be initiated)’. Do you consider this not to be
> sufficient? If so, where would you like to see additional clarification?
>
> This came up when the NCSG held a webinar to cover this WG’s initial
> report. The issue that was identified was that there are Consensus Policies
> that do not necessarily involve new contractual obligations for contracted
> parties, but may create new obligations on registrants. The examples
> provided were changes to the UDRP or URS.
>
>
> With regards to your point on the EPDP, and apologies for having missed
> last week’s meeting, I’m not sure why you would want to specifically
> exclude an issue for which a previous policy recommendation was rejected as
> circumstances may have changed or new information may have become available
> (which would need to be noted in the scoping request) but for which all the
> other previous scoping information would still be relevant.
>
> Hmm. That’s a good point. Thanks for making it. The intent of the NCSG
> comment here is to prevent abuse of this process as a tool to reopen a
> previously explored policy issue only because a stakeholder didn’t like the
> conclusion of a previously held process on the same policy. Let me think
> about this some more between now and tomorrow’s call.
>
> Thanks again.
>
> Amr
>
>
>


<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy