I have been trying to get a similar point through...

I am a strong believer in contact IDs uniformity and consistency. Ie. all 
contact IDs managed through all registrars should be ROIDs. Unfortunately, 
for no reason I can see, most registrars have developed their own 
proprietary system of NICs which in term map back down to ROIDs in the 
background. The management of these is poor, especially if managing domains 
through different registrars - giving birth to scenarios like the one you 
have described.

How can we get registrars to switch to pure ROIDs as contact IDs? Make it a 
rule for the newly accredited ones for a start.

At 07:35 PM 9/14/03 +1000, you wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I have a question about contact IDs.
>
>~From what I have seen personally as now domains are just starting to
>come up for renewal.
>
>With contact IDs.
>
>Transfering some domains away from MIT to other registrars I have
>noticed there appear to be no way to put in a contact ID, you have to
>fill in the details.
>
>The question this raises is that as ISP Hosting with Technical IDs into
>the domains and several domains with the same admin ID, from what I have
>been able to find they are all going to have different contact IDs.
>
>The question is doesnt that make the IDs fairly pointless. I mean there
>is no tracking or constant details for either auDA or the owners to
>track through the ID.
>
>Now this may have been done for a reason I am not seeing but I am not sure.
>
>Any one got any ideas? Is this for the Good, Bad or Ugly?
>
>David
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.2 (GNU/Linux)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iD8DBQE/ZDZTT1aQztc2W7wRAlIWAKC/neJYW48SLo7Jfw5VHML0AnSJkgCg4K+/
>pcbxHY0xBAx1cd2H0A8MCSo=
>=GNZn
>-----END PGP SIGNATURE-----
>
>
>---------------------------------------------------------------------------
>List policy, unsubscribing and archives => http://www.auda.org.au/list/dns/
>Please do not retransmit articles on this list without permission of the 
>author, further information at the above URL.

Kind regards,

Lucian Kafka
www.conexim.com.au