Dear All, Please find the attendance and recording of the call attached to this email. The AC recording and AC Chat are listed below for the New gTLD Subsequent Procedures Sub Team – Track 2 – Legal/Regulatory Issues held on Thursday, 13 July 2017 at 15:00 UTC. Adobe Connect recording (audio and visual): https://participate.icann.org/p2mn6hx71j0/<https://participate.icann.org/p2mn6hx71j0/?OWASP_CSRFTOKEN=b560bc8bdbc53ab354fcb9a3e62cf7c94ff489404776d85c72fdf4fc779b54a0> The recordings of the calls are posted on the GNSO Master Calendar page: http://gnso.icann.org/en/group-activities/calendar ** Please let me know if your name has been left off the list ** Mailing list archives: http://mm.icann.org/pipermail/gnso-newgtld-wg-wt2 Agenda Wiki page: https://community.icann.org/x/XnHwAw Thank you. Kind regards, Julie ------------------------------- Adobe Connect chat transcript for 13 July 2017 Julie Bisland:Welcome to the New gTLD Subsequent Procedures Sub Team – Track 2 – Legal/Regulatory Issues on Thursday, 13 July 2017 at 15:00 UTC Susan Payne:perhaps the lack of notice of the change is a factor! people do have other obl;igations too. I have to leave after 45 minutes Jeff Neuman:@Susan - Normally we wouldnt change the time like this, but the GNSO Council meeting was just scheduled for our normal time, so we had to scramble. Susan Payne:I was just responding to the comments on how few people had joined, that the short notice of the change probably has an impact Jeff Neuman:@Susan - i know, but I wanted to clarify in the chat since some may not listen to the recording and may only read the chat :) Emily Barabas:Just wanted to reinforce that any staff summary/synthesis documents are intended to help promote discussion, but will inevitably be subjective and incomplete. Emily Barabas:It is important for WT members to read all comments and use this review to inform deliberations. Emily Barabas:Complete comments are available here: https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_spreads... Emily Barabas:Here is the complete text of the 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 spe Emily Barabas:Apologies if there is an error in the summary. Susan Payne:ah lovely thanks Emily Emily Barabas: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. Emily Barabas:Correction now uploaded. 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:@Jim - Thanks. 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 differentialation. 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. Emily Barabas:Full comment from Valideus: Categories become more relevant if there are different application criteria, obligations, or contractual provisions applied accordingly. Whilst we do not support multiple categories with different criteria, due to the complexity and lack of flexibility to develop and evolve business models that would likely result, the 2012 round did clearly establish a category of Brand TLDs, which we support. A number of Brands would have benefited from an application process and contractual provisions which better acknowledged the different drivers and priorities of a Brand TLD. Specification 13 goes some of the way here, but additional Brand-specific provisions or even a Brand-specific contract would be beneficial. An entirely separate contract for Brand TLDs requires careful consideration, however, as it has the potential to reduce the flexibility of registries. For example, if a registry operator did wish in the future to allocate names more widely, outside the limitations imposed by Specific Emily Barabas:iSpecification 13, it is a simple matter to remove the Specification from the contract. With a separate Brand contract the registry operator would need to enter into a replacement contract with ICANN. The same benefits and tailoring for Brand TLD might also satisfactorily be delivered by using the specification model. Susan Payne:Apologies, I have a standing meeting so need to drop Greg Shatan:"General Availability" Greg Shatan:Although I like "General Admission," since it nicely conjures up the mosh pit of GA.... John Laprise:I must also depart with apologies. Jon Nevett:no need Greg Shatan:Thanks, Michael! avri doria:thanks avri doria:bye Greg Shatan:Bye