I haven't read all of the specs top-to-bottom, but in general the EPP specs are very careful to provide an implementation that is agnostic to the business policies of the Registry. As long as PIR supports the syntax of the EPP message, I believe that it is within their rights to return an error code instead of a success code if their business policies disallow this data transformation. For example, PIR may choose to return error code 2306, Parameter value policy error, in this case. _Mike -----Original Message----- From: Rick Wesson [mailto:wessorh@ar.com] Sent: Tuesday, October 12, 2004 4:06 PM To: Mike Lampson Cc: 'Registrars Constituency'; Bhavin Turakhia Subject: RE: [registrars] FW: Registrars - gTLD Registries Constituencies - Items for Discussion? 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@gnso.icann.org [mailto:owner-registrars@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@dotcoop.coop] Sent: Tuesday, October 12, 2004 2:24 AM To: bhavin.t@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)