[registrars] FW: Registrars - gTLD Registries Constituencies - Items for Discussion?

[Rick Wesson]

Not implementing the <host:chg> opperation would make PIR non-compliant
with RFC 3732. Per ICANN Agreements the registry MUST implement ALL
protocol elements of the RFC specified with "MUST"

If PIR decides not to implement <host:chg> they they don't implement
epp-1.0 and per their contracts thay are required to implement the
protocol which includes the <host:chg> element.

Sounds like PIR would need a letter from ICANN that states why they don't
comply with the protocol.


-rick


On Tue, 12 Oct 2004, Mike Lampson wrote:

> Bhavin,
>
> PIR has unilaterally decided that the <host:chg> operation of RFC 3732,
> section 3.2.5 is too dangerous to use.  See the following from PIR's FAQ:
> http://www.pir.org/faqs/for_registrars/epp_upgrade#howmultiplehosts
>
> Essentially, they are prohibiting the renaming of nameservers, which would
> nullify the need for the queing of <poll> messages as I requested in item #2
> below.  My question is: should we ask for the behavior of this operation to
> be consistent for all Registries?
>
> Personlly, I do not see that this operation is so dangerous.  This also
> brings up the issue of how do you delete an expired domain if other domains
> are using nameservers (hosts) belonging to this expired domain.  From RFC
> 3731, Section 3.2.2:
>
> > A domain object SHOULD NOT be deleted if subordinate host
> > objects are associated with the domain object.  For example,
> > if domain "example.com" exists, and host object
> > "ns1.example.com" also exists, then domain "example.com"
> > SHOULD NOT be deleted until host "ns1.example.com" has been
> > either deleted or renamed to exist in a different
> > superordinate domain.
>
> Of course the subordinate host objects cannot be deleted if it is referenced
> by different "superordinate" domains.  These other domains cannot be changed
> by the Registrar wishing to delete EXAMPLE.COM if these "superordinate"
> domains are sponsored by other Registrars.
>
> Thanks,
>
> _Mike
>
>
> -----Original Message-----
> From: owner-registrars at gnso.icann.org
> [mailto:owner-registrars at gnso.icann.org]On Behalf Of Bhavin Turakhia
> Sent: Monday, October 11, 2004 5:42 PM
> To: 'Registrars Constituency'
> Subject: [registrars] FW: Registrars - gTLD Registries Constituencies -
> Items for Discussion?
>
>
> hi all,
>
> please read below email from Carolyn Hoover on behalf of the registries
> constituency. some of the issues need comments from us, and it would be
> great if all of you can send in your comments to carolyn, unless they are
> for a specific registry, in which case you may send them on the mailing list
> or to the concerned registry
>
> bhavin
>
>
>
>
> From: Hoover, Carolyn [mailto:choover at dotcoop.coop]
> Sent: Tuesday, October 12, 2004 2:24 AM
> To: bhavin.t at directi.com
> Subject: Registrars - gTLD Registries Constituencies - Items for Discussion?
>
>
> Dear Bhavin,
> I know that the registrars have been very busy over the last month or so
> dealing with the change in leadership in the Registrar Constituency as well
> as other issues critical to the Constituency.
> On behalf of the gTLD Registries Constituency, I had previously contacted
> the Registrars that had expressed interest in participating in an EPP 1.0
> Implementation Group to discuss issues relating to that upcoming
> implementation and address any open issues.  Two issues were identified and
> are under discussion within our constituency.
> 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. (From James Gould (VGRS) to IETF list).
> 2. Right now Verisign sends out a daily report of all nameserver renamings.
> Registrars 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.
> (From Mike Lampon at The Registry at Info Avenue)
> Have any other issues been noted by Registrars?
> In addition, during those exchanges, one registrar noted that there had been
> a list of other items of concern to both registrars and the registries that
> had been discussed amongst the registrars in May 2004 but that had not been
> addressed.    We believe that some of these items have been addressed as
> noted below.  Other items have been jointly discussed in teleconference
> calls as well as the Kuala Lumpur joint meeting.
> Do you feel that any of these items require further discussion?  Are there
> new items that should be jointly discussed between the two constituencies
> either in a teleconference or at a joint session in Capetown?  Which
> approach do Registrars prefer?  If a meeting in Capetown is desired, when
> would there be time to meet?
> 1.      Com/net registries should remain thin after transition.
> 2.      Registries should conduct an OT&E environment prior to initiating a
> transition period
>                 *****This was addressed in the request for extension for EPP
> 1.0.  OT&E will exist at least between 12/31/04 and 3/31/05 and longer for
> some registries.
> 3.      Registries should sync up their business rules as much as possible
> (e.g., whois fields).
> 4.      A 3rd party should validate that the registries have synced the
> rules prior to initiating a transition period
> 5.      Transition processes should be the same or as similar as possible
> (see #14).
> 6.      RRP-EPP transitions should allow for legacy registrations until
> transitions are completed and checked in order not to turn off
> registration/renewals
> 7.      The transition should be as long as possible, at least through Q1
> 2005
>                 ***** This was addressed in the request for extension for
> EPP 1.0.
> 8.      Com/net transition should allow for an additional year beyond BONI
> 9.      The registries should not require auth codes for transfers until all
> transition periods are done.
>                 ***** Required by the Transfer Policy.
> 10.     An implementation committee that includes registrars should be
> established.
>                 ***** This has been established and two items have been
> presented to the registries.
> 11.     There should be a standardization of maintenance notices and other
> types of notices and reports.
> 12.     Registrars should be able to electronically query registries about
> their balances
> 13.     Registries should provide a list of recommended developers for
> reference by registrars that need consultants.
> 14.     Registries have not published any documentation or software
> regarding registry changes such as the transfer undo.
> Thank you for any comments on the above items that I can share with the gTLD
> Registries Constituency.
> Regards,
> Carolyn T. Hoover
> dotCoop Operations Center
> 1401 New York Avenue, Suite 1100
> Washington, DC  20005
> Tel:   +1.202.383.5453
> Fax:  +1.202 347.1968
> Toll-Free: +1.866.288.3154 (Intl Callers - Check www.att.com/traveler for
> your local toll free number)
>
>