To:
ietf-provreg@cafax.se, ietf-whois@imc.org
From:
Sheer El-Showk <sheer@laudanum.saraf.com>
Date:
Tue, 30 Jan 2001 08:54:46 -0500 (EST)
In-Reply-To:
<Pine.LNX.4.20.0101280636380.180-100000@graymalkin.teranix.net>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Sorry -- Re: Merging RRP and Whois
Hi, Sorry about the two double postings. I was using a non-subscribed email address and the postings didn't go through so I reposted ... I didn't know they'de just be delayed. Sheer On Sun, 28 Jan 2001, Sheer El-Showk wrote: > > Now, having lambasted the idea of lumping whois into provreg, I've a goofy > > idea. Can PROVREG recommend a scalable solution to the consideration of > > NIC-HANDLES? To my knowledge, this has never been addressed properly, at > > least since the days when the IR was split. When we did the RA project, the > > thought was to tag the NIC-HANDLE with the registrars "stamp", e.g. > > > > WM110-NSI > > WM110-RIPE > > WM110-ARIN > > > > but this leads, as friend Bush commented at the RIPE-37 mtg, to inconsistancies > > between registration agents. IN a nutshell, do we need globally unique IDs > > to the registering agents? If so, who administers that ID space? > > Why would we want global NIC handles? Transfers? Data-consistency? Making > life easier for the registrant? > > None of these seem sufficiently important to merit the kind of effort > (either bureacratic -- if its one big NIC Handle registry; or technical -- > if the registries used a shared/synced NIC Handle DB). Especially because > registries may not want to share their NIC handles for various privacy or > reasons. > > That having been said, what I like about an idea like this is it would > make it simpler to determine who is authoritative owner of a domain - an > issue I think we should really consider since it seems to be done mostly > by "out-of-band" methods (email's sent by the registry -- at least > Verisign -- to determine the domain owner) -- which I agree should > be eliminated. Still I think a focus on digitally certifying a domain is > the right way to go, rather than centralizing user information. > > Sheer > >