RE: [EPP-discuss] End customer confirmation process for registration

From: Boris Fernandez <Boris.Fernandez_at_GroupNBT.com>
Date: Tue, 10 May 2011 11:58:43 +0000

I fully agree. This is not the place.

What I am trying to propose is a system that will make our life easier in a way where we do not create any domain name that we will have subsequently to delete if the owner do not catch the email from DK-Hostmaster. Then we will avoid to get on those heavy post processing workflow to remind people what to do, to create credit note, etc..

We are currently this system of handshake with Nominet, for the transfers. Basicaly the end customer must request a TAG change to nominet and then we can deny it if we do not have an order placed in our system

I know this is not resolving the fact we would like this process to be managed by us in trust with DK-hostmaster... but as you just say this is not the place for this discussion and I am trying to focus in the technical part :)

I will gladly support any other mailing to discuss administrative and legal process :)





Best regards,
Boris A. Fernandez
Application Support Team Leader
Direct:
+45 33 88 63 41
Mobile:
+45 27 53 63 41
Office:
+45 33 88 61 00
Fax:
+45 33 88 61 01
www.ascio.com

Islands Brygge 55, 2300 Copenhagen S, Denmark
A Group NBT company
............................................................................................................................
The information in this internet email is confidential and
may be legally privileged. It is intended solely for the addressee.
Access to this internet email by anyone else is unauthorized.
If you are not the intended recipient, any disclosure, copying,
distribution or any action taken or omitted to be taken in reliance
on it is prohibited and may be unlawful.
............................................................................................................................


-----Original Message-----
From: Eva Frölich [mailto:eva_at_frobbit.se]
Sent: 10. maj 2011 13:49
To: EPP-discuss_at_liste.dk-hostmaster.dk
Cc: Boris Fernandez
Subject: Re: [EPP-discuss] End customer confirmation process for registration



I´m not sure the prereg process you propose makes it easier. A system
that meets the demands from the holders in a for everybody (registry,
registrar, registrant) secure and easy way is what I think we shall aim for.

I´m not in favour of continuing with the current system but I think you
are right on the spot when you say "Why do you not just trust your
partner to handle this process for you and then to provide you with the
data whenever you need ?".

Though - for DK-Hostmaster to trust their Registrars means that they
need to do what IIS started in 2007 and finalised in 2009 when they went
not only EPP, but also Registry-Registrar Business Model. That change
meant IIS defined the roles of registry, registrar and registrant as
well as created a framework agreed by the entire community. And inforced
it by worked through agreements.

I though understood this mailinglist is not for discussing change of
business model. If (as?) there is a need for such discussion I propose
that Jonas bring this into DK-Hostmaster and that we ask them to create
a separate mailinglist regarding going RRM.

/ Eva


Boris Fernandez skrev 2011-05-10 09:35:
> Hi everyone,
>
> First I want to say it was a pleasure to be at the meeting yesterday for the first time. My danish is far to be good enough to understand everything in details but I could make some of the thing translated to me.
>
> I want to talk again about how DK-Hosmaster get the confirmation from the end customers and why this is not a good process for all of us. And maybe I will with my suggestion, make a contribution
>
> It is clear to me this process gives us more work and problem than anything else. We spend a lot of time post registration chasing our customers, manualy or automaticaly, to remind them to activate the domain names. As a registrar we expect to do nothing after a registration of a domain name . Once it is registered, we cash and the end customer is happy.
>
> In our mind all work of identification should be done pre-registration.
>
> Before I start with my suggestion I want to stress out than a lot of NIC, that are known for their strict validation and acceptance terms, have make our life easier since the past 3 years. The AFNIC with the .FR . IIS with .SE and NORID with .NO
>
> So here come my suggestion : Handshake request
>
>
> If a end customer have opted to register a domain name he will have to go on line to the DK-Hostmaster website where he will have to confirm this registration and then a notification via EPP (to poll) or email will be generated and send to the registrars (or whatever we call it) . Then the registrar can aknowledge this registration and start it.
>
> So practically how does it work.
>
> 1 (optional) - End customer go to the ISP/Registrar website, start the registration of the domain name xxx001.dk. The ISP/Registrar inform the end customer he have to go on DK-Hostmaster to confirm his request, and then hold the order
> 2 - The end customer go to the DK-Hostmaster website to an online form, enter the domain name xxx001.dk and the ID of the provider he have chosen
> 3 - DK Hostmaster start the confirmation process via email, pdf, phone call, fax, courrier or whatever suit them.
> 4 - The end customer confirm it (or not)
> 5 - DK - Hostmaster notify the ISP/Registrar via EPP or email they have receive a confirmation request to register the domain name xxx001.dk
> 6 - ISP/Registrar check their system if they have an order for the corresponding domain name xxx001.dk and accept (ack) the handshake and send the registration
> 7 - Done
>
> - On steps 5 and 6, the handshake notification could contain a code generated by DK-Hostmaster who should be reuse on the registration order together wih the owner's email address as a reference. This to make sure the registration match the one we have on our system. After all we can have sometime different request from different end customers.
> We could also imagine it could be our responsibility to generate this code we will give to the end customer during step 1 and he will have to enter it, together with domain name and provider, on step 2. This will be an optional code to give on the step 2. If it is not there then DK-Hostmaster will generate it and send it together with the handshake.
>
> - If step 1 was ignored by the end customer then the registrar can or not Acknowledge the message and reject the registration at step 6. Or they can wait for a period of time of 10 days to receive the order and then to ack the message. The handshake Notification from DK-Hostmaster should be alive for a certain period of time before the end customer have to do it all over again.
>
> Why this could be a good solution is that we can get rid of those 10 percent non confirmed registration who generate a lot of work for us. when we will receive a registration and we close our orders we are sure we do not have to follow up on anything else. Peace of mind.
>
> Then it will comply with DK-Hostmaster regulation to identify the end customer (even though it remain to know if an email is enough to do such identification)
>
> This is just to invert the process of confirmation from post registration to pre registration
>
> This is my suggestion and I can take any comments and questions about it.
>
>
>
> On a personal note... please look at the IIS , the NIC .SE. They had a very strict way to confirm the registration. Now they trust us to confirm registration with customers by making them sign digitaly and on line , on our website , the Term and condition of the NIC before we start the registration. This is working like a charm . Sending an email out to a person do not garanty you to identify him as the right owner. Why do you not just trust your partner to handle this process for you and then to provide you with the data whenever you need ?
>
> We do that everyday as a registrar by sending the ICANN reports on some activities we do toward end customers... We can help implementing such a process if this is needed
>
>
>
> Best regards,
> Boris A. Fernandez
> Application Support Team Leader
> Direct:
> +45 33 88 63 41
> Mobile:
> +45 27 53 63 41
> Office:
> +45 33 88 61 00
> Fax:
> +45 33 88 61 01
> www.ascio.com
>
> Islands Brygge 55, 2300 Copenhagen S, Denmark
> A Group NBT company
> ............................................................................................................................
> The information in this internet email is confidential and
> may be legally privileged. It is intended solely for the addressee.
> Access to this internet email by anyone else is unauthorized.
> If you are not the intended recipient, any disclosure, copying,
> distribution or any action taken or omitted to be taken in reliance
> on it is prohibited and may be unlawful.
> ............................................................................................................................
>
> -----Original Message-----
> From: Jonas B. Nielsen [mailto:jonasbn_at_dk-hostmaster.dk]
> Sent: 6. maj 2011 14:08
> To: EPP-discuss_at_liste.dk-hostmaster.dk
> Subject: Re: [EPP-discuss] EPP status presentation from registrar meeting in Århus/Denmark 2011-05-04
>
> Hello,
>
> On 06/05/2011, at 13.48, Boris Fernandez wrote:
>
>> Thank you Jonas,
>> It sound great
>>
>> How can we structure and archive those discussion for the incoming iterations ?
>>
>
> I have no silver-bullet on how to handle this, but I will do my best to try to identify requests sent to the list. When identified I will put these in my request tracking system. Unfortunately this is not public available, but I will do my best to communicate reference numbers from the system for unique identification.
>
>> What I mean is that dropping idea, request, suggestion etc... on a mailing list can be very difficult to follow up both for you and us.
>>
>
> To make this as easy as possible requires that information sent to the list is concise and focused. If this does not work out I will investigate what other options we will have for use of collaborative tools.
>
>> Will you organise some other meeting and seminar during the incoming year where all the exchange in this mailing will be sumarise on an early stage for review and acceptance ?
>>
>
> That is a magnificent idea, I am sure it will be very beneficial to the project and implementation as a whole.
>
>>
>>
>> Kristian,
>>
>>> (and btw we found a legal way to automate activation of .dk domains)
>>
>> This is indeed a great news :)
>>
>>
>>
>> Best regards,
>> Boris A. Fernandez
>> Application Support Team Leader
>> Direct:
>> +45 33 88 63 41
>> Mobile:
>> +45 27 53 63 41
>> Office:
>> +45 33 88 61 00
>> Fax:
>> +45 33 88 61 01
>> www.ascio.com
>>
>> Islands Brygge 55, 2300 Copenhagen S, Denmark
>> A Group NBT company
>> ............................................................................................................................
>> The information in this internet email is confidential and
>> may be legally privileged. It is intended solely for the addressee.
>> Access to this internet email by anyone else is unauthorized.
>> If you are not the intended recipient, any disclosure, copying,
>> distribution or any action taken or omitted to be taken in reliance
>> on it is prohibited and may be unlawful.
>> ............................................................................................................................
>>
>>
>> -----Original Message-----
>> From: Jonas B. Nielsen [mailto:jonasbn_at_dk-hostmaster.dk]
>> Sent: 6. maj 2011 13:39
>> To: EPP-discuss_at_liste.dk-hostmaster.dk
>> Subject: Re: [EPP-discuss] EPP status presentation from registrar meeting in Århus/Denmark 2011-05-04
>>
>> Hello Boris,
>>
>> Well I would like to do iterative releases along a the following lines:
>>
>> 1. Preliminary specification
>> 2. Specification
>>
>> 3. Feature implementation
>> 4. Feature release to test environment
>>
>> Repeating 3 and 4 until specification has been met.
>>
>> 5. Release to production
>> 6. Cloning of production setup to Sandbox and Test environments
>>
>> 8... Futher life-cyle with new releases (bug fixes, features etc.) being deployed to Test prior to being released to Production and Sandbox. This will reflect a cycle along the lines of all of the above points in shorter cycles.
>>
>> The test environment will always reflect upcoming releases, changes to specifications will be sent out to document these accordingly. I expect most of these features to be discussed on this list, since the initial requests will most likely be coming from registrars.
>>
>> The sandbox environment will be a non-destructive or at least very forgiving environment mimicking production. Designated to allowed clients to develop against without having to feel like chasing a moving target (test).
>>
>> jonasbn
>>
>> On 06/05/2011, at 11.48, Boris Fernandez wrote:
>>
>>> Jonas,
>>>
>>>> I am aiming for an iterative release process, so we might have a more realistic and pragmatic approach to getting the specification and software out to you
>>>
>>> Do you have an idea if this will be done before you go live ? I am following you on that one and you got the right thoughts.
>>>
>>> But have you already decided if you will give us access to a testing environement, and soon enough for us to test everyting before the release ?
>>>
>>> To be honest I hope I won't have again to implement something like .NU... half EPP, Half email callbacks or phone calls =) instead of giving us a environement to test prior launch they decided to go live directly with it, and now we have to wait for them to implement the rest of it....
>>>
>>> And to bounce on Tobias about Nomitet, If you are lucky (or mad) enough you have implemented the Nominet EPP... otherwise you are on their standard EPP with half of the option you could use on their EPP and you still have stuff to do online :)
>>>
>>>
>>>
>>>
>>>
>>> Best regards,
>>> Boris A. Fernandez
>>> Application Support Team Leader
>>> Direct:
>>> +45 33 88 63 41
>>> Mobile:
>>> +45 27 53 63 41
>>> Office:
>>> +45 33 88 61 00
>>> Fax:
>>> +45 33 88 61 01
>>> www.ascio.com
>>>
>>> Islands Brygge 55, 2300 Copenhagen S, Denmark
>>> A Group NBT company
>>> ............................................................................................................................
>>> The information in this internet email is confidential and
>>> may be legally privileged. It is intended solely for the addressee.
>>> Access to this internet email by anyone else is unauthorized.
>>> If you are not the intended recipient, any disclosure, copying,
>>> distribution or any action taken or omitted to be taken in reliance
>>> on it is prohibited and may be unlawful.
>>> ............................................................................................................................
>>>
>>>
>>> -----Original Message-----
>>> From: Jonas B. Nielsen [mailto:jonasbn_at_dk-hostmaster.dk]
>>> Sent: 6. maj 2011 11:32
>>> To: EPP-discuss_at_liste.dk-hostmaster.dk
>>> Subject: Re: [EPP-discuss] EPP status presentation from registrar meeting in Århus/Denmark 2011-05-04
>>>
>>> Hello Benny,
>>>
>>> I think you must have misunderstood something.
>>>
>>> As I recall Per said that DK Hostmaster regards EPP as a channel to our systems/backend. This is something I support, since it is how it fits into my architectural perspective of how software systems generally should work.
>>>
>>> We might have mentioned that we have a working EPP solution, which was created years ago, but it was never deployed. It might have been me who mentioned this at the meeting since I was involved in the actual implementation. In retrospect I am glad it never was deployed.
>>>
>>> 1. It only implement a very limited set of the EPP commands
>>> 2. It relies heavily on extensions
>>> 3. It would be hard to move a way from it once it was deployed
>>>
>>> Back then It was my hope to get that existing solution deployed to get some traction, this might have been defined by me to be about Q1/2011. I am going to be more careful with dates in the future. Please also see my response to Boris in this thread. I am aiming for an iterative release process, so we might have a more realistic and pragmatic approach to getting the specification and software out to you.
>>>
>>>
>>> jonasbn
>>> --
>>> Jonas Brømsø Nielsen
>>>
>>> Software Developer at DK Hostmaster A/S
>>> http://www.dk-hostmaster.dk
>>> +45 31546056
>>>
>>> On 06/05/2011, at 11.17, Benny - ISPHuset Nordic AS wrote:
>>>
>>>> Thats rather funny because I am sure that on the Copenhagen meeting it was pointed out by Per Kølle that the EPP was already running in the backend and only minor things where to be done... Are you now saying that this was not true at the moment it was told to the registrars attending the meeting?
>>>>
>>>> /Benny
>>>> ISPHuset
>>>>
>>>> -----Original Message-----
>>>> From: Jonas B. Nielsen [mailto:jonasbn_at_dk-hostmaster.dk]
>>>> Sent: 6. mai 2011 11:12
>>>> To: EPP-discuss_at_liste.dk-hostmaster.dk
>>>> Subject: Re: [EPP-discuss] EPP status presentation from registrar meeting in Århus/Denmark 2011-05-04
>>>>
>>>> Hello,
>>>>
>>>> There is no current EPP implementation and the presentation from the Århus meeting was aimed at trying to give a response to some of the attending registrars had raised at earlier occasions. This should give a basic outline of some of the requirements under which the EPP solution is going to be working.
>>>>
>>>> I hope it will not be necessary to implement special extensions, but I do not have a complete overview of the extent at this time, well at not in a publishable format anyway.
>>>>
>>>> jonasbn
>>>> --
>>>> Jonas Brømsø Nielsen
>>>>
>>>> Software Developer at DK Hostmaster A/S
>>>> http://www.dk-hostmaster.dk
>>>> +45 31546056
>>>>
>>>> On 06/05/2011, at 10.33, Patrik Fältström wrote:
>>>>
>>>>> What is needed is from DK-Hostmaster a detailed description of the EPP status of .DK, what features in .EPP is in use, and the evaluation I take for granted DK-Hostmaster have done regarding deciding on extensions that are special for .DK, and what extensions have been inherited from other TLDs. And if private .DK special extensions have been chosen, an explanation on why.
>>>>>
>>>>> Any special extension a registry chooses imply great cost for the registrars, and unfortunately, as a registrar, I see TLDs unfortunately take too lightly how complicated it is to manage private extensions.
>>>>>
>>>>> So, I have great hope DK-Hostmaster have chosen to not create any private extensions at all, and in worst case have inherited same extensions as some other TLDs.
>>>>>
>>>>> Patrik
>>>>>
>>>>> On 6 maj 2011, at 10.29, Benny - ISPHuset Nordic AS wrote:
>>>>>
>>>>>> Seriøst ?
>>>>>>
>>>>>> Den fortæller jo ingenting...
>>>>>>
>>>>>> /Benny
>>>>>> ISPHuset
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Jonas B. Nielsen [mailto:jonasbn_at_dk-hostmaster.dk]
>>>>>> Sent: 6. mai 2011 9:59
>>>>>> To: epp-discuss_at_liste.dk-hostmaster.dk
>>>>>> Subject: [EPP-discuss] EPP status presentation from registrar meeting in Århus/Denmark 2011-05-04
>>>>>>
>>>>>> By request I hereby forward the presentation from the recently held registrar meeting in Århus/Denmark.
>>>>>>
>>>>>> The slides are in Danish, but it should not be anything Google translate cannot handle.
>>>>>>
>>>>>> jonasbn
>>>>>> --
>>>>>> Jonas Brømsø Nielsen
>>>>>>
>>>>>> Software Developer at DK Hostmaster A/S
>>>>>> http://www.dk-hostmaster.dk
>>>>>> +45 31546056
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
>

-- 
-----------------------------
Eva Frölich
Frobbit AB
Mail: eva_at_frobbit.se
Phone: +46 417 77 39 82
mobile: + 46 709 68 50 59
sip: eva_at_frobbit.se
www.frobbit.se
Received on Tue May 10 2011 - 13:58:43 CEST

This archive was generated by hypermail 2.3.0 : Fri Feb 06 2015 - 11:39:02 CET