<<<
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: "Gomes, Chuck" <cgomes@xxxxxxxxxxxx>
- Date: Wed, 29 Apr 2015 13:03:59 +0000
Thanks for the helpful clarifications Amr.
I want to make clear that, in pointing out that requirements on registrants are
flowed down through registries and registrars I was not implying that I am
opposed to the NCSG suggestion. Rather, I wanted to clarify that when a
contracted party has to implement a consensus policy, they often have to make
modifications to their agreements with registrars in the case of registries and
with registrants in the case of registrars that modify the requirements on
registrants.
I repeat the question I asked of all WG members in a previous message in this
thread. Is anyone opposed to adding something like the following for the GGP:
"The GGP should not be used to add new obligations on registrants."
Chuck
From: Amr Elsadr [mailto:aelsadr@xxxxxxxxxxx]
Sent: Wednesday, April 29, 2015 7:33 AM
To: Gomes, Chuck
Cc: Marika Konings; Mary Wong; gnso-policyimpl-wg@xxxxxxxxx
Subject: Re: [gnso-policyimpl-wg] Updated public comment review tool and
proposed "hierarchy" language
Hi Marika and Chuck,
This comment wasn't mine, but raised by other NCSG members. However, I will do
my best to answer your questions now, and maybe get back to some colleagues for
more.
My understanding of how the UDRP and URS work is that a consensus policy could
lead to changes in requirements on the part of the registrant, or maybe more
accurately, the criteria that would trigger requirements for registrants to act
or be held accountable. Example (according to my admittedly limited
understanding) include changes to what constitutes applicable disputes or
evidence of registration or use of domain names in bad faith, which in turn
would require the submission of a mandatory administrative proceeding.
Although changes to these as a result of a consensus policy will create new
responsibilities (or obligations) on registrants, they don't actually change
the obligations of the contracted party or registrars. The language in section
3.8 of the 2013 RAA will not need to be amended to enforce the changes in the
UDRP. The obligations on the registrars remain constant, while new ones may be
created for registrants.
The language describing the GGP is very specific in excluding new obligations
to registries and registrars as a criteria, but does not mention consensus
policies or obligations of registrants. From my understanding, the GGP is not
meant to create new rules in processes such as the UDRP or URS, so it makes
sense to me to add registrants to the list of parties that the GGP cannot
create new obligations for.
I hope that was helpful.
Thanks.
Amr
On Apr 28, 2015, at 9:05 PM, Gomes, Chuck
<cgomes@xxxxxxxxxxxx<mailto:cgomes@xxxxxxxxxxxx>> wrote:
Unless I am missing something, the only way consensus policies can impact
registrants is via registries and registrars. ICANN doesn't have agreements
with registrants.
Chuck
From: Marika Konings [mailto:marika.konings@xxxxxxxxx]
Sent: Tuesday, April 28, 2015 12:27 PM
To: Amr Elsadr
Cc: Gomes, Chuck; Mary Wong;
gnso-policyimpl-wg@xxxxxxxxx<mailto:gnso-policyimpl-wg@xxxxxxxxx>
Subject: Re: [gnso-policyimpl-wg] Updated public comment review tool and
proposed "hierarchy" language
Hi Amr,
Apologies, I misread your first comment. It would be helpful if you could be
more specifics with regards to your examples and related concerns concerning
the URS and UDRP. As far as I understand, these processes set out the rules for
registrants, but I am not aware of any obligations that are created that are
enforceable in a similar way as consensus policies are enforceable on
contracted parties.
Best regards,
Marika
From: Amr Elsadr <aelsadr@xxxxxxxxxxx<mailto:aelsadr@xxxxxxxxxxx>>
Date: Tuesday 28 April 2015 11:10
To: Marika Konings <marika.konings@xxxxxxxxx<mailto:marika.konings@xxxxxxxxx>>
Cc: Chuck Gomes <cgomes@xxxxxxxxxxxx<mailto:cgomes@xxxxxxxxxxxx>>, Mary Wong
<mary.wong@xxxxxxxxx<mailto:mary.wong@xxxxxxxxx>>,
"gnso-policyimpl-wg@xxxxxxxxx<mailto:gnso-policyimpl-wg@xxxxxxxxx>"
<gnso-policyimpl-wg@xxxxxxxxx<mailto: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<mailto: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
>>>
|