Hi Ben and Michele, The requirement has been discussed in the context of the Thick Whois Policy implementation. Please see https://whois.icann.org/sites/default/files/files/thick-rdds-consensus-polic..., particularly section 2.1, starting on page 8. By the way, this document is in public comment at https://www.icann.org/public-comments/rdds-output-2015-12-03-en until 31 January. Regards, -- Francisco On 1/21/16, 2:30 PM, "gtld-tech-bounces@icann.org<mailto:gtld-tech-bounces@icann.org> on behalf of Benoit Levac" <gtld-tech-bounces@icann.org<mailto:gtld-tech-bounces@icann.org> on behalf of benoit.levac@rightside.co<mailto:benoit.levac@rightside.co>> wrote: Francisco, I don't see any explanation for making registries store and publish the "Registrar Registration Expiration Date" in the "ICANN Thick Whois Policy Recommendation". What is the use case we are trying to solve for? Ben On Thu, Jan 21, 2016 at 1:55 PM, Francisco Arias <francisco.arias@icann.org<mailto:francisco.arias@icann.org>> wrote: On 1/21/16, 11:59 AM, "Gustavo Lozano" <gustavo.lozano@icann.org<mailto:gustavo.lozano@icann.org>> wrote:

Hello colleagues,

I uploaded an I-D (http://www.ietf.org/id/draft-lozano-ietf-eppext-registrar-expiration-date- 00.txt) in order to define an EPP extension to support the transmission of the registrar registration expiration date from the registrar to the registry.

This extension is defined in order to support the ICANN Thick Whois Policy Recommendation (http://gnso.icann.org/en/issues/whois/thick-final-21oct13-en.pdf) that requires gTLD domain name registries to display the registrar registration expiration date in the Registration Data Directory Service (e.g. Whois, RDAP).

Your feedback is appreciated.

Regards, Gustavo

-- Benoit Levac VP Engineering, Registry Platform Office | 425-298-2337 Mobile | 613-617-4416 benoit.levac@rightside.co<mailto:benoit.levac@rightside.co> www.rightside.co<http://www.rightside.co>

Here’s a problem that raises the issue of whether date data from the registrar should be preserved (at least for a time) in a thin-to-thick registry migration. Some registrars have dates that are out of synch with the Verisign registry. The registry dates should be authoritative. But when data’s out of synch it creates questions and problems for registrants. (Like, “My registrar told me my domain doesn’t expire for another week – what do you mean it expired three days ago?”) Here’s a real-life example, where NONE of the dates match: VERISIGN WHOIS SEZ: Domain Name: DIRECTNIC.COM Updated Date: 03-sep-2014 Creation Date: 09-feb-2000 Expiration Date: 09-feb-2017 The REGISTRAR WHOIS SEZ: Domain Name: DIRECTNIC.COM Updated Date: 2015-05-26T07:01:01-05:00 Creation Date: 2000-05-25T05:45:12-05:00 Registrar Registration Expiration Date: 2016-05-25T05:45:12-05:00 All best, --Greg From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Francisco Obispo Sent: Thursday, January 21, 2016 6:20 PM To: Francisco Arias Cc: gtld-tech@icann.org Subject: Re: [gtld-tech] Registrar Expiration Date I-D I thought that in the thick model, the Registry was the only authoritative source for the expiration date of the domain name. The documents linked there don’t provide an explanation on why the ‘registrar expiration date’, is needed at the registry level, they seem to focus on when but not on the why. Can we just simply say that the Registrar Expiration Date Is not applicable at the registry level? I’m just envisioning here having to implement yet-another-extension, and then try to get all RARs to update the information before a deadline, etc. Can someone please clarify what it is that we’re trying to achieve here? Thanks! On 21 Jan 2016, at 14:54, Francisco Arias wrote: Hi Ben and Michele, The requirement has been discussed in the context of the Thick Whois Policy implementation. Please see https://whois.icann.org/sites/default/files/files/thick-rdds-consensus-polic..., particularly section 2.1, starting on page 8. By the way, this document is in public comment at https://www.icann.org/public-comments/rdds-output-2015-12-03-en until 31 January. Regards, -- Francisco On 1/21/16, 2:30 PM, "gtld-tech-bounces@icann.orggtld-tech-bounces@icann.org on behalf of Benoit Levac" <gtld-tech-bounces@icann.org <mailto:gtld-tech-bounces@icann.org%3cmailto:gtld-tech-bounces@icann.org> <mailto:gtld-tech-bounces@icann.org> on behalf of benoit.levac@rightside.cobenoit.levac@rightside.co> wrote: Francisco, I don't see any explanation for making registries store and publish the "Registrar Registration Expiration Date" in the "ICANN Thick Whois Policy Recommendation". What is the use case we are trying to solve for? Ben On Thu, Jan 21, 2016 at 1:55 PM, Francisco Arias <francisco.arias@icann.org <mailto:francisco.arias@icann.org%3cmailto:francisco.arias@icann.org> <mailto:francisco.arias@icann.org>> wrote: On 1/21/16, 11:59 AM, "Gustavo Lozano" <gustavo.lozano@icann.org <mailto:gustavo.lozano@icann.org%3cmailto:gustavo.lozano@icann.org> <mailto:gustavo.lozano@icann.org>> wrote: Hello colleagues, I uploaded an I-D (http://www.ietf.org/id/draft-lozano-ietf-eppext-registrar-expiration-date- 00.txt) in order to define an EPP extension to support the transmission of the registrar registration expiration date from the registrar to the registry. This extension is defined in order to support the ICANN Thick Whois Policy Recommendation (http://gnso.icann.org/en/issues/whois/thick-final-21oct13-en.pdf) that requires gTLD domain name registries to display the registrar registration expiration date in the Registration Data Directory Service (e.g. Whois, RDAP). Your feedback is appreciated. Regards, Gustavo -- Benoit Levac VP Engineering, Registry Platform Office | 425-298-2337 Mobile | 613-617-4416 benoit.levac@rightside.cobenoit.levac@rightside.co www.rightside.cohttp://www.rightside.co * PGP Signed by an unknown key Francisco Obispo CTO - Registry Operations ____________________________ <http://www.uniregistry.com/> Uniregistry 2161 San Joaquin Hills Road Newport Beach, CA 92660 Office +1 949 706 2300 x4202 fobispo@uniregistry.link * Unknown Key * 0xB38DB1BE

On Jan 22, 2016, at 12:22 AM, Andrew Sullivan <asullivan@dyn.com> wrote:

On Thu, Jan 21, 2016 at 09:12:47PM -0500, Greg Aaron wrote:

...

Here’s a problem that raises the issue of whether date data from the registrar should be preserved (at least for a time) in a thin-to-thick registry migration.

I was directly involved in a pretty large thin-to-thick migration some years ago (org), and as far as I could tell the registry still had the dates in question. What is the circumstance under which the registrar has different expiry dates than the registry? (I am not totally _au courant_ with the systems, but I am having a hard time figuring out how the registry and registrar are out of sync when that isn't just fraud.)

I'm prepared to admit that registrars' data could be out of sync. But surely this ought to be a bulk operation?

My guess is it might come from a business practice. Scenario 1: Registrar pays registry 1 year, user deletes domain in less than 1 year. Instead of deleting the domain at the registry as soon as user requests it, registrar takes ownership of domain and try selling either at standard reg fee or at an auction. Registrar needs then to keep track of when its business relation with the registry expires and when its business relation with the registrant expires, and those are in effect different dates. Scenario 2: Registrant registers for more than 1 year. Registrar pays registry for 1 year, and keep paying it for as long as the registrant originally paid for, but only at 1-year intervals. Considering most gTLDs auto-renew domains, it's not hard to implement. Rubens

I personally don't yet have an opinion on whether we should implement this extension, but I did want to point out a very common case where the registry expiration date differs from the registrar expiration date. And that is during the autoRenew period. If the customer hasn't yet paid the registrar for a renewal, the registrar expiration date will be in the past, while the registry expiration date is a year in the future. I know for a fact that this can be confusing for registrants and happens in both thick and thin registries who autorenew domains at expiration. But, as I said before, I haven't looked extensively into this extension and the reasons for it yet, and there may be a easier or better way to remove the possible confusion. -Pat Moroney Name.com On Thu, Jan 21, 2016, 21:26 Patrik Fältström <paf@frobbit.se> wrote:

On 22 Jan 2016, at 3:22, Andrew Sullivan wrote:

...

I'm prepared to admit that registrars' data could be out of sync. But surely this ought to be a bulk operation?

If things are out of sync, having both dates (that are out of sync) in the registry does not help.

The registry expiration date, which is already in the registry, is definitely enough.

What is in the business agreements between the registrar and registrant has nothing to do with the lifecycle of a domain name. And sure, some registrars do have, on request from their customers, coordinated payment cycles across all domains in the portfolio of the registrant. That the registrars today also expose those values in whois might be a bug, a feature or whatever. But we can not have as a goal that the registry should include information about those dates etc.

Can we please instead try to make the lifecycle of a domain name _simpler_ so people do understand it? Already today it is extremely complicated. Specifically in the end game, and yes, as pointed out, that is used by some registries and registrars in a way that is viewed by some as not 100% "ok".

Patrik

-- -Pat Moroney Sr. Software Engineer Name.com http://www.youtube.com/watch?v=V1GKGXXF12c 720-663-0025

It doesn’t have to be this way. A RAR can model the registry policy and auto-renew the name in its database, or keep the dates in sync via EPP <info> commands. There’s nothing that says that the expiration date has to remain in the past until the customer pays for it, the RAR has other means to inform its customer that the service has expired. regards, On 21 Jan 2016, at 21:29, Pat Moroney wrote:

I personally don't yet have an opinion on whether we should implement this extension, but I did want to point out a very common case where the registry expiration date differs from the registrar expiration date. And that is during the autoRenew period. If the customer hasn't yet paid the registrar for a renewal, the registrar expiration date will be in the past, while the registry expiration date is a year in the future. I know for a fact that this can be confusing for registrants and happens in both thick and thin registries who autorenew domains at expiration. But, as I said before, I haven't looked extensively into this extension and the reasons for it yet, and there may be a easier or better way to remove the possible confusion.

-Pat Moroney Name.com

On Thu, Jan 21, 2016, 21:26 Patrik Fältström <paf@frobbit.se> wrote:

...

On 22 Jan 2016, at 3:22, Andrew Sullivan wrote:

...

I'm prepared to admit that registrars' data could be out of sync. But surely this ought to be a bulk operation?

If things are out of sync, having both dates (that are out of sync) in the registry does not help.

The registry expiration date, which is already in the registry, is definitely enough.

What is in the business agreements between the registrar and registrant has nothing to do with the lifecycle of a domain name. And sure, some registrars do have, on request from their customers, coordinated payment cycles across all domains in the portfolio of the registrant. That the registrars today also expose those values in whois might be a bug, a feature or whatever. But we can not have as a goal that the registry should include information about those dates etc.

Can we please instead try to make the lifecycle of a domain name _simpler_ so people do understand it? Already today it is extremely complicated. Specifically in the end game, and yes, as pointed out, that is used by some registries and registrars in a way that is viewed by some as not 100% "ok".

Patrik

-- -Pat Moroney Sr. Software Engineer Name.com http://www.youtube.com/watch?v=V1GKGXXF12c 720-663-0025

Pat, I would agree with you, but the amount of effort needed to keep the data in sync would be tremendous and most likely to be never achieved, and so would be the effort to get all registrars/registries to implement this extension. A simpler solution could be just to: * have a note at the end of the whois result (registry) indicating that the expiry date field corresponds to the domain lifecycle, and that it should check with the registrar with regards to the contracted service (if applicable). * Or a note on the registrar whois explaining that the expiry date denotes the expiration date of the service. * Or both :-). best regards, — Francisco Obispo Uniregistry Inc. On 21 Jan 2016, at 22:22, Pat Moroney wrote:

I see what you are saying, but I think it would be even more confusing to have a Registrar Registration Expiration Date on the whois result that doesn't match when the service expires.

-Pat Moroney Name.com

On 22 Jan 2016, at 2:35, Thomas Corte wrote:

While, from a purist's standpoint, it seems entirely out of scope for registries, it does account for the fact that the end of the registrant's paid service period with the *registrar* is pretty much the *only* date the registrant needs to know.

I see things a bit differently. The issue at hand is that in essence, we have two completely separate databases tracking the same object (the domain name) using (hopefully) the same rules to ascertain its life-cycle and expose it to the public, including the registrant. IMO, the two databases operate in rough agreement most of the time regarding the expiry date. Disagreement usually happens around the auto-renew date because the two databases might very well update their status at different times creating a window of inconsistency. Nowadays, registrants go to either the registrar or the registry to consult the expiration date — I would think that most go to the registrar, where they’re seeing the “Registrar Expiration Date” and probably leave happy knowing their domain is safe and sound for the year they just were charged for. The proposal calls for the registrar to send their version of the expiration date so that the registry displays it. Of course, the update itself will have some time delay in being processed — besides of being an additional transformative operation, that will be coming at a time separate from the moment the registry finishes processing the automatic renewal. Basically we’re left in a worst place than we started. By exposing both dates at the same place, all of a sudden the registrant is made aware of a non-issue that she can do nothing about. This will result in more tickets opened at both, registrars and registries, claiming that the dates are different as well as unnecessary stress on the registrants. The resolution of those tickets will likely be some variation of “just wait a little and the dates will again magically match. Thank you”, causing the impression that there is some sort of confusion in the way the domain name is being managed by the registrar / registry. The inconsistency is a problem we have *today*, and by all means it self-corrects. It’s a classical distributed systems problem with no easy / perfect solution, by the way, simply because of the model we have in place. Why do we want to expose and amplify the impact of this non-issue by including third parties that cannot do anything to help resolve the situation? Again IMO, this does not improve things. We’re making an already complex system, more complex while at the same time we all lose. Luis Muñoz Director, Registry Operations ____________________________ http://www.uniregistry.link/ 2161 San Joaquin Hills Road Newport Beach, CA 92660 Office +1 949 706 2300 x 4242 lem@uniregistry.link

On 22 Jan 2016, at 10:03, Thomas Corte wrote:

Hello Luis,

Hello Thomas,

On 22/01/2016 18:18, Luis E. Muñoz wrote:

...

On 22 Jan 2016, at 2:35, Thomas Corte wrote:

While, from a purist's standpoint, it seems entirely out of scope for registries, it does account for the fact that the end of the registrant's paid service period with the /registrar/ is pretty much the /only/ date the registrant needs to know.

I see things a bit differently.

The issue at hand is that in essence, we have two completely separate databases tracking the same object (the domain name) using (hopefully) the same rules to ascertain its life-cycle and expose it to the public, including the registrant.

IMO, the two databases operate in rough agreement most of the time regarding the expiry date. Disagreement usually happens around the auto-renew date because the two databases might very well update their status at different times creating a window of inconsistency.

It's not just a matter of how auto-renewals are processed; the agreement highly depends on the registrar's billing policy.

Agree. I used the auto-renew as an example, but this does not invalidate the rest of the argument.

However, for transferred-in domains it could be vastly different. Let's say a domain is created by a different registrar on January 1st, 2016 with a 1-year period (expiring on 2017-01-01). It is then transferred to us on July 1st, 2016, meaning that our registrar (2-year) payment cycle starts on 2016-07-01 and ends on 2018-07-01. The domain is renewed by one year at the registry as part of the transfer, setting its registry expiration date to 2018-01-01. However, our *registrar* expiration date is 2018-07-01, six months later.

Perhaps I’m missing some important information, but shouldn’t you consider the creation / expiration dates at time of transfer and use that in your billing cycle computation? I would think that this scheme would always result in being out of phase with the domain’s life cycle.

Currently, what our registrar system does instead is extend the domain by another year (bumping the registry expiration date to 2019-01-01), so that the registrant won't worry about losing it on 2018-01-01. This premature renewal could be avoided with the proposed extension.

The premature renewal would also be avoided by adjusting your policy to account for this use case, without all the rest having to write code and deploy resources to address the changes. Best regards Luis Muñoz Director, Registry Operations ____________________________ http://www.uniregistry.link/ 2161 San Joaquin Hills Road Newport Beach, CA 92660 Office +1 949 706 2300 x 4242 lem@uniregistry.link

On 22 Jan 2016, at 11:05, luvingnc@aol.com wrote:

Maybe this is a dumb question, but why not require registrars to display the registry expiration date? They already have it, it requires no EPP extensions, and it's the registrar that's confusing (if things are confused) by exposing a different date than is held by the registry.

Hello Ann, The registrar has the registry’s expiration date from the last time it got the domain info. This does not always match, as previously described in the thread. I would argue that the worse problem is that we’re trying to show the registrant two different dates — the use cases that lead to this are present and sort out by themselves, with the processes we all have in place now. By showing the two dates side by side, we’re simply highlighting a non-issue and converting it to a concern on the registrant’s mind. Luis Muñoz Director, Registry Operations ____________________________ http://www.uniregistry.link/ 2161 San Joaquin Hills Road Newport Beach, CA 92660 Office +1 949 706 2300 x 4242 lem@uniregistry.link

On Fri, Jan 22, 2016 at 09:18:11AM -0800, Luis E. Muñoz wrote:

The issue at hand is that in essence, we have two completely separate databases tracking the same object (the domain name) using (hopefully) the same rules to ascertain its life-cycle and expose it to the public, including the registrant.

I have to agree that this is in fact the problem. One of the rules you learn early as a DBA is that storing the same data in two different databases is a good way to store the wrong data sometimes. Perhaps another way to look at this, however, is that there may be different understandings of what this object is and what the role of registrars is. One view (the one I confess I've always had) is that registrars are basically retailers of a thing distributed by registries. In this view, registrars are really just an intermediary between a thing in the registry and the registrant. But another view is that the registrars are actually packagers of things sold be registries to the registrars. The registrar is, in this view, more of a VAR. In that case, what the registrant gets is _not_ actually what the registry sells, but a package that happens to be made up of stuff, one component of which is the thing sold by the registry. I suspect the problem here is that we're not clear on which model is in force, and as a result even when a registrar is working in the "VAR" mode, the life cycle of the domain name which is implicit in the "retailer" mode ends up exposed to the registrant. That seems like a problem, and I am sceptical that it will be helped by giving the registrant another expiry date to worry about. For I think that requires the registrant to develop a theory of operation of the entire registration market, and I think that psychic burden is going to be too high for most registrants to be bothered. Best regards, A -- Andrew Sullivan Dyn, Inc. email: asullivan@dyn.com

Pat That could be addressed in a much more graceful fashion A LOT of ccTLDs give a “grace” period and the whois data isn’t impacted, but for some reason gTLDs don’t and we (registrars) end up using the auto renew to provide it.. Adding more data to whois output is going to cause more confusion and I can’t see any point in doing that. Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blog.blacknight.com/ http://ceo.hosting/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From: <gtld-tech-bounces@icann.org<mailto:gtld-tech-bounces@icann.org>> on behalf of Pat Moroney <pmoroney@name.com<mailto:pmoroney@name.com>> Date: Friday 22 January 2016 at 05:29 To: Patrik Fältström <paf@frobbit.se<mailto:paf@frobbit.se>>, Andrew Sullivan <asullivan@dyn.com<mailto:asullivan@dyn.com>> Cc: "gtld-tech@icann.org<mailto:gtld-tech@icann.org>" <gtld-tech@icann.org<mailto:gtld-tech@icann.org>> Subject: Re: [gtld-tech] Registrar Expiration Date I-D I personally don't yet have an opinion on whether we should implement this extension, but I did want to point out a very common case where the registry expiration date differs from the registrar expiration date. And that is during the autoRenew period. If the customer hasn't yet paid the registrar for a renewal, the registrar expiration date will be in the past, while the registry expiration date is a year in the future. I know for a fact that this can be confusing for registrants and happens in both thick and thin registries who autorenew domains at expiration. But, as I said before, I haven't looked extensively into this extension and the reasons for it yet, and there may be a easier or better way to remove the possible confusion. -Pat Moroney Name.com On Thu, Jan 21, 2016, 21:26 Patrik Fältström <paf@frobbit.se<mailto:paf@frobbit.se>> wrote: On 22 Jan 2016, at 3:22, Andrew Sullivan wrote:

I'm prepared to admit that registrars' data could be out of sync. But surely this ought to be a bulk operation?

If things are out of sync, having both dates (that are out of sync) in the registry does not help. The registry expiration date, which is already in the registry, is definitely enough. What is in the business agreements between the registrar and registrant has nothing to do with the lifecycle of a domain name. And sure, some registrars do have, on request from their customers, coordinated payment cycles across all domains in the portfolio of the registrant. That the registrars today also expose those values in whois might be a bug, a feature or whatever. But we can not have as a goal that the registry should include information about those dates etc. Can we please instead try to make the lifecycle of a domain name _simpler_ so people do understand it? Already today it is extremely complicated. Specifically in the end game, and yes, as pointed out, that is used by some registries and registrars in a way that is viewed by some as not 100% "ok". Patrik -- -Pat Moroney Sr. Software Engineer Name.com http://www.youtube.com/watch?v=V1GKGXXF12c 720-663-0025

Andrew A big warning notice in the whois output telling them to pay their registrars might work better :) M -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blog.blacknight.com/ http://ceo.hosting/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 On 22/01/2016, 14:26, "gtld-tech-bounces@icann.org on behalf of Andrew Sullivan" <gtld-tech-bounces@icann.org on behalf of asullivan@dyn.com> wrote:

On Fri, Jan 22, 2016 at 05:24:35AM +0100, Patrik Fältström wrote:

...

The registry expiration date, which is already in the registry, is definitely enough.

The problem that people claim to want to solve, however, is that registrants are sometimes surprised at expiration because their registrar says something's expired when the whois doesn't say that. The registrar then sells the registry-registered name off to some other registrant.

The idea is that by putting this data in the public whois, registrants wont get surprised this way. I have pretty grave doubts that this idea is correct, but I can see the logic.

...

Can we please instead try to make the lifecycle of a domain name _simpler_ so people do understand it? Already today it is extremely complicated. Specifically in the end game, and yes, as pointed out, that is used by some registries and registrars in a way that is viewed by some as not 100% "ok".

Yes.

A

-- Andrew Sullivan Dyn asullivan@dyn.com

I agree that registry data should prevail. If the registrar has been out of synch with the registry regarding expiration dates, domain statues, etc., it's the registrar's fault. Unfortunately those errors devolve upon registrants and cause problems for them. We do not know how often or badly registrars are out of synch. But I would expect some resulting registrant confusion when .COM and .NET go thick. -----Original Message----- From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Patrik Fältström Sent: Thursday, January 21, 2016 11:25 PM To: Andrew Sullivan Cc: gtld-tech@icann.org Subject: Re: [gtld-tech] Registrar Expiration Date I-D * PGP Signed by an unknown key On 22 Jan 2016, at 3:22, Andrew Sullivan wrote:

I'm prepared to admit that registrars' data could be out of sync. But surely this ought to be a bulk operation?

If things are out of sync, having both dates (that are out of sync) in the registry does not help. The registry expiration date, which is already in the registry, is definitely enough. What is in the business agreements between the registrar and registrant has nothing to do with the lifecycle of a domain name. And sure, some registrars do have, on request from their customers, coordinated payment cycles across all domains in the portfolio of the registrant. That the registrars today also expose those values in whois might be a bug, a feature or whatever. But we can not have as a goal that the registry should include information about those dates etc. Can we please instead try to make the lifecycle of a domain name _simpler_ so people do understand it? Already today it is extremely complicated. Specifically in the end game, and yes, as pointed out, that is used by some registries and registrars in a way that is viewed by some as not 100% "ok". Patrik * Unknown Key * 0x0B88D7CD

VERISIGN WHOIS SEZ: Expiration Date: 09-feb-2017 The REGISTRAR WHOIS SEZ: Registrar Registration Expiration Date: 2016-05-25T05:45:12-05:00

Essentially, as long as the registrardate <= registrydata, then all-is-good(tm) it's when they're the other way around that 'issues' can arise. Is the real question not simply "why does anyone need to know" ? Registrant s/be relying on their Registrar Everyone else doesn't matter as it's none of their business Rob

Hi Everyone, Just a few facts to recap: 1. I can't recall a single gTLD that is contracted by ICANN that does not auto renew a registered domain. Every registered domain is renewed by the registry either on the expiration date of the domain or 45 days after the expiration date. The domain is never deleted at the registry unless requested by the registrar or a policy supported mechanism. 2. There are millions of domains where the registrar expiration date does not match the registry expiration date due to the auto renewal that is performed by the registry and the fact that the registrant has not renewed with the registrar. 3. The registrant has an agreement with the registrar to provide service for the registration of the domain, but does not have an agreement with the registry. If the domain is not registered or deleted by the registrar, the registrant is going to contact the registrar regarding the issue. The registry expiration date provides a false sense of security to the registrant. It does not display the actual date of service that the registrant has actual purchased and the registrar has agreed to provide. Adding the registrar expiration date to the registry whois will lead to more confusion to the registrant when the dates don't match. An option could be to add a link to the whois output to an ICANN page listed with the registry expiration date and the registrar expiration date to explain what the date means to the registrant. The link could be very similar to the links provided in the whois to explain the various domain statuses. Here is an example of the links listed for the domain statuses: Domain Status: clientDeleteProhibited https://www.icann.org/epp#clientDeleteProhibited Domain Status: clientTransferProhibited https://www.icann.org/epp#clientTransferProhibited Domain Status: clientUpdateProhibited https://www.icann.org/epp#clientUpdateProhibited The registry whois could be updated to: Registry Expiry Date: 2017-01-13T04:00:00Z https://ww.icann.org/epp#registryexpirationdate The registrar whois could be updated to: Registrar Registration Expiration Date: 2016-01-13T04:00:00Z https://ww.icann.org/epp#registarregistrationexpirationdate Another option would be to remove the requirement of the registry to display the expiration date entirely and require the customer to go to the registrar to verify the expiration date of the domain. Thoughts? Thanks, Jody Kolker -----Original Message----- From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Maxim Alzoba Sent: Tuesday, January 26, 2016 10:06 AM To: Rob Golding Cc: gtld-tech@icann.org Subject: Re: [gtld-tech] Registrar Expiration Date I-D Hello Rob, Registries process domain data according to their particular domain lifecycle, and it is done basing on the registry dates. Sincerely Yours, Maxim Alzoba Special projects manager, International Relations Department, FAITID m. +7 916 6761580 skype oldfrogger Current UTC offset: +3.00 (Moscow) On Jan 26, 2016, at 15:21 , "Rob Golding" <rob.golding@astutium.com> wrote:

...

VERISIGN WHOIS SEZ: Expiration Date: 09-feb-2017 The REGISTRAR WHOIS SEZ: Registrar Registration Expiration Date: 2016-05-25T05:45:12-05:00

Essentially, as long as the registrardate <= registrydata, then all-is-good(tm) it's when they're the other way around that 'issues' can arise.

Is the real question not simply "why does anyone need to know" ?

Registrant s/be relying on their Registrar Everyone else doesn't matter as it's none of their business

Rob

Once .COM and .NET (and .jobs) go thick, do registrars want to or need to operate WHOIS servers at all? One of the ostensible benefits of thick registries is that there's only a need for one WHOIS server -- the authoritative registry one. Right now, at least on their web-based WHOIS, many registrars just regurgitate registry WHOIS for any gTLD domain except for .COM and .NET. So I see three options: 1. Registrar-based WHOIS will always be required, because of expiration date variances we've been discussing here, caused by auto-renewals and registrar payment policies. 2. Registrar-based WHOIS goes away. Registry WHOIS contains an Registry Expiration Date AND a Registrar Expiration Date field. The registrar populates and manages the latter. 3. Registrar-based WHOIS goes away. The WHOIS only shows the registry expiration date, and registrars and registrants have to communicate with each other about expirations and payments etc. All best, --Greg -----Original Message----- From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Jody Kolker Sent: Tuesday, January 26, 2016 2:19 PM To: Maxim Alzoba; Rob Golding Cc: gtld-tech@icann.org Subject: Re: [gtld-tech] Registrar Expiration Date I-D Hi Everyone, Just a few facts to recap: 1. I can't recall a single gTLD that is contracted by ICANN that does not auto renew a registered domain. Every registered domain is renewed by the registry either on the expiration date of the domain or 45 days after the expiration date. The domain is never deleted at the registry unless requested by the registrar or a policy supported mechanism. 2. There are millions of domains where the registrar expiration date does not match the registry expiration date due to the auto renewal that is performed by the registry and the fact that the registrant has not renewed with the registrar. 3. The registrant has an agreement with the registrar to provide service for the registration of the domain, but does not have an agreement with the registry. If the domain is not registered or deleted by the registrar, the registrant is going to contact the registrar regarding the issue. The registry expiration date provides a false sense of security to the registrant. It does not display the actual date of service that the registrant has actual purchased and the registrar has agreed to provide. Adding the registrar expiration date to the registry whois will lead to more confusion to the registrant when the dates don't match. An option could be to add a link to the whois output to an ICANN page listed with the registry expiration date and the registrar expiration date to explain what the date means to the registrant. The link could be very similar to the links provided in the whois to explain the various domain statuses. Here is an example of the links listed for the domain statuses: Domain Status: clientDeleteProhibited https://www.icann.org/epp#clientDeleteProhibited Domain Status: clientTransferProhibited https://www.icann.org/epp#clientTransferProhibited Domain Status: clientUpdateProhibited https://www.icann.org/epp#clientUpdateProhibited The registry whois could be updated to: Registry Expiry Date: 2017-01-13T04:00:00Z https://ww.icann.org/epp#registryexpirationdate The registrar whois could be updated to: Registrar Registration Expiration Date: 2016-01-13T04:00:00Z https://ww.icann.org/epp#registarregistrationexpirationdate Another option would be to remove the requirement of the registry to display the expiration date entirely and require the customer to go to the registrar to verify the expiration date of the domain. Thoughts? Thanks, Jody Kolker -----Original Message----- From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Maxim Alzoba Sent: Tuesday, January 26, 2016 10:06 AM To: Rob Golding Cc: gtld-tech@icann.org Subject: Re: [gtld-tech] Registrar Expiration Date I-D Hello Rob, Registries process domain data according to their particular domain lifecycle, and it is done basing on the registry dates. Sincerely Yours, Maxim Alzoba Special projects manager, International Relations Department, FAITID m. +7 916 6761580 skype oldfrogger Current UTC offset: +3.00 (Moscow) On Jan 26, 2016, at 15:21 , "Rob Golding" <rob.golding@astutium.com> wrote:

...

VERISIGN WHOIS SEZ: Expiration Date: 09-feb-2017 The REGISTRAR WHOIS SEZ: Registrar Registration Expiration Date: 2016-05-25T05:45:12-05:00

Essentially, as long as the registrardate <= registrydata, then all-is-good(tm) it's when they're the other way around that 'issues' can arise.

Is the real question not simply "why does anyone need to know" ?

Registrant s/be relying on their Registrar Everyone else doesn't matter as it's none of their business

Rob

Greg Registrars probably don’t want to run whois servers … the only reason we have them now is because of thin registries Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blog.blacknight.com/ http://ceo.hosting/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 On 27/01/2016, 16:22, "gtld-tech-bounces@icann.org on behalf of Greg Aaron" <gtld-tech-bounces@icann.org on behalf of greg@illumintel.com> wrote:

Once .COM and .NET (and .jobs) go thick, do registrars want to or need to operate WHOIS servers at all? One of the ostensible benefits of thick registries is that there's only a need for one WHOIS server -- the authoritative registry one. Right now, at least on their web-based WHOIS, many registrars just regurgitate registry WHOIS for any gTLD domain except for .COM and .NET.

So I see three options: 1. Registrar-based WHOIS will always be required, because of expiration date variances we've been discussing here, caused by auto-renewals and registrar payment policies. 2. Registrar-based WHOIS goes away. Registry WHOIS contains an Registry Expiration Date AND a Registrar Expiration Date field. The registrar populates and manages the latter. 3. Registrar-based WHOIS goes away. The WHOIS only shows the registry expiration date, and registrars and registrants have to communicate with each other about expirations and payments etc.

All best, --Greg

-----Original Message----- From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Jody Kolker Sent: Tuesday, January 26, 2016 2:19 PM To: Maxim Alzoba; Rob Golding Cc: gtld-tech@icann.org Subject: Re: [gtld-tech] Registrar Expiration Date I-D

Hi Everyone,

Just a few facts to recap:

1. I can't recall a single gTLD that is contracted by ICANN that does not auto renew a registered domain. Every registered domain is renewed by the registry either on the expiration date of the domain or 45 days after the expiration date. The domain is never deleted at the registry unless requested by the registrar or a policy supported mechanism.

2. There are millions of domains where the registrar expiration date does not match the registry expiration date due to the auto renewal that is performed by the registry and the fact that the registrant has not renewed with the registrar.

3. The registrant has an agreement with the registrar to provide service for the registration of the domain, but does not have an agreement with the registry. If the domain is not registered or deleted by the registrar, the registrant is going to contact the registrar regarding the issue.

The registry expiration date provides a false sense of security to the registrant. It does not display the actual date of service that the registrant has actual purchased and the registrar has agreed to provide.

Adding the registrar expiration date to the registry whois will lead to more confusion to the registrant when the dates don't match.

An option could be to add a link to the whois output to an ICANN page listed with the registry expiration date and the registrar expiration date to explain what the date means to the registrant. The link could be very similar to the links provided in the whois to explain the various domain statuses. Here is an example of the links listed for the domain statuses:

Domain Status: clientDeleteProhibited https://www.icann.org/epp#clientDeleteProhibited Domain Status: clientTransferProhibited https://www.icann.org/epp#clientTransferProhibited Domain Status: clientUpdateProhibited https://www.icann.org/epp#clientUpdateProhibited

The registry whois could be updated to:

Registry Expiry Date: 2017-01-13T04:00:00Z https://ww.icann.org/epp#registryexpirationdate

The registrar whois could be updated to:

Registrar Registration Expiration Date: 2016-01-13T04:00:00Z https://ww.icann.org/epp#registarregistrationexpirationdate

Another option would be to remove the requirement of the registry to display the expiration date entirely and require the customer to go to the registrar to verify the expiration date of the domain.

Thoughts?

Thanks, Jody Kolker

-----Original Message----- From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Maxim Alzoba Sent: Tuesday, January 26, 2016 10:06 AM To: Rob Golding Cc: gtld-tech@icann.org Subject: Re: [gtld-tech] Registrar Expiration Date I-D

Hello Rob,

Registries process domain data according to their particular domain lifecycle, and it is done basing on the registry dates.

Sincerely Yours,

Maxim Alzoba Special projects manager, International Relations Department, FAITID

m. +7 916 6761580 skype oldfrogger

Current UTC offset: +3.00 (Moscow)

On Jan 26, 2016, at 15:21 , "Rob Golding" <rob.golding@astutium.com> wrote:

...

...

VERISIGN WHOIS SEZ: Expiration Date: 09-feb-2017 The REGISTRAR WHOIS SEZ: Registrar Registration Expiration Date: 2016-05-25T05:45:12-05:00

Essentially, as long as the registrardate <= registrydata, then all-is-good(tm) it's when they're the other way around that 'issues' can arise.

Is the real question not simply "why does anyone need to know" ?

Registrant s/be relying on their Registrar Everyone else doesn't matter as it's none of their business

Rob

Hello, On 27/01/2016 17:31, Antoin Verschuren wrote:

I see a 4th one, like Thomas Corte suggested:

4. Registrar-based WHOIS goes away. The WHOIS does not show any expiration date, and registrars and registrants have to communicate with each other about expirations and payments etc.

Alternatively, the "Registry Expiry Date" Whois field could be renamed to "Registry Renewal Date", which (for auto-renewing registries) reflects the real meaning much better and sounds less worrying to clueless registrants. /Thomas -- TANGO REGISTRY SERVICES® Knipp Medien und Kommunikation GmbH Thomas Corte Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: Thomas.Corte@knipp.de Germany

Hello, On 27/01/2016 18:48, Andrew Sullivan wrote:

...

Alternatively, the "Registry Expiry Date" Whois field could be renamed to "Registry Renewal Date", which (for auto-renewing registries) reflects the real meaning much better and sounds less worrying to clueless registrants.

I can see some advantage there, but the basic problem is that it requires the registrant to have some sort of model of how the registration business works; to the extent the registrant is wrong, it gets a bad picture of how things are going to work.

The main problem is that, unlike most other industries, the domain business publicly exposes (via the registry's Whois) data of its "wholesale" vendors to end customers. Not understanding that data has the potential to worry them. If I could see that e.g. my electricity company's contract with its supplier is about to end (without knowing for sure it's going to be renewed), I might get worried, too. /Thomas -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeißer-Weg 9 44227 Dortmund Deutschland Dipl.-Informatiker Tel: +49 231 9703-0 Thomas Corte Fax: +49 231 9703-200 Stellvertretender Leiter SIP: Thomas.Corte@knipp.de Software-Entwicklung E-Mail: Thomas.Corte@knipp.de Registereintrag: Amtsgericht Dortmund, HRB 13728 Geschäftsführer: Dietmar Knipp, Elmar Knipp

Greg It’s how several ccTLDs work and there aren’t any issues with them … Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blog.blacknight.com/ http://ceo.hosting/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 On 27/01/2016, 17:49, "gtld-tech-bounces@icann.org on behalf of Greg Aaron" <gtld-tech-bounces@icann.org on behalf of greg@illumintel.com> wrote:

Four problems with #4: A) The current registrar and the current registrant are not the only parties with an interest in a domain's expiration date. For example, other people may want that domain when it expires. Gaining registrars like to see the expiration date when processing inbound transfers. B) A domain's expiration date can be gotten via EPP <info> command. No reason to show expiration date in a <info> command but not in WHOIS. C) Some registrants use WHOIS to understand their domains. D) The registry has to store the expiration date no matter what. So no reason not to display it in WHOIS?

-----Original Message----- From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Antoin Verschuren Sent: Wednesday, January 27, 2016 11:31 AM To: gtld-tech@icann.org Subject: Re: [gtld-tech] Registrar Expiration Date I-D

* PGP Signed by an unknown key

Op 27 jan. 2016, om 17:22 heeft Greg Aaron <greg@illumintel.com> het volgende geschreven:

...

So I see three options: 1. Registrar-based WHOIS will always be required, because of expiration date variances we've been discussing here, caused by auto-renewals and registrar payment policies. 2. Registrar-based WHOIS goes away. Registry WHOIS contains an Registry Expiration Date AND a Registrar Expiration Date field. The registrar populates and manages the latter. 3. Registrar-based WHOIS goes away. The WHOIS only shows the registry expiration date, and registrars and registrants have to communicate with each other about expirations and payments etc.

I see a 4th one, like Thomas Corte suggested:

4. Registrar-based WHOIS goes away. The WHOIS does not show any expiration date, and registrars and registrants have to communicate with each other about expirations and payments etc.

No more discussions. I kind of like that ;-)

- -- Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392

* Unknown Key * 0x74FA2351

The point was that domain expiration date should not be information only given to registrars who have the privilege of EPP access directly into a registry. It’s data that’s been in WHOIS for twenty years, and access to it via WHOIS should not be withdrawn. Domain back-orders are usually placed before the expiration date, not in the 30 days after an auto-renewal, and not during pendingDelete. From: Luis E. Muñoz [mailto:lem@uniregistry.link] Sent: Wednesday, January 27, 2016 1:06 PM To: Greg Aaron Cc: Antoin Verschuren; gtld-tech@icann.org Subject: Re: [gtld-tech] Registrar Expiration Date I-D On 27 Jan 2016, at 9:49, Greg Aaron wrote: A) The current registrar and the current registrant are not the only parties with an interest in a domain's expiration date. For example, other people may want that domain when it expires. Gaining registrars like to see the expiration date when processing inbound transfers. B) A domain's expiration date can be gotten via EPP <info> command. No reason to show expiration date in a <info> command but not in WHOIS. Wouldn’t (B) negate the “Gaining registrars” part of (A) as an argument? Also, given the prevalence of auto-renewals, I would argue that WHOIS as it is today don’t work for prospective registrants interested in an unavailable name. They really have no further clue about when the domain will be available by looking at the expiration date alone. To that effect, showing the pendingDelete status in the WHOIS record is better for them, as it’s clear that the name won’t be auto-renewed and will become available at some point in the (near) future. Luis Muñoz Director, Registry Operations ____________________________ <http://www.uniregistry.link/> Uniregistry 2161 San Joaquin Hills Road Newport Beach, CA 92660 Office +1 949 706 2300 x 4242 lem@uniregistry.link

Hello, On 27/01/2016 18:49, Greg Aaron wrote:

Four problems with #4: A) The current registrar and the current registrant are not the only parties with an interest in a domain's expiration date. For example, other people may want that domain when it expires. Gaining registrars like to see the expiration date when processing inbound transfers.

Most registries allow (as they should) the inquiry of non-sponsored domains via EPP, so registrars should have better ways to obtain that information. As for other interested parties (such as domain grabbers), I'm not sure how justifiable their interest might be.

B) A domain's expiration date can be gotten via EPP <info> command. No reason to show expiration date in a <info> command but not in WHOIS.

There are other things not shown in Whois that can be obtained via EPP, such as a domain's authinfo, creator registrar, or contact disclosure settings. In my point of view it' only a problem if the Whois displays *more* information than is available via EPP.

C) Some registrants use WHOIS to understand their domains.

Unfortunately, most use WHOIS to misunderstand them.

D) The registry has to store the expiration date no matter what. So no reason not to display it in WHOIS?

The discussion is about whether this is potentially confusing information that should be suppressed. /Thomas -- TANGO REGISTRY SERVICES® Knipp Medien und Kommunikation GmbH Thomas Corte Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: Thomas.Corte@knipp.de Germany

Hi, On Wed, Jan 27, 2016 at 12:49:57PM -0500, Greg Aaron wrote:

B) A domain's expiration date can be gotten via EPP <info> command. No reason to show expiration date in a <info> command but not in WHOIS.

I disagree strongly with this claim. An EPP client is normally an authenticated client with a pre-existing arrangement with the operator of the repository. There is some reason to suppose in that case that the client is operated by someone who understands the nature of the repository with which it is interacting. Even in that apparently far-off future happy state where we've finally ditched whois, we'll still have an unauthenticated mode of RDS operation, and we'll therefore have queries from clients that may well not understand the distinction between the registry data and data about the registrant-registrar relationship. It is our failure to provide a clear distinction so far in the kinds of data we return from RDS that has made this problematic. If we can find a way to make that distinction clear, then I'm all in favour of ways for passing the info around. But until we make these things clear to users, more data just adds more confusion. Best regards, A -- Andrew Sullivan Dyn asullivan@dyn.com

Hello, On 27/01/2016 17:22, Greg Aaron wrote:

Once .COM and .NET (and .jobs) go thick, do registrars want to or need to operate WHOIS servers at all?

For think registries, the registrar Whois has always been a complete waste of resources, and I truly hope that ICANN will drop the requirement for it once all gTLDs have adopted the thick model.

So I see three options: 1. Registrar-based WHOIS will always be required, because of expiration date variances we've been discussing here, caused by auto-renewals and registrar payment policies. 2. Registrar-based WHOIS goes away. Registry WHOIS contains an Registry Expiration Date AND a Registrar Expiration Date field. The registrar populates and manages the latter. 3. Registrar-based WHOIS goes away. The WHOIS only shows the registry expiration date, and registrars and registrants have to communicate with each other about expirations and payments etc.

My personal preference would be 3, however (as said before) it seems that registrant confusion about a domain's fate can best be avoided by option 2. Best regards, Thomas -- TANGO REGISTRY SERVICES® Knipp Medien und Kommunikation GmbH Thomas Corte Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: Thomas.Corte@knipp.de Germany

Andy, << I certainly find it helpful to know when the registry and registrar have a difference of opinion on how to deliver the service I am paying them to deliver.

...

Registrants are not paying the registry and the registrar. Registrants are only paying the registrar. As the registrant, that is the expiration date that you as the registrant should be concerned with. If the registrar is not fulfilling its duties, the registrant will not be able to expect much help from the registry. The only relationship the registrant has is with the registrar, not the registry. I think that we as a community need to enforce the fact that the registrant is paying the registrar for service not the registry (who is paid by the registrar). The most important date to the registrant is the registrar expiration date since technically the domain will never expire at the registry due to the fact that all domains will auto renew at the registry. Once the domain expires at the registry, it will be renewed automatically for another year. Putting both of the expiration dates in the registry whois does explain why there is a difference between the dates. To me it does not address any confusion related to this issue. Thanks, Jody Kolker 319-294-3933 (office) 319-329-9805 (mobile) Please contact my direct supervisor Charles Beadnall (cbeadnall@godaddy.com) with any feedback. This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments. -----Original Message----- From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Andrew Newton Sent: Tuesday, January 26, 2016 2:19 PM To: Anderson, Marc Cc: gtld-tech@icann.org Subject: Re: [gtld-tech] Registrar Expiration Date I-D On Tue, Jan 26, 2016 at 2:28 PM, Anderson, Marc <mcanderson@verisign.com> wrote:

The proposed extension certainly does not meet the intent of the PDP working group. In fact adding an additional expiration field to the Registry Whois output would seem to me to make Registry response inconsistent with the 2013 RAA.

So the intent of the PDP working group was to have consistency of protocol labels but ignore consistency in the meaning of those protocol labels? As a member of the general public (I don't work for a domain registry or registrar), I certainly find it helpful to know when the registry and registrar have a difference of opinion on how to deliver the service I am paying them to deliver. Therefore I see nothing wrong with this proposal. -andy

On Tue, Jan 26, 2016 at 3:54 PM, Jody Kolker <jkolker@godaddy.com> wrote:

Putting both of the expiration dates in the registry whois does explain why there is a difference between the dates. To me it does not address any confusion related to this issue.

When dealing with Amazon and other big Internet retailers, they let me know when they have shipped my order and the details of how the shipping company is handling my shipment even though I never enter into a contractual relationship with the shipping company. Yes, this might confuse some people but in general it is known throughout the industry as good customer service. -andy

Hi Andy, The RAR (the entity that has the relationship with the customer), has both dates.. if the RAR added that date to its whois output, would provide a similar experience than what you’re describing here. But the RY doesn’t have that piece of data, and getting in in sync would be a tremendous amount of effort, not in dev, but operationally and then making sure it’s current. regards, — Francisco Obispo Uniregistry Inc. On 26 Jan 2016, at 13:10, Andrew Newton wrote:

On Tue, Jan 26, 2016 at 3:54 PM, Jody Kolker <jkolker@godaddy.com> wrote:

...

Putting both of the expiration dates in the registry whois does explain why there is a difference between the dates. To me it does not address any confusion related to this issue.

When dealing with Amazon and other big Internet retailers, they let me know when they have shipped my order and the details of how the shipping company is handling my shipment even though I never enter into a contractual relationship with the shipping company. Yes, this might confuse some people but in general it is known throughout the industry as good customer service.

-andy

On Tue, Jan 26, 2016 at 4:20 PM, Andrew Sullivan <asullivan@dyn.com> wrote:

On Tue, Jan 26, 2016 at 01:16:10PM -0800, Francisco Obispo wrote:

...

But the RY doesn’t have that piece of data, and getting in in sync would be a tremendous amount of effort, not in dev, but operationally and then making sure it’s current.

And stays current. It's "staying current" that worries me. The first thing they teach you in database school is not to have two sources of truth. For if you have one, there is a fact of the matter; but if you have two it's anyone's guess which is correct.

Well, this isn't a single database but two separate systems. Now which is the system of record I guess is an ICANN policy issue. But I see it no differently than my contact information or name servers. If I change either with the RAR, that info must also be updated in the RY. How is this date any different? In the current thick gTLDs, don't the RARs already have to keep their data up to date in the RY? -andy

On Tue, Jan 26, 2016 at 4:48 PM, Andrew Sullivan <asullivan@dyn.com> wrote:

So it's not different, and the history of this sort of thing suggests that adding more ways for the two data systems to drift apart is not a good idea.

Then can't the same be said of ANY new EPP extension? Yes, it is one more data element to synchronize but that seems like a very small freckle considering all the other warts of the registry-registrar system. In my opinion, the onerous nature of adding such a simple element should be more demonstrable. -andy

Hello Andrew, On 27/01/2016 00:26, Andrew Sullivan wrote:

Since the registry doesn't have access to the life cycle of the registrar-registrant agreement, this value doesn't belong in the registry database -- any more than, say, the expiry date of the registrant's credit card belongs in the registry. The reason for this is that it is dependent on the registrar's business logic, so it can't be in a shared repository like the registry.

I completely agree that, in a perfect world, the registrar expiration date would have no business being stored in the registry's database. Meanwhile, in real life, the problem seems to be that registrants get confused by looking at the registry Whois and seeing their domain expiring in, say, a couple of months, even though their current payment cycle with their registrar or reseller extends way beyond that point (I pointed out in an earlier e-mail that registrars may choose to e.g. bill domains in cycles that are completely detached from the registry's). Seeing this makes them worried about losing their domain, since most of them are also unaware of the fact that most registries auto-renew domains when they reach the expiration date. So from this point of view, it *may* be beneficial to have the registrar expiration date displayed alongside the registry expiration date. It may also add even more confusion though; it could be argued that it may even better to *not* display the registry expiration date in the registry Whois at all in such scenarios, since it has no meaning to the registrant, and the registrar can always get it via EPP. Best regards, Thomas -- TANGO REGISTRY SERVICES® Knipp Medien und Kommunikation GmbH Thomas Corte Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: Thomas.Corte@knipp.de Germany

Op 27 jan. 2016, om 12:54 heeft Jody Kolker <jkolker@godaddy.com> het volgende geschreven:

< Since the registry doesn't have access to the life cycle of the registrar-registrant agreement, this value doesn't belong in the registry database -- any more than, say, the expiry date of the registrant's credit card belongs in the registry. The reason for this is that it is dependent on the registrar's business logic, so it can't be in a shared repository like the registry.

...

+1

Having read the tread for a while, I must say I agree with this too. Bilateral agreements between registrant and registrar don’t belong in whois. Next thing will be that the registrar wants to publish it’s commercial package name, SLA, sales department phone no etc in the registrY whois. The whole problem is off course that some registrars want different business models than other registrars or registries, and want to save every penny without losing a domain name. That’s fine, but don’t put the burdon of that business model to every other registrar with a different business model. In the good old days, when a domain lost it’s owner because he didn’t want the domain anymore, a domain was deleted at the registry, and when someone new wanted to register it again, it just got into a new cycle with a new expiry date. Nowadays, registrars hold on to their domains so they can resell it again at as little cost as possible, trying to gain from a former registrant’s unused registration period. But there is one thing I don’t understand, or perhaps I miss in the registry-registrar agreement. The most simple way to prevent these out of sync dates is to reset the expiry date at the registry whenever a domain is transferred or changes owner. The only problem is a "sense” of either the registrar or registrant that they have not "used up” their entire registration period that they paid for. But I think that is the cost that is associated with changing registration data continuously. Billing and maintenance cost by the registry should also be taken into account. One way of handeling this as I’ve seen with some ccTLD’s is to give registrars a choice of how they want their domains to be invoiced. Invoicing can be different from the contract lifecycle. Let them choose between let’s say 10,- a year or 1,- per month invoicing cycles for their domains. If they then want to transfer a domain after f.e. 14 months after registration, they don’t feel that they have not "used up” their registration lifecycle they paid for. And every registrar can choose a billing cycle to fit their businessmodel. In the EU, legislation prescribes that for subscriptions such as domain names, a consumer must be able to cancel their subscription on a monthly basis after an initial first year contract f.e. Registries are not excluded from that legislation. This will also lead to better accuracy in the whois data, as the cycle will be restarted after every transfer or change of owner, so there is a clear incentive to have the data changed to the real user of the domain at that time. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392

On Tue, Jan 26, 2016 at 4:16 PM, Francisco Obispo <fobispo@uniregistry.link> wrote:

But the RY doesn’t have that piece of data, and getting in in sync would be a tremendous amount of effort, not in dev, but operationally and then making sure it’s current.

Can you elaborate? To me it seems that if you are going through the expense of transmitting registrant data for the conversion from thin to thick, that this one date field is easy enough to add on. -andy