ICANN ICANN Email List Archives

[gnso-vi-feb10]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [gnso-vi-feb10] What do we mean by "single registrant"?

  • To: Gnso-vi-feb10@xxxxxxxxx
  • Subject: RE: [gnso-vi-feb10] What do we mean by "single registrant"?
  • From: "Tim Ruiz" <tim@xxxxxxxxxxx>
  • Date: Mon, 05 Apr 2010 15:23:14 -0700

As long as Milton and Mike want to continue dismissing certain
concerns/points/issues as *protectionism* or something else equally
offensive, we will not get anywhere. I respect they're right to free
speech, but I hope Roberto and Mikey will respect all of our right to
hopefully accomplish something with the time we spend on this.

Tim 
 
-------- Original Message --------
Subject: RE: [gnso-vi-feb10] What do we mean by "single registrant"?
From: Milton L Mueller <mueller@xxxxxxx>
Date: Mon, April 05, 2010 5:08 pm
To: "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>, Tim Ruiz
<tim@xxxxxxxxxxx>, Eric Brunner-Williams
<ebw@xxxxxxxxxxxxxxxxxxxx>
Cc: "Gnso-vi-feb10@xxxxxxxxx" <Gnso-vi-feb10@xxxxxxxxx>


It's very clear what the rationale is: economic protectionism for
existing registrars and existing business models. 
The ONLY rationale for separating registries and registrars was to
prevent consumer lock-in. When the consumer and producer of a domain are
the same entity, any economic or consumer protection requirement that
registrars be used disappears. At that point, to require registrars is a
form of protectionism, similar to the railroad unions' demand that
freight and yard-engine firemen, who were needed on steam locomotives,
be retained on diesel and electric trains. 
--MM
________________________________________

What is the rationale for making a brand-TLD use ICANN registrars if
they are giving out domains to their employees or even vendors? I
understand about giving names out to the public at large, but what is
the benefit for the employees or vendors in having to use an icann
registrar? If they gave them out to their employees and/or vendors, the
Registry could still own the names, the names would be
non-transferrable, and they are being used for a specific purpose. What
is the value add of an ICANN-registrar? For example, if I want .neustar
and want to give out a domain name to each of my employees, contractors
and vendors to use for a specific purpose and once they ceased being an
employee, contractor, vendor, etc., I took back the name, why would I
have to use a registrar?

Jeffrey J. Neuman
Neustar, Inc. / Vice President, Law & Policy

________________________________
The information contained in this e-mail message is intended only for
the use of the recipient(s) named above and may contain confidential
and/or privileged information. If you are not the intended recipient you
have received this e-mail message in error and any review,
dissemination, distribution, or copying of this message is strictly
prohibited. If you have received this communication in error, please
notify us immediately and delete the original message.


From: owner-gnso-vi-feb10@xxxxxxxxx
[mailto:owner-gnso-vi-feb10@xxxxxxxxx] On Behalf Of Tim Ruiz
Sent: Monday, April 05, 2010 3:19 PM
To: Eric Brunner-Williams
Cc: Gnso-vi-feb10@xxxxxxxxx
Subject: RE: [gnso-vi-feb10] What do we mean by "single registrant"?

I would prefer this concept not be pursued right now at all, but if it
is I prefer Single Registrant / Single User (SRSU) as the descriptor
indicating that the Registry Operator(RO) is the sole registrant and
user of the second level names and that if such names resolve, they
resolve to a site/tool/resource that is produced/maintained solely by
and for the RO.

For example, 650i.bmw or coupes.bmw as sites produced by BMW for BMW
marketing and promotion. Or search.msn or developers.msn as sites
produced by Microsoft for internet search and developer support.

However, if BMW and/or Microsoft want to offer their vendors, employees,
customers, or anyone else domain names in their TLD, then they are no
longer SRSU TLDs. If they want to set up private access to their systems
for vendors, employees, customers, etc. they don't need a TLD in the
public root to do that. In fact, many enterprises already have their own
TLDs set up for such private use and access.

The examples above use well known trademarks as TLDs so besides the SRSU
issues, there is also the issue of having such marks in the public root
and under contract to ICANN. How well will such IP owners deal with
things like consensus policy, equitable treatment, enforcement actions,
etc.? I may be paranoid, but I see how effectively IP interests are
lobbied within ICANN and I guess I don't see them taking direction from
a bottom up, process driven institution very well. And if a TLD string
is one RO's IP, why should VeriSign and NeuStar not argue that com and
biz are their IP properties respectively?

Cliches like *can of worms* and *slippery slope* and *day in court* come
to mind when I think of all this. So if the SRSU concept has to move
forward, it should be with much caution and restraint until we can see
and understand all the repercussions.

Tim

-------- Original Message --------
Subject: [gnso-vi-feb10] What do we mean by "single registrant"?
From: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>
Date: Mon, April 05, 2010 12:03 pm
To: "Gnso-vi-feb10@xxxxxxxxx" <Gnso-vi-feb10@xxxxxxxxx>



One way of distinguishing something that doesn't yet exist, and for
which we have no examples to point to, and the models for which we do
have examples:
- price capped "open" or "standard" gTLDs,
- price uncapped "open" or "standard" gTLDs,
- sponsored gTLDs, and
- community-based gTLDs,
is the single purpose or unitary agency of a single registrant.

Milton used "private" vs "public" to attempt the distinction, and
Richard has used a "customer, member, employee, ..." relationship.

I've been trying to generalize because I don't think these get to the
difference. We don't know or care why registrants use com/net/org ...
we used to care that .net registrants were access network operators or
"in the wire trade", and that .org registrants were non-profit
organizations, and that .com registrants were communists (humor).

The point is, there is no reason common to the registrants, other than
the desire to use a namespace, complicated by preferences, for .com
primarily, and accommodation to prior registrations, trademark claims,
and so on.

In the case of a single registrant there is a reason common to the
single registrant, and all of the registrations by that registrant.
The reason will vary from registrant to registrant, asset management
for one, liability management for another, accounts receivable for a
third, customer care for a fourth, ...

I suggest it is the unity, or singularity of purpose that
distinguishes most a "single registrant" from what we have -- the
existing four types of present, and DAGvX anticipated registry
contract types.

This doesn't answer several important questions:
- what is the rational for excepting some asset or liability or
accounts receivable or customer care or ... management tool from
having more than one access channel? Is it size? Is it margin? Is it
quality control?
- are brand management solely instances of single registrant
sufficiently different from asset or liability or ... instances to
make policy differentiation?
- what should the ICANN transactional fee be? Is $0.20, from the
purposeless CNOBI market reasonable? Does it recover cost? Is it
equitable where the entry is a brand? Is it equitable where the entry
is a managed asset and the value of the registry is the savings using
an ICANN namespace product rather than some other asset management tool?

I suggest that there are at least two kinds of "single registrant",
what we call "brand" and what we call "customer" or "member" or ...
and that if, and only if, we decide that one or more of these kinds of
"single registrant" be included in DAGv4, or DAGv5, that there are
adequate gross differences to support differences in policy for these
two kinds, and any other kinds which we come up with.

Eric





<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy