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

[Mike Lampson <lampson@xxxxxxxxxxxxxx>]

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@xxxxxx]
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@xxxxxxxxxxxxxx
> [mailto:owner-registrars@xxxxxxxxxxxxxx]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@xxxxxxxxxxxx]
> Sent: Tuesday, October 12, 2004 2:24 AM
> To: bhavin.t@xxxxxxxxxxx
> 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)
>
>