ICANN ICANN Email List Archives

[At-Large Advisory Committee]


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

RE: [alac] .net: Thick vs. thin registry, WHOIS models

  • To: alac@xxxxxxxxx
  • Subject: RE: [alac] .net: Thick vs. thin registry, WHOIS models
  • From: "Roberto Gaetano" <alac_liaison@xxxxxxxxxxx>
  • Date: Thu, 12 Aug 2004 09:02:50 +0200

Although in the early days of CORE I was in favour of a thick registry (there must still be trace of an Internet draft under names of Crispin, Gaetano, Langenbach), for a number of reasons that have become irrelevant in time, I now believe that the thin registry will be a better model because it keeps data local (added value is addressing different privacy laws), encourages competition (registrar have some flexibility in data collection and management), limits the power of the Registry (where competition is less relevant).
We should give independent advice to the Board only if we believe that the two models provide substantially different benefits to the registrants.
Roberto GAETANO
ALAC
ICANN BoD Liaison






From: Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>
To: alac@xxxxxxxxx
Subject: [alac] .net: Thick vs. thin registry, WHOIS models
Date: Wed, 11 Aug 2004 18:31:15 +0200

As you may have noticed, the GNSO's advice on .net is explicitly
undecided on whether the .net registry should change from the
current thin model (as known from .com) to the thick model (as in
.info).

With the thin model, registrant data remains with the registrar; the
registry only knows the mapping from a domain name to a registrar,
and knows about the name servers. WHOIS services operated by the
registry publish that mapping; the registrant's identity is then
published by the registrar.

With the thick model, registrant data is also kept by the registry,
and the registry's WHOIS services publish these data.

With the .org reassignment, a transition from a thin registry model
to a thick one took place.


There are tradeoffs between the two.

The thick model is, on its surface, better for data users who get
uniformly formatted data from a single source.  Of course, this is
nothing that couldn't be achieved by deploying properly standardized
software -- just think about the DNS itself, which is
decentralized.

From a registrant perspective, the thick model takes care of escrow
concerns -- the assumption here is that the registry keeps its data
more secure than "some registrar," so it becomes easier to deal with
business or physical failures of registrar businesses.

A centralized storage of registrant information also makes transfers
and registry-level transfer enforcement easier, which generally is a
good thing in my book.


On the other hand, a thick registry model implies transfers of registrant data across the boundaries of jurisdictions with different privacy regimes, and it takes away control over the publication of WHOIS data from registrars who may be subject to relevant national law in a more direct way, and who may be more accessible to registrants attempting to enforce their privacy rights. (Think registrar in EU, registry in US.)


Personally, I certainly prefer a thin WHOIS model, or at the very least a thick model that quacks like current thin WHOIS, i.e., leaves the choice of data elements published by registries to the registrar.

What do others think about this?  Should we give independent advice
to the ICANN board on this topic?  (If so, we would have to finish
this advice ASAP, since the RFP is supposed to start by 1 October
2004.)


References:

* .net procedure
  http://www.icann.org/announcements/announcement-29jun04.htm

* Announcement of GNSO's .net criteria
  http://icann.org/announcements/announcement-10aug04.htm


Regards, -- Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx> At-Large Advisory Committee: http://alac.info/

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus





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

Privacy Policy | Terms of Service | Cookies Policy