Subject: Re: [regext] [eppext] Registrar Expiration Date I-D

From: Patrick Mevzek <[email-masked]>
Date: Wed, 23 Mar 2016 00:27:09 +0100

Gustavo Lozano <[email-masked]> 2016-01-21 20:59
> 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. 

[…]

> Your feedback is appreciated.

I've implemented this extension in my EPP client.

Some comments:

- there is no discussion on the timezone of the date given by
  the registrar
But core EPP has:
"   Date and time attribute values MUST be represented in Universal
   Coordinated Time (UTC) using the Gregorian calendar. "
Should it be the same for the registrar expiration date?

- what happens in case of a 1001 reply?
should the rrExDate:exDate (if provided by registrar or not) be
updated immediately, or only when the pending command is finalized?

- §2.2.2
why is there a need to base the decision on the presence of the
extension at login time?
Why not just use the date as provided by registrar if present and
otherwise set it as the exDate?

The fact that we sometimes just copy the exDate seems to overlap some
previous non technical discussion about the usefulness of this data,
if it is just a copy of another one, creating questions when both are
not in sync anymore.

Also, the discussion on the 2004 response if rrExDate (writen as
rExDate, so probably a typo here) is before crDate seems close to
business rules and not protocol ones, since with this current
definition rrExDate could be crDate + 1s, which has no more useful
meaning as if it were crDate - 1s.

- §2.2.1.2
the given example lacks the
</rrExDate:rrExDateData>
closing node

- §5.  IANA Considerations
both IANA registrations are for the same namespace.
there is probably a s/ns/schema/ needed in the second one

- §7.2 
The URL for [ThickWhoisPolicy] does not seem right

HTH,

-- 
Patrick Mevzek

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 22 Mar 2016 23:05:22 -0400

> if it is just a copy of another one, creating questions when both are

Right.  I particularly predict that these could drift over time if
they're not automatically synced on absence.  The sorts of things that
always get people here are problems like leap seconds, leap years, and
off-by-one-second renewal times due to < vs <= mistakes in database
code.  Having seen at least 5 million of these kinds of errors in
various database-backed systems, I think it is a safe bet that it will
happen again :-)

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Patrick Mevzek <[email-masked]>
Date: Thu, 24 Mar 2016 01:29:38 +0100

Andrew Sullivan <[email-masked]> 2016-03-23 04:06
> various database-backed systems, I think it is a safe bet that it will

I fear that obviously a lot of problems will arise around the
auto-renew case, since it is the most frequent one (only one?) in
gTLDs.

The registry has its expiration date shown through whois, and may have
the "registrar expiration date" as given by the help of this EPP
extension.
The registrar may display in his whois another expiration date.
So basically we may have 3 expiration dates, except if registrar whois
disappears altogether.

But until then, at expiration, a domain is automatically renewed:
- registry expiration date change and this is reflected in registry
  whois
- since it is an out of band action and outside of EPP, there is no
  reason for the registrar to update its "registrar expiration date"
at registry, nor at its own local whois
So then we have two sets of dates, the registry showing one instance
of each
- then, during the autorenew grace period, the registrar is paid by
  its client, hence he will probably update its own local expiration
date, but at that time he has no incentive/need to contact the
registry (no need to do an explicit renew) so there is no guarantee
that the registrar will update its "registrar expiration date" on
registry side.
But the registrar expiration date has changed locally (and may/should
be the same as the registry expiration date, but there is no guarantee
of that either, taking into account corner cases in date calculus,
such as with timezones or leap years), so we get 3 possibly distinct
expiration dates :-(

Also, not everyone knows what a registrar or a registry is, and many
people discover at one point or another all their personal details
from whois extracted on some website (and it will come even more like
that with RDAP as it has been discussed already), where there will see
a "registry expiration date" and a "registrar expiration date", and I
doubt that many people will be able to understand why their domain has
2 expirations dates (the question will be if there are the same dates or
not: if they are the same, why having two of them, and if they are not
the same, why and which one is the "true" one?)

-- 
Patrick Mevzek

---

From: Gustavo Lozano <[email-masked]>
Date: Tue, 29 Mar 2016 16:03:17 +0000

Thank you Patrick,

Comments inline.

Regards,
Gustavo

On 3/22/16, 16:27, "regext on behalf of Patrick Mevzek"
<[email-masked] on behalf of [email-masked]> wrote:

>[Š]

Great news, thank you.

>Should it be the same for the registrar expiration date?

Yes, I will add text in the next version of the I-D.

>updated immediately, or only when the pending command is finalized?

After the pending command is finalized, because the Registrar Expiration
Date is an extra attribute that is being transmitted for the purpose of
being shown in RDDS (i.e. Whois, RDAP, etc.) by the registry, therefore
the transformation on the main object should be finalized first. I will
add text in the next version of the I-D.

>otherwise set it as the exDate?

The objective is to support three possible modes of assertion by the
registrar:

* A registrar that does not know how or does not want to transmit the
Registrar Expiration Date (extension not included at login). In this case
the registry shall not show a value in the Registrar Expiration Date field
in RDDS (i.e. Whois).

* A registrar that wants the registry to always show the same value in
both expiration date RDDS fields (Registry and Registrar Expiration Date).
For this case, the registrar includes the EPP extension at login time, but
does not include the rrExDate:rrExDateData during the transform command.
If the domain name is auto-renewed, the registry shall show the same value
in both expiration date RDDS fields (Registry and Registrar Expiration
Date). If the business model of the registrar allows this mode of
operation, it should be simple to implement by the registrar, because the
only code change is to include the extension at login time.

* A registrar that wants to set the Registrar Expiration Date to a certain
value. For this case, the registrar includes a rrExDate:rrExDateData in
the transform command. In some cases, after the auto-renew by the
registry, the registry expiration date is one year in the future versus
the registrar expiration date, therefore the registrar shall send a
transform command once the registrar expiration date should be updated
(e.g. the registrant payed for an extra year).

Probably the text in the I-D needs to be clarified.

>if it is just a copy of another one, creating questions when both are

It¹s not just copying, it is basically telling the registry to keep them
in sync. In other words, it¹s analogous to say: by default keep in sync or
always show the same value in both expiration dates (Registry and
Registrar Expiration Date) in Whois.

>rExDate, so probably a typo here)

To be fixed in the next version of the I-D.

>is before crDate seems close to

It does not make sense to say that the rrExDate is before the creation
date of the object. This is the only rule related to protocol, and I think
should be captured in the I-D.

To be fixed in the next version of the I-D.

>there is probably a s/ns/schema/ needed in the second one

To be fixed in the next version of the I-D.

>The URL for [ThickWhoisPolicy] does not seem right

To be fixed in the next version of the I-D.

>
>HTH,
>
>-- 
>Patrick Mevzek
>
>_______________________________________________
>regext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/regext

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 29 Mar 2016 23:00:45 +0200

Patrick Mevzek <[email-masked]> 2016-03-23 00:28
> I've implemented this extension in my EPP client.
 
Another point:
there is no information on registration in the IANA regitry of EPP
extensions.
Other drafts have such sections, like:
https://tools.ietf.org/id/draft-brown-epp-reverse-00.html#rfc.section.7.2

Should there be one?

-- 
Patrick Mevzek

---

From: Gustavo Lozano <[email-masked]>
Date: Tue, 29 Mar 2016 21:31:58 +0000

Thank you Patrick,

Comments inline.

Regards,
Gustavo

>https://tools.ietf.org/id/draft-brown-epp-reverse-00.html#rfc.section.7.2

Yes, I will add this on the next version of the I-D.