RE: [EPP-discuss] Forthcoming feature releases of the EPP service: renew

From: Boris Fernandez <Boris.Fernandez_at_ascio.com>
Date: Thu, 14 Apr 2016 12:48:38 +0000

Jonas,

There is two way to manage autorenewal. Or you explicitly renew the domain name via EPP, and that is only possible by the registrar doing, or the NIC renew the domain name at expiry date for ever until you explicly delete the domain name.

In your EPP and NIC model, anyone can do the renew and therefore the "registrars" handling those domain name will never know if it has been done outside their management. Point is : will there be any way to know if someone has renew a domain name I manage for my resellers ? And yes it is well understood than if I do myself a renew and the expiry dates do not match you will let me know.

Will you push some message via EPP polling to us to show us "update/renew" of the domain name if we are the registrar and if the command wasn't done by us ?



-----Original Message-----
From: Jonas Nielsen [mailto:jonasbn_at_dk-hostmaster.dk]
Sent: 14. april 2016 14:39
To: Tom Sommer <ts_at_zitcom.dk>
Cc: Ashley La Bolle | EPAG Domainservices GmbH <al_at_epag.de>; Benny Samuelsen - ISPHuset Nordic AS <benny_at_isphuset.no>; Rieke Poppe - One.com <rm_at_one.com>; epp-discuss_at_liste.dk-hostmaster.dk
Subject: Re: [EPP-discuss] Forthcoming feature releases of the EPP service: renew

Hi Tom,

I have gone over the EPP specification and I am not able to find anything on auto renewal apart from a mention in RFC:5730 under poll, since this is not a part of standard EPP it was not in my current scope.

Can you give me an overview of the requirement for auto renewal, is this a defacto standard across registries?

See further comments below

> On 14 Apr 2016, at 11:44, Tom Sommer <ts_at_zitcom.dk> wrote:
>
> Actually, a colleague just presented me with a possible issue.
>
> Say a customer has an account with both UnoEuro and One.com, both set to autorenewal. Now which registrar gets to autorenew? Both do, but the one who autorenews first, wins - which might not be the correct registrar and not the one the customer actually wants to perform the renewal.
>

A precedence rule could be implemented so auto-renew would only be available for one registrar at a time, meaning first-come first-served. And in addition billing-c auto renewal could again have higher precedence due to higher cohesion.

> So, obviously a 'good way' to figure out who can renew a domain would
> be preferred, and so we're back to <clID> :) The best alternative to <clID>, that I can think of, would be that billing-c and nameserver-owner could renew.
>

billing-c demonstrates clear cohesion, I am not settled on nameserver-owner renewal, I will have to evaluate that particular requirement more thoroughly.

> // Tom
>
>
> -----Original Message-----
> From: Jonas Nielsen [mailto:jonasbn_at_dk-hostmaster.dk]
> Sent: 13. april 2016 15:41
> To: Tom Sommer <ts_at_zitcom.dk>
> Cc: Ashley La Bolle | EPAG Domainservices GmbH <al_at_epag.de>; Benny
> Samuelsen - ISPHuset Nordic AS <benny_at_isphuset.no>; Rieke Poppe -
> One.com <rm_at_one.com>; epp-discuss_at_liste.dk-hostmaster.dk
> Subject: Re: [EPP-discuss] Forthcoming feature releases of the EPP
> service: renew
>
> Hi Tom,
>
> See below:
>
>> On 13 Apr 2016, at 15:26, Tom Sommer <ts_at_zitcom.dk> wrote:
>>
>> If we are required to set ourselves as billing-c -> perform the renew -> unset ourselves as billing-c, this function becomes essentially useless to us and to our customers, it will be nothing but a headache for them and us.
>>
>
> Understood
>
>> We need to be able to renew a domain even if we are not billing-c, which is how EPP normally works - since the permission to renew is usually held by the <clID>, and not the billing-c. Since DKHM does not have a <clID> concept, a reasonable compromise would that any registrar can perform a renew on any domain, until a better permission-scheme is found.
>>
>
> Acknowledged
>
>> Since YOU are performing the EPP-RENEW command, you do not need a poll about it, if someone else performs a renew on a domain to which you are attached, or the customer/DKHM does, an epp-poll should be issued to you.
>>
>
> Noted
>
>> It would be nice if the procedure regarding who is billed (the registrar issuing the renewal, and not the billing-c) could be further explained in the draft, just for clarity.
>>
>
> I will try to outline the further processing and side-effects.
>
>> Just my thoughts.
>
>
> Thanks for your feedback
>
> jonasbn
>
>>
>>
>>
>>
>> --
>> Tom Sommer (via OWA)
>> Zitcom A/S
>> From: Ashley La Bolle | EPAG Domainservices GmbH <al_at_epag.de>
>> Sent: Wednesday, April 13, 2016 2:16 PM
>> To: Tom Sommer
>> Cc: Benny Samuelsen - ISPHuset Nordic AS; Rieke Poppe - One.com;
>> Jonas Nielsen; epp-discuss_at_liste.dk-hostmaster.dk
>> Subject: Re: [EPP-discuss] Forthcoming feature releases of the EPP
>> service: renew
>>
>> Hi Tom,
>>
>> would the billing-c be notified via EPP of the expiration date change?
>>
>> We don't troll registries for 'unexpected changes' in the expiration date so if the expiration date was just bumped forward, we would be left with a mismatch bewteen ourselves and the registry. Even worse, I would have no explanation for our customers for how this happened...
>>
>> Best,
>> Ashley
>>
>> Am 13.04.2016 um 14:08 schrieb Tom Sommer:
>>> That's not how it would work. The person doing the renew would be billed. Not the billing contact.
>>>
>>> --
>>> Tom Sommer (via iPhone)
>>>
>>> On 13. apr. 2016, at 14.00, Ashley La Bolle | EPAG Domainservices GmbH <al_at_epag.de> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have to agree with Benny here... I don't want to run into the situation where someone else can send a command to renew a domain but I (as the billing contact) am charged for the renewal. Because the DK automation is so asynchronous, that renewal information wouldn't be correctly registered in our system so there's a good chance we would be billed but wouldn't know to charge the client.
>>>>
>>>> It just gets very messy :)
>>>>
>>>> Best,
>>>> Ashley
>>>>
>>>> Am 13.04.2016 um 13:33 schrieb Benny Samuelsen - ISPHuset Nordic AS:
>>>>> I don't agree we do not want a situation like Joker where anyone can renew a domain.
>>>>>
>>>>> It will be a mess if the domain are not connected to a billing
>>>>> handle we can connect to our registrar somehow
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Benny Samuelsen
>>>>>
>>>>> benny_at_isphuset.no
>>>>>
>>>>>
>>>>> ISPHuset Nordic AS
>>>>> Arupsgate 18
>>>>> 3015 Drammen
>>>>>
>>>>> Tlf sentralbord +47 3226 0200
>>>>> Faks +47 3281 1355
>>>>>
>>>>> www.isphuset.no
>>>>> www.facebook.com/isphuset
>>>>> www.twitter.com/isphuset
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>> On 13 Apr 2016, at 13:29, Rieke Poppe - One.com <rm_at_one.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>>>
>>>>>>>
>>>>>> sounds good. Only comment from here is that I think we should skip the requirement of being billing contact to do a renew command.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>>
>>>>>>>
>>>>>> best regards
>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Rieke Poppe (RM)
>>>>>>
>>>>>>> Domain Operations Manager, One.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> On 13/04/16 09:17, Jonas Nielsen wrote:
>>>>>>
>>>>>>>>>
>>>>>>> Hello all,
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> We are starting to work on our EPP road map shortly. As previously announced we plan to do a series of feature releases, each holding a single feature.
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> First feature we are looking into is renew based on the feedback provided to us by users of our EPP service.
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> I have updated our EPP specification as a draft describing this first feature. The draft is available here:
>>>>>>>
>>>>>>>>>
>>>>>>>>> https://github.com/DK-Hostmaster/epp-service-specification/tre
>>>>>>>>> e/epp_renew_domain_v1#renew-domain
>>>>>>>>>
>>>>>>>>>
>>>>>>> The additional drafts will be in separate branches and upon implementation the branch will be merged into the released specification.
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> Discussion on the feature are most welcome here on the list, you can also write directly to me, but the first will be appreciated, to keep an open discussion and getting feedback archived publicly.
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> Spelling errors etc. can be sent to me or offered via merge request on Github.
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> Looking forward to your feedback,
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> jonasbn
>>>>>>>
>>>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>>>
>>>>>>> Med venlig hilsen/Best Regards
>>>>>>>
>>>>>>>>>
>>>>>>> Jonas B. Nielsen
>>>>>>>
>>>>>>>>>
>>>>>>> Development Team Leader / Team leder for Udvikling
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> Kalvebod Brygge 45, 3. sal
>>>>>>>
>>>>>>>>>
>>>>>>> 1560 København V
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> Tlf. +45 33 64 60 60
>>>>>>>
>>>>>>>>>
>>>>>>> Fax.: +45 33 64 60 66
>>>>>>>
>>>>>>>>> Email: jonasbn_at_dk-hostmaster.dk
>>>>>>>>> Homepage: https://www.dk-hostmaster.dk
>>>>>>>>>
>>>>>>>>>
>>>>>>> .dk Danmarks plads på Internettet
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> ----------------------------------------------------------------
>>>>>>> ---------
>>>>>>>
>>>>>>>>>
>>>>>>> Dette er en e-mail fra DK Hostmaster A/S. Denne e-mail kan
>>>>>>> indeholde
>>>>>>>
>>>>>>>>>
>>>>>>> fortrolig information, som kun er til brug for den tiltænkte modtager.
>>>>>>>
>>>>>>>>>
>>>>>>> Hvis du ved en fejl har modtaget denne e-mail, bedes du venligst
>>>>>>> straks
>>>>>>>
>>>>>>>>>
>>>>>>> give afsenderen besked om dette og slette e-mailen fra dit
>>>>>>> system uden
>>>>>>>
>>>>>>>>>
>>>>>>> at offentliggøre, videresende eller tage kopi af meddelelsen.
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> This is an email from DK Hostmaster A/S. This message may
>>>>>>> contain
>>>>>>>
>>>>>>>>>
>>>>>>> confidential information and is intended solely for the use of
>>>>>>> the
>>>>>>>
>>>>>>>>>
>>>>>>> intended addressee. If you are not the intended addressee please
>>>>>>> notify
>>>>>>>
>>>>>>>>>
>>>>>>> the sender immediately and delete this e-mail from your system.
>>>>>>> You are
>>>>>>>
>>>>>>>>>
>>>>>>> not permitted to disclose, distribute or copy the information in
>>>>>>> this
>>>>>>>
>>>>>>>>>
>>>>>>> e-mail.
>>>>>>>
>>>>>>>>>
>>>>>>> ----------------------------------------------------------------
>>>>>>> ----------
>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>
>>
>
>
Received on Thu Apr 14 2016 - 14:48:38 CEST

This archive was generated by hypermail 2.3.0 : Thu Apr 14 2016 - 14:49:00 CEST