Page History

PROPOSED AGENDA

1. Welcome
2. SOI Updates
3. CC2 Comments: Registry Agreement
4. AOB

BACKGROUND DOCUMENTS

CC2 Comments_Base Registry Agreement - Themes.pdf

13 July 2017_WT2.pdf

Registry Agreement - Themes v2.pdf

Mp3

AC Recording

AC ChatTranscript

Attendees

Dial outs: Cheryl Langdon-Orr

Apologies: 
ICANN staff:Sara Bockey, Alan Greenberg, Annebeth Lange, Phil Buckingham

Notes/ Action Items

Registry Agreement

Introduction (Slide 3)

-- Goal: To move towards deliberations and proposals for steps forward for the initial report.

-- Schedule: 13 July -- review CC2 comments; 27 July -- work towards deliberations for Base Registry Agreement.

-- Go over the comments and to see if we are moving towards certain positions.

-- Develop preliminary recommendations and try to just consensus based on lack of objection.  Trying to stay away from polls as results can be biased.  Use the Working Group Guidelines concerning consensus.

Discussion Recap: Where are we at now? (Slide 4)

-- Only discussed one item with respect to the Base Registry Agreement: Single Registry Agreement vs. Multiple Registry Agreements.  Looked at pros and cons.

-- Possible Compromises: 1) scaled back "core" agreement with additional specifications per category; 2) single agreement with a more clear, structured, and efficient method for obtaining exemptions.

CC2 Question (Slide 5) -- 2.1.1 -- Base Registry Agreement (also see attached summary document)

-- Just wanted to reinforce that any staff summary/synthesis documents are intended to help promote discussion, but will inevitably be subjective and incomplete.  It is important for WT members to read all comments and use this review to inform deliberations.  Complete comments are available here: https://docs.google.com/spreadsheets/d/1tcWZt1bdoYH7vJl2Yi9G0jah7QzyhqU99tXnl3qV0rc/edit

-- Jannik Skou, INTA, Nominet, BC, BRG, John Poole, Afilias, RySG, ALAC, and NCSG support a single base registry agreement with specific sections for different TLD types.

-- Jim Prendergast and BRG support multiple registry agreements.

Comments focused on high-level goals rather than mechanisms:

-- RrSG: No new "on the fly" exemptions made or new TLD types classified once the application window is closed. (excerpt).

-- RySG: Single registry agreement with clauses versus suite of registry agreements are the same concept -- neither model should be more or less effective in recognizing the different operational requirements of different TLDs. (excerpt)

-- Valideus: Additional Brand-specific provisions or a Brand-specific contract would be beneficial.  An entirely separate contract for Brand TLD requires careful consideration, however, as it has the potential to reducee the flexibility of registries.  (excerpt).

Discussion:

-- BRG comments -- didn't think they were in favor of a single registry agreement.  Preference is to have something more tailored, but if that wasn't the case then they would support some kind of a stripped down base agreement.  Work out what the core is and then tailor based on addition, versus subtraction.  Full BRG comment: In its current form, the base RA is skewed towards traditional models and does not adequately reflect the new models introduced in the 2012 round. This can be a barrier for new entrants that operate distinctly different models. Where there is a significant difference between registry models and where these different models are a sizeable proportion of registry operators, the BRG recommends customised RAs to better reflect those models and their distinct nature. In this respect, the BRG favours a customised Registry Agreement (RA) for dotBrands, to reflect the distinct differences against a traditional open and commercial registry. A significant proportion of New gTLDs were dotBrands and we anticipate continued interest in future application windows. In the absence of a customised RA for dotBrands or other distinct and sizeable models, the BRG recommends the base agreement is stripped down to provide core provisions that are applicable to all, with the relevant specifications that define the model and variant provisions applicable to that model.  The contracting parties associated with each defined model would be the parties responsible for negotiating and voting any changes to the related specification, while all registry operating under the RA would be responsible to negotiate and vote for any changes to the core base agreement.

-- The ideal of having potentially completely different registry agreements for each TLD -- would need separate approvals for each time, different negotiations, just the effort on the registry side would be huge.  The systems and staff will be a huge resource allocation too.

-- Would be an administrative nightmare to get registries to agree on multiple agreements and some might fall into more than one category.  Introduces more complications than it settles.  This seems to be a theme in the comments we've received.

-- How ICANN prioritizes its spending and resources needs to be considered.

-- Seems that the objections to completely separate registry agreements can be resolved by having a master agreement that is the common core and than have schedules based on type.  Current agreement contains to many elements that are not common so we end up subtracting from the base registry agreement.  Better than having registries opt out of what doesn't apply.

-- Last round applicants were forced to accept what was essentially a franchise agreement.  Having a single base registry agreement would stunt innovation.  There are things, such as SLAs, that need to be negotiated.  Variable pricing also and how you treat registrars.  Also, GDPR.  There needs to be flexibility and negotiation.

-- The GDPR issue is a good one.  How to accomplish that while making sure that general legal boilerplate items for fairness sake that everyone is on a level playing field while addressing required differences?  Response: There does need to be a box around certain contractual/legal provisions, but avoid too many technical burdens that may not be necessary for some registry operations.

-- You may have a closed brand registry you may have to weigh whether you want to open it up and if you were to do that it is easier if you have a specification or master schedule model.

From the chat:

Trang Nguyen: To add to what Kristina just said, there is also added complexity for ICANN compliance to enforce multiple versions of the contract as well.

Sarah L Verisign: I realize my comment bucks the trend, but I would support increasing the ICANN compliance team and supporting negotiated contracts - I realize that this would increase the administrative burden however I support the concept of "contract negotiation" vs "contract acceptance" and dont see why contracts cant be negotiated seprately.

Susan Payne: Hi Greg - yes I think that is what the BRG was thinking  if there isn't a separate agreement altogether for certain registry types

Trang Nguyen: Another consideration is whether multiple individually negotiated RAs would create additional burden for the community who might be interested in tracking contractual provisions of various TLDs.

Jon Nevett: GDPR can be handled by the documented waiver process, no?

Sarah L Verisign: @jeff, you can have elements of a contracts, like LOLs, that are not negotiable and others that are.  We could agree which were negotiable and which were not, but having us all the same doesnt help us be innovative

Jeff Neuman: @Sarah - It would be interesting to see from ICANN legal which were the parts of the contract that were the most negotiated.

Jeff Neuman: But from what I recall, it was more the legal boilerplate than the technical specs

Susan Payne: sarah are you arguing that each individual registry should geta tailored agreement?  I hadn't initially thought you were but now I'm not sure?

Jeff Neuman: But, it would be great if we could draw a box around things needed for level playing field and those that have flexibility around technical solutions (while still having a minimum of requirements for stability/security, etc.

Sarah L Verisign: @jeff - I am not sure there were any negotiable aspects, rather an expectation of acceptance - at least from what I am aware.    @ susan, I am strying to  suggestimechanism that could address Jeff's concern  and still give us the ability to  have differentiation.

Greg Shatan: The Master/Schedule model would make this easier to manage.  Typically, the Master is less negotiable than the Schedules or SOW.  If the base agreement was truly the common core needed for virtually all registries,  while the Schedules were more particular/negotiable that would make management much easier.

Greg Shatan: The "Specification" model didn't really do this, since the Specs were a mixed bag of required and special elements.

2.1.2 Question (Slide 6) -- Restrictions pertaining to sunrise periods, landrush or other registry activities (also see attached summary document):

-- INTA, John Poole, Valideus, and Jannik Skou support additional restrictions pertaining to sunrise periods, landrush or other registry activities.

-- Nominet, BRG, Afilias, and RySG supporting maintaining the status quo with respect to restrictions.

-- BC supports maintaining current restrictions but pursuing additional measures regarding "predatory pricing."

Discussion:

-- Re: INTA Comment "[ICANN] has refused to request and share such [reserved domain names] lists, which would allow brand-owners to police improper reservation of names -- not sure that ICANN has that authority.  Could be a question back to INTA.

-- Question: A lot of this section touches on pricing and what the registries can do.  I think ICANN is explicit in that they do not regulate pricing in the new gTLD program.  Does anyone know the genesis of that?  Response: We should get more specificity, but there might be antitrust concerns at the root of this position.  Whether they are well founded or correct is a different question.  If this is the case that is open to review.

-- Use a term other than "predatory pricing" in our final report.