<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [registrars] thick RRP client
Ivan Vachovsky wrote:
>
> Fellow Registrars,
>
> 1. We are developing the RRP client for the new gTLD .info. Our developers
> are reporting that we are going to send ALL customer details to the
> Registry.
>
> I remember that the prevailing opinion in Marina Del Ray meetings last Fall
> was towards the thick RRP client. Can someone refresh my memory what were
> the advantages of this solution?
Intellectual Property Lawyers will be happy.
>
> Anyone concerned about passing his full customer's information to the
> Registry?
>
> Are we protected against abuse/leak of this information by the Registry,
> voluntarily, by accident or subject to sniffers?
They already have plans to release it.
>
> 2. Why ICANN does not step in and request the Registries to standardize on
> the RRP protocol?
I think the idea was to figure out the best
system, or something like that. Unfortunately the cost
of doing it this way was not considered.
> It appears now that each and every Registry will be using
> different protocol (or at least different flavor of the same protocol )
> making the life of the Registrars miserable?
Why should that matter? One protocol will emerge the
winner, and the author of that protocol will
get the MERIT BADGE. So what if it costs us money
(which is passed on to customers)?
> We have had hard time managing
> just one single relation with Verisign (numerous problems). Can you imagine
> this multiplied 5x times. Also the new registries will be definitely less
> experienced (at least in the beginning ). Any input on this?
For what it's worth it pisses me off also. On the
positive side it creates a significant barrier
to entry for new registrars and/or an opportunity
for people selling registrar software.
Larry Erlich
http://www.DomainRegistry.com
>
> Best regards,
> ----------------------------------------------
> Ivan Vachovsky,
> CEO
> Names4Ever
>
> ----- Original Message -----
> From: "Werner Staub (CORE Secretariat)" <secretariat@corenic.org>
> To: "Michael D. Palage" <michael@palage.com>
> Cc: <registrars@dnso.org>; <secretariat@corenic.org>
> Sent: Tuesday, July 24, 2001 11:53 AM
> Subject: Re: [registrars] Draft Letter
>
> > Hi Mike,
> >
> > Great job. I know everything cannot be said in a letter, but
> > I find that the following facts ought to be stated:
> >
> > 1) The transfer procedure has been designed *by* Verisign,
> > including all the rules shown in the letter.
> >
> > 2) If the registry were not related to the largest registrar,
> > it would have reformed the transfer procedure rather than
> > allowing a registrar to unilaterally deform it.
> >
> > 3) The remedies proposed by Verisign are designed to further
> > increase the cost of transfers as a barrier against competition.
> >
> > 4) We ask Verisign to discontinue the auto-nack methods *immediately*,
> > All registrars are willing to work on improving the transfer
> > framework with low cost and high security as objectives.
> >
> > Regards,
> >
> > Werner
> >
> >
> > "Michael D. Palage" a *crit :
> > >
> > > Attached please find the proposed letter to Stuart drafted in accordance
> > > with the discussion during yesterday's teleconference and which the
> > > Constituency proposes sending to ICANN. I believe that the letter
> achieves
> > > the objectives stated in our teleconference yesterday. Please provide
> any
> > > comments to the letter during the next 24 hours so that I can submit it
> to
> > > ICANN ASAP. This letter is important to the ongoing consensus building
> > > efforts that the Constituency has undertaken and I urge all member to
> review
> > > this letter closely.
> > >
> > > Best regards,
> > >
> > > Michael D. Palage
> > >
> > > Name: Registrars-July24.doc
> > > Registrars-July24.doc Type: Microsoft Word Document
> (application/msword)
> > > Encoding: base64
--
-----------------------------------------------------------------
Larry Erlich - DomainRegistry.com, Inc.
215-244-6700 - FAX:215-244-6605 - Reply: erlich@DomainRegistry.com
-----------------------------------------------------------------
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|