[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Patrycja Wegrzynowicz <patrycjaw@nask.pl>
Cc: ietf-provreg@cafax.se
From: Gerhard Winkler <gerhard.winkler@univie.ac.at>
Date: Mon, 24 Oct 2005 10:41:01 +0200
In-Reply-To: <4357D9E8.8050801@nask.pl>; from Patrycja Wegrzynowicz on Thu, Oct 20, 2005 at 07:54:48PM +0200
Sender: owner-ietf-provreg@cafax.se
Subject: Re: [ietf-provreg] EPP domain:transfer

On Thu, Oct 20, 2005 at 07:54:48PM +0200, Patrycja Wegrzynowicz wrote:
> Gerhard Winkler wrote:
>  > For clarification (maybe I was too short in my explanation):
>  > the token, generated by the registry, is sent to the registrant, and
>  > for confirmation the registrant has to send the token to the
>  > gaining registrar (who has initiated the transfer also).
>  > The losing registrar doesn't play any role in our transfer process
>  > (except of receiving notifications of course).
> 
> Hi Gerhard,

Hi Patrycja!


> 
> Scott's proposal sounds very fine for your case; although I'd like to 
> put my 2 cents to your problem. ;)
> 
> 1. Considering Scott's approach one MINOR note to mention:
> <domain:update> command must be sent by the registrar which is
> not the sponsoring client. It's only the minor note as according to EPP
> standard the restriction of this action to the sponsoring client is only
> recommended. However, worth to keep this in mind.

That's the point where I feel uncomfortable.
It's not very nice to implement a policy checking module for access rights
where every business case is handled in one way except one single
transaction which is handled in another way.
But it's manageable to implement.


> 
> 2. Your transfer process seems a lot like ours (.PL registry). .PL also
> requires the registrant to confirm/authorize the transfer request.
> Although the implementation is a bit different from yours proposal:
> - the gaining registrar sends <domain:transfer> request
> - the registry sends email with 'confirmation link' to the registrant
> - the registrant clicks 'confirmation link' and then the transfer is done


This is exactly what we are currently doing.


> 
> As you see we decided to skip forwarding token forth-and-back in the
> registry/registrar/registrant circle. From the semantic point of view
> IMO it's more clear since such round-trip seems redundant. I see some
> possible explanations of the 'token' approach... although it's more
> question to you... what are your reasons behind having token approach
> instead of, for example, direct confirmation?



One advantage for the gaining registrar is to control the point in time
when the transfer is passed. The gaining registrar is able to initiate
other transactions without polling the registry for the current status
of the transfer immediately.


From the semantic point of view you can see it also the other way round.
The registrant gives authorization to the registrar for a transaction.
This can be embeded in a more complex process at the registrars side.


kind regards
-Gerhard



-- 
Gerhard Winkler                    |  E-Mail: gerhard.winkler@univie.ac.at
Vienna University Computer Center  |
Universitaetsstrasse 7             |  Tel: +43 1 4277 14035
A-1010 Vienna, Austria             |  Fax: +43 1 4277 9140

Home | Date list | Subject list