[registrars] FW: BOUNCE registrars@dnso.org: Non-member submission from [rick@ar.com]

["Michael D. Palage" <michael@palage.com>]

This was a message that Rick Wesson attempted to post, but because it was
from an unauthorized email account it was bounced.

Mike

RICK'S EMAIL


Ivan,

The new protocol is called EPP and there is a standardization effort in the
IETF. RRP (the Verisign version) was never standardized. see
http://www.ietf.org/html.charters/provreg-charter.html

If you haven't figured it out registrars now have a technical challenge to
meet in managing a single interface to many registries over many
protocols.

I hope our collective experience with the current roll out will be fed back
into the ICANN process for selecting additional gTLDs, so that in the
future we can have it a little easier.

-rick


On Tue, 24 Jul 2001, 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?
>
> 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?
>
> 2. Why ICANN does not step in and request the Registries to standardize on
> the RRP protocol? 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? 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?
>
> 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
>