[Gnso-newgtld-wg] Closed generics proposal

Alexander Schubert alexander at schubert.berlin
Wed Feb 26 21:17:02 UTC 2020


In my mind:



If you need to take public land (category defining generic keyword based
gTLDs); have a clear, defined plan that serves the public interest. Or open
the gTLD up to the general public. Otherwise do your closed-gTLD trials in
the third level of an established gTLD first; when you are ready to rumble:
upgrade to top-level. In the third level you have all the "control" in the
world. 

I think it would be very hard to successfully prove why one heart monitor
company needs to claim the entire .heart namespace. What is the public
interest here?

 

But this brings up an interesting question:



*        It seems that exclusive access registry models for generic term
based gTLDs would demand to prove a "public benefit claim". "Generic keyword
based term" meaning: dictionary terms.

*        It also seems that the operation of an exclusive access registry
via Spec 13 designation places a lot of limits on such registry (Twitter or
Snap wouldn't be able to have their users completely controlling "their"
domains as far as I understand the Spec 13 restrictions)

*        What about permitting the operation of "exclusive access"
registries - if they do not use a generic dictionary term? In the example of
the heart monitoring company: ".pulz". It's not a "generic keyword based
term". 

 

Thanks,

 

Alexander

 

 

 

 

 

 

From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces at icann.org] On Behalf
Of Dorrain, Kristine via Gnso-newgtld-wg
Sent: Mittwoch, 26. Februar 2020 15:14
To: gnso-newgtld-wg at icann.org
Subject: [Gnso-newgtld-wg] Closed generics proposal

 

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.  

a.	Example: .heart 
b.	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.  
c.	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.

 

2.	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.  

a.	Example: .dashboard
b.	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.

c.	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. 

 

3.	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.  

a.	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

 

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


More information about the Gnso-newgtld-wg mailing list