[wg-c] S/K principles [Was: Working Group C agenda]

[Jonathan Weinberg <weinberg@mail.msen.com>]

	Let's talk about this.

	1. My understanding of the idea behind the S/K principles is that they
would indeed be used by the relevant ICANN body or process to guide its
selection of new TLDs or TLD/registry pairs.  If that's not right, then I'd
appreciate it if Philip or Kathy would let me know forthwith.  (If the
principles aren't intended to have some meaning as part of ICANN's
decisional process, then I'm not sure what we're doing considering them.)

	2. The actual language in the S/K principles that goes to the question of
enforcement is #1:  "a gTLD should give the net user confidence that it
stands for what it purports to stand for."  My understanding of that
language, based on various folks' exchanges with Philip on this list, is
that ICANN would expect a new TLD to have some mechanism (pre- or post-
registration) to eliminate SLD registrations that are inconsistent with
"what [the gTLD] purports to stand for."  Philip has indicated that the
language is consistent with having a new TLD that is open, and therefore
"stands for" unrestricted content, but presumably a TLD that indicates in
its charter that it "stands for" something narrower would have to have some
mechanism to enforce that by excluding SLD registrants.

	There's been some debate on the list as to how costly this would be, but I
think Kevin raises a more basic issue that I'd like to see discussed:  Is
this a good model for the name space, or a bad one?  *Should* most new TLDs
have such mechanisms?  There are some who argue that the best, bottom-up,
user-driven structure for the name space will be created by allowing users
to register where they want, and thus to define the name space in the ways
most meaningful to them.  There are others who argue that that such an
approach would interfere with attempts to add value through the structure
of the name space, and would allow some registrants to destroy the utility
of the name space for others.  Using Kevin's example, they urge that .FIRM
can add value only if a user can deduce from a registrant's presence in
that portion of the name space that it is in fact a limited-liability
corporation (say), and not an unincorporated pornographer.

	I suspect that this is one of the most important issues underlying the S/K
principles.  What do people think?

Jon


Jonathan Weinberg
co-chair, WG-C
weinberg@msen.com


At 09:06 AM 4/3/00 -0400, Kevin J. Connolly wrote:
>Dear Readers:
>
>There are several problems with the Shepard/Kleiman principles.
>
>First, at least one of the proponents (Kathy Kleiman)
>has stated (for instance, at the March 1 Small Business Administration
>round table on the future of the DNS and small businesses) that
>the principles are intended to be entirely optional, i.e., that no penalty
>would attach to a registry which declined to embrace any one or more
>of these principles.  If that is so.....if the adoption or rejection or
modification
>of the principles is a matter for each registry to consider as part of its
business
>plan.....then this WG has no business dealing with them.
>
>Second, while the principles are nice-sounding, they are, in fact, fraught
>with a mixture of operational difficulty, practical lack of meaning, and
>
>D A N G E R!!!  I recognize that I am probably in ful-dress Cassandra mode
>at this point, and while I rend my garment and cover myself in the ashes of
>Semele, yet I cannot still my fingers.
>
>The concept that a TLD should mean what it stands for is a good example 
>of these problems.
>
>My distinguished cousin, o-taka-no-sama Robert Connelly, is no doubt
>aware that one of the more popular SLD delegations requested under .FIRM
>is "keep-it" and congeners thereof.  Not exactly congruent with that the
>IAHC had in mind when it proposed that TLD.
>
>In the absence of a narrow and stringently-enforced charter, a gtld means 
>whatever the users think it does.  A narrow and stringently-enforced charter
>is not good business.  
>
>A narrow charter reduces the number of SLD delegations that will be 
>requested, thereby increasing the average cost per domain; and since 
>average cost is about as good an approximation to marginal cost as 
>we will ever find in the real world, an increased average cost means 
>that the competitive market price to the end user is likewise increased.
>
>Strict enforcement of charters is likewise very expensive.  Though I have
yet 
>to see a rigorous examination of the costs of strict enforcement, the cost of
>bringing a UDRP (an artifact of loose a priori enforcement) is not small.
If we
>are to adopt a rule of stringent enforcement before registration, I
daresay that
>the cost should not be less.  This indicates that the cost of securing a SLD 
>delegation would be on the order of $1,000.00, thereby creating some
>fairly high barriers to entry.  We should be mindful that the internet
establishment
>wants to do precisely this:  raise the barrier to entry so high that
no-one would
>ever think of obtaining their own SLD to use as a permanent e-mail address
and
>family photo album; raise the barrier so high that mom-and-pop operations
will
>not presume to try to create the same kind of internet image as the big guys.
>
>Moreover, this little review does not even attempt to factor in the need to 
>develop a litigation war chest, and it goes without saying that new TLD
registries
>will need to prepare their legal strategies carefully.
>
>There will be at least two serious challenges to strict prequalification
of SLD
>delegations:  one from the civil libertarian elements of US society, which
reacts
>frontally to anything which can be characterized as restraint of free
speech.  The
>second challenge will be economically driven, and come from the name-hoard/
>cybergrab industry.  I don't care to try to guess at the cost of defending
the system,
>but it won't be cheap.  A conservative estimate is on the order of $10E6.
>
>NSI has consistently avoided being held liable as a secondary infringer of
trademarks
>precisely because it exercises no prior scrutiny before delegating a
second level
>domain.  Apart from the fact that the Shepard/Kleiman principles sound
nice, there
>is no good reason to adopt them.  There is, however, a darned tootin' good
reason
>to avoid them.
>
>Timeo danaos et dona ferentes.  I fear the Greeks, even when they bear gifts.
>The principles are a Trojan Horse.  Consider the source thereof:  WG-B.  I 
>shudder in horror.  Once we adopt the idea that registrars or registries
or registrants hold a
>domain out as meaning something, and that that holding-out is a part of
the process
>of obtaining a delegation, we have let Odysseus into the walls of Illion,
and we will
>have let a legion of hungry lawsharks into the DNS.  The competitive
disadvantage
>that the new gtlds will face vis a vis com/net/org (which make no such
pretense and
>therefore will not be sued into oblivion for failure to enforce the
principles) will swamp
>the new gtlds.
>
>By the way, I do not condemn the authors of the principles as being as
wily and crafty
>as Odysseus.  They have engaged in an exercise which has great interest.
I simply
>believe that the adoption of the principles, or of any similar prior
restraint on the
>operations of new gtld registries, is suicidal.
>
>Kevin J. Connolly
>The opinions expressed are those of the author, not of Robinson Silverman
Pearce 
>Aronsohn & Berman LLP
>This note is not legal advice.  If it were, it would come with an invoice.
>As usual, please disregard the trailer which follows.
>**********************************************************************
>The information contained in this electronic message is confidential
>and is or may be protected by the attorney-client privilege, the work
>product doctrine, joint defense privileges, trade secret protections,
>and/or other applicable protections from disclosure.  If the reader of
>this message is not the intended recipient, you are hereby notified
>that any use, dissemination, distribution or reproduction of this com-
>munication is strictly prohibited.  If you have received this communi-
>cation in error, please immediately notify us by calling our Help Desk
>at 212-541-2000 ext.3314, or by e-mail to helpdesk@rspab.com
>**********************************************************************
>
>