ICANN/GNSO GNSO Email List Archives

[registrars]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [registrars] Final Call (so wake up) EPP Transition Implementation Group

  • To: registrars@xxxxxxxx
  • Subject: Re: [registrars] Final Call (so wake up) EPP Transition Implementation Group
  • From: Mike Lampson <lampson@xxxxxxxxxxxxxx>
  • Date: Fri, 10 Sep 2004 13:14:28 -0400
  • Importance: Normal
  • Sender: owner-registrars@xxxxxxxxxxxxxx

First one didn't get through...

_M

-----Original Message-----
From: IARegistry Technical Staff
Sent: Friday, September 10, 2004 9:51 AM
To: registrars@xxxxxxxx
Subject: RE: [registrars] Final Call (so wake up) EPP Transition
Implementation Group

>> There were prior collections of issues, Elana's note of June 10th is one,
>> and I hope Tim has the ExCom's copy of noted issues.

Here are my concerns.  Mostly, these concerns relate to the inconsistent
business rules and interpretation of the EPP specification by the gTLD
Registries.

1) A change to the EPP <poll> command response was implemented in draft 7 of
the EPP specification and made it into the final 1.0 release.  (See
http://www.cafax.se/ietf-provreg/maillist/2004-08/msg00001.html )  This
change probably doesn't make sense and NeuLevel has documented that they
will follow the earlier "non-standard" method described in draft 6 and
earlier.   Regardless of the whether the spec is followed or not, the gTLD
registries should be consistent in the data returned in response to the
<poll> command.

2) Some gTLD registries do not post a message to the <poll> queue for each
event that occurs during the transfer of a domain.  For example, PIR only
posts a message when a transfer is requested.  They should also post one
when the transfer in explicitly acknowledged.

3) Right now Verisign sends out a daily report of all nameserver renamings.
We need comparable information from the EPP Registries.  I believe this
should be implemented by having Registries send a <poll> message to all
Registrars each time an internal nameserver is renamed.  This is so we can
then propagate this nameserver rename to external host records in the other
Registries.  For example, I could have a nameserver blue.example.org hosting
the domain iaregistry.biz.  If I rename this nameserver to
red.hostdomain.org, this change will have no affect in the BIZ registry.
See section 1.1 of RFC 3731 for an explanation of external hosts.  As
external hosts are considered private to each Registrar, every Registrar
must take action on any domains that they sponsor that happen to use this
nameserver.

Thanks,

Mike Lampson
The Registry at Info Avenue, LLC




<<< Chronological Index >>>    <<< Thread Index >>>