[Gnso-newgtld-wg-wt2] Actions/Discussion Notes: Work Track 2 SubTeam Meeting 25 May

Thu May 25 22:20:28 UTC 2017

Dear Sub Team Members,

Please see below the action items and discussion notes captured by staff from the meeting on 25 May.  These high-level notes are designed to help Work Track Sub Team members navigate through the content of the call and are not a substitute for the chat room or the recording.   See the chat room and recording on the meetings pages at: https://community.icann.org/display/NGSPP/Work+Track+2+Meetings. 

Please also see the attached slides and the excerpts from the chat room below.

Best regards,

Julie

Julie Hedlund, Policy Director

Action Items/Discussion Notes 25 May

1. Discussion on Contractual Compliance

Slide 2: Explanation of the Subject

Slide 3: Questions and Concerns Related to the Subject

-- Issues raised around how application representations can be better applied to the RA.

Slide 4: Relevant Guidance

Side 5: Rationale for Policy Development 

-- not in our mandate to make recommendation.  WG is not anticipating policy develop on this topic.

-- In CC2, the WG asked: 2.8.1 - Noting that the role of Contractual Compliance is to enforce the registry agreement and any changes to that role are beyond the scope of this PDP, the WG is not anticipating policy development related to this topic. The WG expects that any new contractual requirements would be made enforceable by inclusion in the base agreement. Do you agree with this approach? 

-- One more question that talked about making changes -- should the application itself be tied into the registry agreement?  2.1.3 - Should the entire application be incorporated into the signed Registry Agreement? Should portions of the application, explicitly identified, be incorporated into the signed Registry Agreement? If changes are made between applying and executing the Registry Agreement, how should this be handled? If changes are made after executing the Registry Agreement, how should this be handled? If changes like these are contemplated, how can the needs of the community to properly consider the contents of an application be weighed against an applicant’s need to make either minor adjustments or fundamental changes to their registry?                

-- One of the things that might be helpful (slide 3) questions raised in the public comment.  Reasoning for why we should even consider this.

-- There are so many issues that arise with respect to contractual compliance and the view of contracted parties would be different from non-contracted parties.  What is the scope with this WG with regard to those issues.  Which have to do with policy?  We can't just brush by contractual compliance issues unless we decide what we are brushing by.

-- First, the question that was posted in 2.1.3 -- it becomes far more relevant if we end up having categories in future applications with different terms associate with them and the lack of a registry to change those terms.  In terms of what is within our scope if we feel that registries and registrars have to do something that is subject to compliance, but we also can make recommendations in terms of how to enforce things.

-- In looking at this the contracts that people have do need to enforce the conditions under which a name was one -- whether all or part.  The problem with getting there looking at audits and compliance as a black box.  No idea of what they are finding now in registry and registrar compliance audits.  How we couple in these together -- how complied with and how it is audited.

-- Summary: 1) what issues to look at and talking about in this topic -- what data ICANN might be collecting in how they enforce the contracts 2) how to make the recommendations on enforcement to ICANN; 3) compliance data is a black box.

-- While data is a concern, the concern is beyond just the data element to how they do what they do and how effective they are.  May need to give recommendations on how to do it.  Data is a window into something, and we need the data too to know what is going on.

-- in a general direction -- how ICANN conducts compliance, how data is collected, and what data can be provided.  

-- May ask ICANN re: question about entering into a contract between ICANN and a registry under certain conditions, and then after the delegation the registry changes the policy considerately? This was relevant in the first round in connection with for example community TLDs or certain geographical TLDs that needed support from a public authority.

-- Public Comments: Concerns on premium pricing.  Such methods were used to abuse sunrise -- exclusive rights to trademark holders. (reference to INTA on behalf of IPC)

-- Issues on predatory pricing that we need to examine, but separate that asking for definitive pricing in the application.  We should take some of the concerns on predatory pricing and seeing how we can address them.

-- These concerns weren't reflected in the contractual compliance section of the Issue Report.  It would not be in contractual compliance's ability to enforce something that is not in the agreement.

>From the chat:

Annebeth Lange: Is this also a question about entering into a contract between ICANN and a registry under certain conditions, and then after the delegation the registry changes the policy considerately? This was relevant in the first round in connection with for example community TLDs or certain geographical TLDs that needed support from a public authority.

Annebeth Lange: Post-delegation was on the table in the first round.

2. Discussion of TLD Rollout

Slide 2: Explanation of the Subject [reading from the slide]

-- Whether or not this was adequate time for the rollout of new gTLDs.

Slide 3: Questions and Concerns Related to the Subject

Slide 4: Relevant Guidance

Slide 5: Rationale for Policy Development

-- Question on this in CC2 so responses may be a good first step. Question: 2.7.1 The Applicant Guidebook specified timelines by which applicants had to complete the contracting (9 months) and delegation (12 months) steps of the process. However, this requirement only means that the contract needs to be executed and nic.TLD be delegated. Are these timeframes reasonable? Is there still a need for these requirements? Please explain. 

-- in reality in regards to the delegation timeline ICANN did issue notices to individuals that needed to execute the registry agreement.  An extension request was offered to those applicants for an additional 9 months.

-- Helpful to explore -- ask ICANN with regards to the delegation deadline in the registry agreement -- were there any TLDs that did request extensions to the delegation deadline and how many were terminated for not meeting the deadline.

-- The question was not just about timelines.  The issue is did the delegation requirement meet the goal, such as helping to prevent squatting?  Not sure what purpose the delegation deadline serves right now.  Need to go back to the principle that we wanted TLDs to be used when applied for.

-- The goal was to prevent squatting.  There were TLDs that weren't delegated -- was this an issue?

-- Some applicants that were brands TLD wanted to apply for defense purposes.

-- The issue of use and rollout timing -- there is clearly a policy consideration that TLDs are more like spectrum than second-level domains.  There are ideas of innovation -- there are a lot of different justifications for not allowing warehousing of public domains.

-- There was a policy in place -- if we can't find a justification for changing it, then it stays in place.  There is data available and we are acting like it is something we can't ask for.  We should ask for the data so we can have informed discussions.  Have there been people who needed extensions?  Where there TLDs that were terminated.  Action Item: Get an official response.

-- Consider the good-faith argument in applying for an extension.

-- When an extension was granted it wasn't necessarily a 12-month bracket.

-- Be careful in making any conclusions based on what happened in the last round.

>From the chat:

Rubens Kuhl: That extension was given due to Spec 13 taking time to be finalized. 

Jeff Neuman 2: This issue was not just about the timeline, but also whether there needs to be a delegation deadline and what purpose does it really serve.

Rubens Kuhl: So from the perspective of Spec 13 applicants, they had the same lenght of time to act. 

Trang Nguyen: I believe the RA also provides for applicants (beyond Spec 13 applicants) to request for extensions to sign the RA.

Rubens Kuhl: Non-delegated TLDs could be cheapear to hold as inventory, since they could pay less or no fees to a registry service provider. 

Steve Chan: Section 4.3: §4.3 Termination by ICANN(b) ICANN may, upon notice to Registry Operator, terminate this Agreement if Registry Operator fails to complete all testing and procedures (identified by ICANN in writing to Registry Operator prior to the date hereof) for delegation of the TLD into the root zone within twelve (12) months of the Effective Date. Registry Operator may request an extension for up to additional twelve (12) months for delegation if it can demonstrate, to ICANN's reasonable satisfaction, that Registry Operator is working diligently and in good faith toward successfully completing the steps necessary for delegation of the TLD. Any fees paid by Registry Operator to ICANN prior to such termination date shall be retained by ICANN in full.

-- How do we want to define using a TLD?  What is the concern with putting those TLDs that aren't being actively used on the spot?

-- Many good reasons it might take quite some time for TLDs to be used.  Brands entered this with somewhat of a feeling that they had a gun put to their head.  For competive reasons people got in, for defensive reasons, so brands didn't have the commercial motivations in place.

Rubens Kuhl: @Trang, did any applicants or contracted registries requested such extension ? 

Rubens Kuhl: Possible purpose is to increase the hold cost in order to stimulate usage. 

Jeff Neuman 2: Delegation is when you pay fees

Christa Taylor: When delegated

Rubens Kuhl: The TMCH fee was a single time USD 5,000 fee. So time doesn't factor into cost. 

Jeff Neuman 2: I am just saying that the TMCH fees were billed at signing

Jeff Neuman 2: I guess my question is whether the community still has concerns about TLDs not being "used"

Christa Taylor: If we move to continuous rounds, could it impact the concern of not being used?

Phil Buckingham: Q should there be a requirement to launch after a set number on months / years after delegation ?

Trang Nguyen: ICANN org tracks delegation dates so we can provide average amount of time that it took for TLDs to get delegated if that is helpful to this discussion.

Jeff Neuman 2: "Warehousing" is very different than taking a long time to use

Annebeth Lange: Jeff, +1. There is also the question of the definition of "use"

avri doria: Agree we should ask for data.

Greg Shatan: Jeff, agree but the length of time is part of the difference. I'm not suggesting the current timeframes were good or bad, too long or too short....

Trang Nguyen: ICANN org has received requests for extension for delegations and have granted them.

Trang Nguyen: Same with contracting. We received requests for extensions (from Spec 13 applicants and non-Spec 13 applicants), and have granted extension

Phil Buckingham: +1 Alan . I have "found " PDT Service Level Targets ( SLTs) Should have been 28 days target  2/10 were missed  may 16- march 17 

Trang Nguyen: We can provide average timeframe for contracting and delegation.

Rubens Kuhl: http://newgtlds.icann.org/newgtlds.csv has some indications that could point to TLDs that went beyond expected delegation dates. 

Jeff Neuman 2: @Greg, for some brands the timeline was too short....for others too long.  It also relates to how long ICANN took to evaluate the applications and get to the point of signing agreements.  Many of the sponsors of the TLDs at brands were long gone from those companies by the time ICANN was ready to sign agreements.  That severely impacted brands who originally did want to "use" the TLDs, but lost interest after the 3 or 4 years it took to get through the process

Rubens Kuhl: There are a number of reasons to not being put into use... for instance, our TLDs are not being used due to lack of RAA2013 registrars in our target market. 

Jeff Neuman 2: And some brands got in because they actually wanted to use it :)

Jim Prendergast: Should note that .brands are also the leading type of TLD resignations.

Rubens Kuhl: Has CCT-RT looked into this angle ? 

Jeff Neuman 2: @Jim....true....but that could just mean that they know when they should get out ..... as opposed to others that should be getting out :)

Phil Buckingham: + 1 Jim , so why / what are the  reasons why  they "resigned  " ?  

avri doria: it may be necessary to ammend a strict policy with a list of possible circumstances for getting an extension.

Cheryl Langdon-Orr (CLO): makes sense to me Avri

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt2/attachments/20170525/30a0fb98/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SubPro_WT2_Contractual Compliance Intro.pdf
Type: application/pdf
Size: 625808 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt2/attachments/20170525/30a0fb98/SubPro_WT2_ContractualComplianceIntro-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SubPro_WT2_TLD Rollout Intro.pdf
Type: application/pdf
Size: 585261 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt2/attachments/20170525/30a0fb98/SubPro_WT2_TLDRolloutIntro-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4630 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt2/attachments/20170525/30a0fb98/smime-0001.p7s>