ICANN/GNSO GNSO Email List Archives

[registrars]


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

RE: [registrars] RE: [registrars] PIR

  • To: registrars@xxxxxxxx
  • Subject: RE: [registrars] RE: [registrars] PIR
  • From: Mike Lampson <lampson@xxxxxxxxxxxxxx>
  • Date: Fri, 06 Aug 2004 13:59:04 -0400
  • Cc: bbeckwith@xxxxxxx, twomey@xxxxxxxxx, halloran@xxxxxxxxx
  • Importance: Normal
  • In-reply-to: <200408061715.i76HFbT02948@holiday.com.at.spry.com>
  • Sender: owner-registrars@xxxxxxxxxxxxxx

>From a business perspective, I do not have a problem with PIR's proposed change to the DomainInfo command.   The answer is that to begin the transfer process, the requestor must have the AuthInfo code to enter the request into the gaining Registrar's system.

However from a technical perspective this lockdown seems to be a waste unless a similar lockdown occurs on the Whois side.  For one, if a Registrar is abusing the DomainInfo command, this should be apparent by counting the number of DomainInfo commands executed under the Registrar's login Id.  The same monitoring cannot be done from Whois as you cannot distinguish a Registrar from any other consumer of the Whois service.

There is also another issue that I have submitted as a query to PIR tech support.  Will the ContactInfo command be similarly locked down?  Once I have determined that I have a proper AuthInfo code to begin the process of initiating a domain transfer, I want to query the contact details to prepopulate my database.  There is no reason for the end-user to re-type the contact details already associated with the domain in the thick Registry.  As each contact will have its own AuthInfo code that is independent of the domain, it is not reasonable to have the end-user type in 5 different AuthInfo codes (1 for the domain and 1 each for the 4 types of contacts).

Regards,

Mike Lampson
The Registry at Info Avenue, LLC
 

-----Original Message-----
From: owner-registrars@xxxxxxxxxxxxxx
[mailto:owner-registrars@xxxxxxxxxxxxxx]On Behalf Of Jay Westerdal
Sent: Friday, August 06, 2004 1:16 PM
To: 'Thomas Keller'
Cc: 'Bruce Tonkin'; bbeckwith@xxxxxxx; twomey@xxxxxxxxx;
halloran@xxxxxxxxx; registrars@xxxxxxxx
Subject: RE: [registrars] RE: [registrars] PIR


Thomas,
I will skip the analogies since people don't own hundreds or thousands of driver licenses and most often we know they expire on their birth day.

The status of a domain at another registrar is very important for other registrars to know as well. Why try and transfer a domain that is in pending-delete? To make the registrant fill out a form and pay money, then only to tell him oops sorry, "We can't transfer that domain". Then going through the process of refunding him money. All for what, if status was known it would be simple to turn down the customer and tell him no upfront.

For Expiration date, if the domain expires in June of 2014, I know I can't transfer the domain since only 10 years of registration is allowed. Like wise, if the domain expires in 10 days, it would be important to transfer it. Most Registrants transfer only domain close to expiration. They may not transfer their whole portfolio in one shot. Customer service at your registrar will not even be able to look up a very important date.

VeriSign shows the bare minimum amount of information in their thin whois and even they show expiration date and domain status. If every gTLD Registry wants to be a little bit different on these core requirements then we will be dealing with 100 different handshakes soon.

I would ask PIR to place the referral whois server of the Registrar in the INFO command as well now, as we will need to query registrars if this happens. Registrars have peace of mind right now because no registrant information is present in the DOMAIN INFO command, but if to get the expiration date you have to query the registrar in addition, they will think the queerer is after registrant's personal information.

I hope that sound reasoning will prevail before the we have 100 different situation to code around.

Jay





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