All, As promised on last week's call, I offer a proposal for what we're calling "closed generics." I wanted to turn the attention away from the binary question of "closed generics" or "no closed generics" and think about why some ROs may have applied for closed generics. If we can solve for these problems (e.g. create processes that solve for folks' concerns AND allow applicants to innovate), my guess is, the fight will fade. The examples are not based on real stories but are illustrative; other use cases could be imagined if we move away from only thinking of domain names as the end product/commodity. We should encourage next round applicants to innovate and explore ideas - we didn't get the Tesla by forcing everyone to build a Model T, the Model T was a starting point to improve upon. 1. Applicant offers a product or service for which unique URLs are part of the product. Controlling the namespace is part of the critical safety and infrastructure. * Example: .heart * Use: applicant develops a new pacemaker that stays in contact with the doctor, the pacemaker, an app on the patient's phone, and an online dashboard page that certain necessary folks have access to. * Why should this TLD be single-user? i. The RO has to undergo extensive security and privacy testing - by controlling the entire space (including being its own Registrar), the applicant can guard against phishing, malware, hijacking, etc. ii. The domain name is not sold to the end-user. It's the way the devices and dashboards communicate. It does not need a retail chain or any Rr markup or fees for the applicant to create the names it needs to run its product. The domain is just an easy handle for mobile and desktop access to the dashboard. It performs a function and is not a consumer product or service itself. Some of you will argue that ALL medical device manufacturers should then have access to .heart, but that's unrealistic since the medical device company that controls .heart will own all of the security and no other medical device company would be willing to trust their competitors with their data and security. Some of you will ask: a. "Why not just make it a .brand"? For a registry that is working on a standard for communication and security in this space, they will want it to be more "open" versus branded. That doesn't mean just anyone can obtain. The registry may need flexibility to monitor across a number of entities. Also, startups may not have a brand yet, or part of the new product/service may be creating a new brand. b. "But why not a community? Because some startups may be trying to disrupt an entrenched industry and you may not be able to get the large industry trade associations to back you and instead try to prevent change or innovation, as we saw in the last round. We want to encourage innovation and new models. We don't want to be ourselves an entrenched industry that is unwilling to embrace change. 1. Applicant startup is considering a new service that, when combined with a domain name, offers a new and unique benefit to the customer (a private sandbox, a unique dashboard, a control center for a device, whatever). It's possible that when this idea comes to fruition, the end user will need/want to own or control the domain name, but since the end user is not using the domain name to put up a site, but instead to interact with the service, this is unlikely. Having to own and manage a domain name will be clutter in the customer's life-they want the service. * Example: .dashboard * Assume there is no need/desire for the customer to deal with "owning" the domain name. The current ban on closed generics means that we're forcing the customer to register and manage a domain name that they don't want in order to obtain the service or device. i. Suggestion: create an option for an RO to decide domains in its TLD will be part of a bigger product or service and so long as the domain is bundled, the TLD can be owned and operated by the RO. * Assume the applicant may want to transfer ownership to the end user later. RO needs to alpha- and beta-test this idea before it launches - it really doesn't even know what the final registration policies will be because it hasn't decided its model yet. It needs customers and feedback. RO only has 100 "free" domains to work with and once you use them they're gone. This is not enough for a good beta test. i. Suggestion: make it easier for an Approved Launch Program or a new (TBD) Beta Program to include a multi-year beta. ii. Suggestion: include some guardrails or "PIC" language to ensure that when the idea is launched to customers, Spec 9 will apply at that point. 1. Applicant has cool ideas but needs time to test (similar to 2(c), above, but in a more traditional model). It wants to eventually offer names to customers for sale but needs to be able to break things and try things - pre-RSEP, pre-full registrant access. How can a registry experiment and figure out what works for their customers - the registrant - if the rules say they have to just open up. What happens if, upon opening, they realize the TLD rules need to be modified? Allowing models to be "closed" and test for some time will lead to more experimentation and new models in the long-run. * Suggestion: One set of guardrails could be a set number of test names that don't count against the RO 100, or a specific "test phase." As we can see, there is little point in assuming why ROs applied for closed generics - there were very likely business cases and innovative ideas behind the last round applications. These scenarios demonstrate that it is not difficult to imagine business cases that could benefit from innovation - nor is it difficult to fashion solutions to address concerns that some may have about using TLDs in this way. Instead of being stuck in the binary yes/no deliberations of 8 years ago and failing to meet the Board's expectation that we will come back to them with a sensible policy recommendation, let's instead build the guardrails that will allow innovation to proceed. Thanks, Kristine Dorrain