--On 4 March 2010 19:53:52 -0800 Doug Barton <do...@dougbarton.us> wrote:
On 3/4/2010 4:31 PM, Alex Bligh wrote:
May be it's not a thick vs. thin distinction per se, but a "what happens
if registrant falls out with registrar" distinction. Thick registries
that have a direct contract with the registrant (e.g. Nominet) tend tob
be rather less willing to let a losing registrar intermeddle. May be
this is isomorphic to the beneficial ICANN involvement suggested.
You're undoubtedly aware of this but in RRR parlance "thick" means that
the registry stores all of the registrant data, and in a "thin" registry
they store a subset (generally a very limited one) and a referral to the
registrar. The two terms have no reference to the nature of the
relationship between the registrant and the registry.
In the gTLD world the registrars jealously guard their relationships with
their customers (the registrants), and registries are not allowed to have
direct contact with them. This situation is unlikely to change in any
material way which is why I suggested ICANN involvement may be necessary
if there is agreement that conscious acts on the part of the losing
registrar will be required for the smooth transition of a secure zone.
Sure. And I don't want to expand a one-liner into more than it is
worth, nor start a discussion on the merits of various registry
models. All I was saying was that in a thin model, as the registry
has no direct contact with registrants, and as the canonical
source of zone data is in essence the registrar (that's
who the registrant gives his NS and DS records to), the DS (and, for
that matter the NS) records have more change to "get lost" when
moving between registrars than in a thick registry. As you point
out that means that ICANN involvement may be necessary/desirable
to fix that, and all I was saying was there may be less need for such
involvement in a thick registry model.
--
Alex Bligh
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
