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: Marika Konings <marika.konings@xxxxxxxxx>
  • Subject: Re: [gnso-policyimpl-wg] Updated public comment review tool and proposed "hierarchy" language
  • From: Amr Elsadr <aelsadr@xxxxxxxxxxx>
  • Date: Wed, 29 Apr 2015 16:28:41 +0200

Hi Marika,

The way I see it, the example I provided and the one you did are two extremes 
of a spectrum. They both seem equally relevant to me, and need to somehow be 
addressed. I would prefer to not ignore one in order to avoid the risk of the 
other.

One thought (this is just a first impression) I have is adding some language to 
the description of the GGP to read:

> 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 “Consenus Policies” including, but not limited to, any new contractual 
> obligations for contracted parties (in which case a PDP would need to be 
> initiated). 


This would exclude substantive changes to processes like the UDRP that may 
affect registrants, but would still allow the GNSO Council to use a GGP to 
answer questions the Council believes to be more relevant to implementation 
issues. The change would also be consistent with the working group’s charter 
that specifies that GNSO guidance should be used for developing policy other 
than “Consensus Policy”.

I would say that a combination of this and the low voting threshold required to 
initiate a GGP should allay any concerns about preventing a GGP from being used 
to address implementation issues. Personally, I would prefer language that 
clearly protects registrants from new (non-implementation) obligations, in the 
same manner it does for contracted parties.

Thoughts?

Thanks.

Amr

On Apr 29, 2015, at 3:20 PM, Marika Konings <marika.konings@xxxxxxxxx> wrote:

> I’m not sure how or who would determine whether new obligations on 
> registrants are created. In the case of contracted parties, I guess it is 
> fairly easy, if a change needs to be made to the agreements it creates a new 
> obligation, but in the case of registrants it may be much less obvious or in 
> the eye of the beholder. As a very hypothetical example, there could be a 
> need to clarify in a certain procedure that is the result of a PDP that 
> submissions need to be made by email instead of fax which the original rules 
> demanded. If you would argue that this would create a new obligation on 
> registrants, it would mean that for something that most would probably 
> consider a minor (implementation) change, you would need to go through a full 
> PDP. 
> 
> Furthermore, as Chuck also pointed out, requirements on registrants flow down 
> through registries and registrars, so I still fail to see how new enforceable 
> requirements could be imposed on registrants without a consensus policy.
> 
> Best regards,
> 
> Marika
> 
> From: <Gomes>, Chuck Gomes <cgomes@xxxxxxxxxxxx>
> Date: Wednesday 29 April 2015 09:03
> To: Amr Elsadr <aelsadr@xxxxxxxxxxx>
> Cc: Marika Konings <marika.konings@xxxxxxxxx>, Mary Wong 
> <mary.wong@xxxxxxxxx>, "gnso-policyimpl-wg@xxxxxxxxx" 
> <gnso-policyimpl-wg@xxxxxxxxx>
> Subject: RE: [gnso-policyimpl-wg] Updated public comment review tool and 
> proposed "hierarchy" language
> 
> 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> 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
> 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>
> Date: Tuesday 28 April 2015 11:10
> To: Marika Konings <marika.konings@xxxxxxxxx>
> Cc: Chuck Gomes <cgomes@xxxxxxxxxxxx>, Mary Wong <mary.wong@xxxxxxxxx>, 
> "gnso-policyimpl-wg@xxxxxxxxx" <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