[Gnso-newgtld-wg-wt4] Registry Services straw-person

Rubens Kuhl rubensk at nic.br
Tue Sep 12 18:20:18 UTC 2017


Anne,

That depends of the progress of the discussion in the mailing list and turnaround times on data requests we have pending on other topics... but on Registry Services we are still missing one or more SP proposals from Kurt and Sarah and would like to include all proposals in the discussion... 

Kurt, Sarah,

Any progress on those ? 

Rubens


> Em 12 de set de 2017, à(s) 15:14:000, Aikman-Scalese, Anne <AAikman at lrrc.com> escreveu:
> 
> Thank you.  When will the two SP proposals be discussed further?
>  
> Anne E. Aikman-Scalese
> Of Counsel
> 520.629.4428 office
> 520.879.4725 fax
> AAikman at lrrc.com <mailto:AAikman at lrrc.com>
> _____________________________
> <image003.png>
> Lewis Roca Rothgerber Christie LLP
> One South Church Avenue, Suite 700
> Tucson, Arizona 85701-1611
> lrrc.com <http://lrrc.com/>
>  
> From: Rubens Kuhl [mailto:rubensk at nic.br <mailto:rubensk at nic.br>] 
> Sent: Tuesday, September 12, 2017 11:10 AM
> To: Aikman-Scalese, Anne
> Cc: Jeff Neuman; gnso-newgtld-wg-wt4 at icann.org <mailto:gnso-newgtld-wg-wt4 at icann.org>
> Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person
>  
>  
> Anne,
>  
> What you mentioned was already the plan anyways... Registry Services would only be raised, if raised, as an AOB item; per you request we will deny its inclusion in AOB if someone asks. 
>  
>  
> Rubens
>  
>  
> Em 12 de set de 2017, à(s) 15:07:000, Aikman-Scalese, Anne <AAikman at lrrc.com <mailto:AAikman at lrrc.com>> escreveu:
>  
> Dear all,
> The Work Track 4 meeting tomorrow now conflicts with the ICANN Policy MSSI Update for all Commercial Stakeholders.  Accordingly, could we move discussion of the 2 Straw Proposals on Question 23 to the call after the one tomorrow?  This would mean discussion financial evaluation during the Thursday call and Question 23 SPs to the next call after.
>  
> I would very much appreciate this is if it can be done.
> Thank you,
> Anne 
>  
> Anne E. Aikman-Scalese
> Of Counsel
> 520.629.4428 office
> 520.879.4725 fax
> AAikman at lrrc.com <mailto:AAikman at lrrc.com>
> _____________________________
> <image003.png>
> Lewis Roca Rothgerber Christie LLP
> One South Church Avenue, Suite 700
> Tucson, Arizona 85701-1611
> lrrc.com <http://lrrc.com/>
>  
> From: Aikman-Scalese, Anne 
> Sent: Tuesday, September 05, 2017 3:18 PM
> To: 'Rubens Kuhl'
> Cc: Jeff Neuman; gnso-newgtld-wg-wt4 at icann.org <mailto:gnso-newgtld-wg-wt4 at icann.org>; Greg Shatan; 'Metalitz, Steven'
> Subject: RE: [Gnso-newgtld-wg-wt4] Registry Services straw-person
>  
> Rubens,
> Are you saying that your Straw Proposal includes a proposal to delete the existing Question 23 language asking applicants to propose specifically any new registry services (and listing customary services) whereas mine proposes to maintain it and establish two tracks for processing – that is, one for Fastrack  “no new services” applications and another for regular  “proposed new services” applications?  For clarity, the existing language is pasted below in purple with my proposal in red.  It is not clear to me whether your proposal  includes Question 23 text as is (with additions) or whether you want to delete the current text in the application (shown in purple below from existing application). 
>  
> It appears you propose  (and advocate in this debate)  four substantive changes:
> 1.       Applicant is NOT required to list proposed new registry services in the application as was the case in 2012.
> 2.       Applicant can choose when to propose new services (in the application, at contracting, or after contracting) and when they will be evaluated, using only the RSEP procedure.
> 3.       You propose to delete the list of “customary services” in Question 23.  (BTW for participants, this includes port-43 WHOIS, Web-based Whois, RESTful Whois)
> 4.       You propose to delete the text which states that the Applicant must describe whether any of the customary registry services listed are going to be offered in a manner unique to the TLD.
>  
> Is that correct?
>  
> Thank you,
> Anne
>  
> "  23. Provide name and full description of all the Registry Services to be provided. Descriptions should include both technical and business components of each proposed service, and address any potential security or stability concerns.
> The following registry services are customary services offered by a registry operator:
> A.            Receipt of data from registrars concerning registration of domain names and name servers.
> B.            Dissemination of TLD zone files.
> C.            Dissemination of contact or other information concerning domain name registrations (e.g., port-43 WHOIS, Web- based Whois, RESTful Whois service).
> D.            Internationalized Domain Names, where offered.
> E.            DNS Security Extensions (DNSSEC). The applicant must describe whether any of
> these registry services are intended to be offered in a manner unique to the TLD.
> Additional proposed registry services that are unique to the registry must also be described.  "Applicant acknowledges that ICANN may establish two application evaluation tracks which will operate separately, one for applications which propose new registry services and one for applications which contain only the following pre-approved registry services:  LIST PRE-APPROVED SERVICES HERE"
>  
> Anne E. Aikman-Scalese
> Of Counsel
> 520.629.4428 office
> 520.879.4725 fax
> AAikman at lrrc.com <mailto:AAikman at lrrc.com>
> _______________________________
>  
> Lewis Roca Rothgerber Christie LLP
> One South Church Avenue, Suite 700
> Tucson, Arizona 85701-1611
> lrrc.com <http://lrrc.com/>
>  
> -----Original Message-----
> From: Rubens Kuhl [mailto:rubensk at nic.br <mailto:rubensk at nic.br>] 
> Sent: Tuesday, September 05, 2017 2:43 PM
> To: Aikman-Scalese, Anne
> Cc: Jeff Neuman; gnso-newgtld-wg-wt4 at icann.org <mailto:gnso-newgtld-wg-wt4 at icann.org>
> Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person
>  
>  
> So we are still missing one from Kurt and Sarah... but so far, we have:
>  
> Straw-proposal 1: (from Sep 1)
>  
> "Applicants will be allowed but not required to specify additional registry services. List of  previously approved registry services (IDN Languages, GPML, BTPPA) to be included by reference in AGB and contract.
> If applicant informs additional registry services, they will be evaluated thru RSEP. Applicant will choose whether the evaluation is to occur at evaluation time, contracting time or after contract signing."
>  
> Straw-proposal 2:
> "Applicants should provide name and full description of all the Registry Services to be provided. Descriptions should include both technical and business components of each proposed service, and address any potential security or stability concerns.
> "Applicant acknowledges that ICANN may establish two application evaluation tracks which will operate separately, one for applications which propose new registry services and one for applications which contain only the following pre-approved registry services:  LIST PRE-APPROVED SERVICES HERE"
> (disclaimer: I compiled the language from Q23 and the mailing list discussion, and is prone to errors since it was not submitted in entirety by proposal author)
>  
> Similarities:
> - Both foresee pre-approved services and mention a list
> - Both are silent on whether using only pre-approved services would have a different fee
>  
>  
> Differences between the two so far:
> - (1) incorporates a list of pre-approved services by reference, although mentioning some, while (2) explicitly names a list
> - (1) allows a service to be evaluated at contracting time while (2) does not; (* note: although 1 foresees a option after contract signing, that's already a fact due to Registry Services policy *)
> - (1) is silent of the processing of applications, although in practice create 2 tracks since RSEP is an already established procedure outside of the subsequent procedures evaluation program. (2) explicitly creates two tracks.
> - (1) only requires applicant to inform about registry services that are not in the pre-approved list while (2) requires all services to be informed and described at application time
>  
>  
> Feedback taken from the latest discussions on the list:
> - The list of services on (1) and (2) could be expanded to the "minimal pre-approved services" that would be allowed even if there is no such list for already established registry operators.
> - Some already mentioned the list in AGB as a possible starting point:
> "A. Receipt of data from registrars concerning registration of domain names and name servers. B. Dissemination of TLD zone files. C. Dissemination of contact or other information concerning domain name registrations (e.g., port -43 WHOIS, Web - based Whois, RESTful Whois service). D. Internationalized Domain Names, where offered. E. DNS Security Extensions (DNSSEC)."
>  
> </co-chair>
> - The mention of registry services evaluation after contract signing in (1) is probably misplaced, since it's part of a policy not covered in our charter. It's also redundant.
> - The requirement of specifying pre-approved services in the application in (2) is likely ineffective if there is such a list for registry operators, since a registry could activate them just after contract signing since they are pre-approved. It has an effect though if no such list for registry operators exists at that time.
> A question arises: do we assume such a list will exist or think on both scenarios ?
> <co-chair>
>  
>  
> Any further thoughts, feedback or new straw proposals ? 
>  
>  
>  
> Rubens
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> > Em 5 de set de 2017, à(s) 18:09:000, Aikman-Scalese, Anne <AAikman at lrrc.com <mailto:AAikman at lrrc.com>> escreveu:
> > 
> > Rubens,
> > My Straw Proposal is actually stated in A. below, and yet you have said you did not receive it.  It would be good to have the two side by side.
> > Anne
> >  
> > Anne E. Aikman-Scalese
> > Of Counsel
> > 520.629.4428 office
> > 520.879.4725 fax
> > AAikman at lrrc.com <mailto:AAikman at lrrc.com>
> > _____________________________
> > <image003.png>
> > Lewis Roca Rothgerber Christie LLP
> > One South Church Avenue, Suite 700
> > Tucson, Arizona 85701-1611
> > lrrc.com <http://lrrc.com/>
> >  
> > From: Rubens Kuhl [mailto:rubensk at nic.br <mailto:rubensk at nic.br>]
> > Sent: Tuesday, September 05, 2017 2:05 PM
> > To: Aikman-Scalese, Anne
> > Cc: Jeff Neuman; gnso-newgtld-wg-wt4 at icann.org <mailto:gnso-newgtld-wg-wt4 at icann.org>
> > Subject: Re: [Gnso-newgtld-wg-wt4] Registry Services straw-person
> >  
> >  
> > Em 5 de set de 2017, à(s) 17:52:000, Aikman-Scalese, Anne <AAikman at lrrc.com <mailto:AAikman at lrrc.com>> escreveu:
> >  
> > Rubens,
> > I have communicated separately with you off-list and to Leadership regarding your response.  The following comments are circulated to the entire list:
> >  
> > A.      Please circulate the second Straw Proposal in addition to your own for comparison purposes.  The second proposal is that the language of Question 23 remain the same as in the 2012 round which states that all new services to be offered MUST BE DESCRIBED (see below) with the following addition:   “Applicant acknowledges that ICANN may establish two application evaluation tracks which will operate separately, one for applications which propose new registry services and one for applications which contain only the following pre-approved registry services:  LIST PRE-APPROVED SERVICES HERE (TO BE DISCUSSED ON THE NEXT CALL).
> >  
> >  
> > As I mentioned, I haven't received the second straw proposal. I believe Sarah, Kurt, and perhaps you could join them, were going to send one... as soon as one does, let's start circulating them both. Or three or more if it needs be...
> >  
> > Note also the agenda for the next call was defined long before this discussion, and doesn't include registry services... if there is AOB time for it, it's sure a topic to add.
> >  
> > 
> > 
> >  
> > B.      You state that it is “out-of-scope” for Work Track 4 for us to discuss the policy issue of incurring additional fees for evaluation of additional new registry services.  However, it is in fact your Straw Proposal that suggests such additional fees are appropriate.  If this is policy work that is “out-of-scope” for Work Track 4, then the language of your Straw Proposal is itself “out-of-scope”.
> >  
> > The latest straw person actually removed any fees reference, exactly due to that. BTW, this was added due to a comment during the call that was one made not by me or Cheryl... but anyway, it's removed both due to opposition and to be out of scope. 
> >  
> >  
> > 
> > 
> >  
> > C.      You state that I cannot raise issues regarding effect on RPM policy because that is for the RPM PDP, not for Work Track 4.  If you are advocating a policy change that affects RPM policy, it has to be raised and flagged, not buried as “out of scope” for Work Track 4.)  How will the RPM PDP even KNOW that such an issue is being created by a proposed change in Question 23 if not discussed and brought to their attention?
> >  
> > 
> > On the connection with RPM PDP WG, while there is not something currently foreseen at the work-track level, there is at the WG level, and every WT definition comes first to the WG, doesn't go into final report before that. From our charter:
> > "Second-Level            Rights  Protection        Mechanisms:   Proposing        recommendations        directly            related to         RPMs  is          beyond the      remit    of         this      PDP. There      is          an        anticipated PDP on            the       "current           state     of         all       rights   protection        mechanisms     (RPMs)            implemented   for       both     existing            and      new     gTLDs,            including        but       not            limited to         the       UDRP and      the       URS...". Duplication   or         conflicting       work    between            the      New    gTLD  Subsequent      Procedures      PDP     and      the       PDP on            RPMs  must    be            avoided.          If         topics   relatedto         RPMs  are       uncovered       and      discussed         in         the            deliberations    of         this      PDP,    those    topics   should be        relayed            to         the       PDP     on            RPMs  for       resolution. To  assure  effective          coordination    between           the       two      groups,            a          community      liaison, who     is          a          member           of         both     Groups,           is          to            be        appointed        jointly  by        both     Groups            and      confirmed        by        the       GNSO            Council."
> > 
> > The first topic you mentioned seemed to me an aspect of the sunrise/claims process, which is being actively worked by the RPM PDP WG. The other one is about registry services in general so is not directly related to RPMs; either way, every one of the SubPro recommendations will need, at the end, an analysis of whether it uncovered a new topic that should be forwarded to the RPM PDP or not.
> > 
> > (remaining text already replied to)
> >  
> >  
> >  
> > Rubens
> >  
> > 
> > 
> > This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
>  
>  
> 
> This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
>  
> 
> 
> This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20170912/e39cc2f3/attachment-0001.html>


More information about the Gnso-newgtld-wg-wt4 mailing list