WG: [registrars] Discussion of EPP 1.0 Transition Issues

[Thomas Keller]

Tim,

thanks for starting this discussion. In general I agree with you but would 
like to add some additional points. These points are not directly related 
to changes inside the EPP protokol but given that the Registries are already 
changing their systems they might be willing to change a little more for good.

1. This has nothing to do with EPP but with the migration itself. It would be very 
   favorable for all Registrars if they would get two sandboxes (to be able to test 
   transfers internally) which are a 100% equivalent to the real system with exeption 
   of the grace periods.

2. It should be possible to determine a Registrar inside all Registry
   systems by its IANA id.

3. The maintenance notifications should be standardized

4. All relevant informations about an object must be available through
   the EPP system. Out of band communication like having to use whois
   to get contact informations should not be necessary.
   
Best,

tom,



> Von: owner-registrars at gnso.icann.org
> [mailto:owner-registrars at gnso.icann.org] Im Auftrag von Tim Ruiz
> Gesendet: Dienstag, 19. Oktober 2004 13:34
> An: Registrars at dnso.org
> Betreff: RE: [registrars] Discussion of EPP 1.0 Transition Issues
> 
> 
> I'll kick off this discussion with my views.
>  
> 1. Agreed.
>  
> 2. Agreed.
>  
> 3. I don't necessarily agree. Right now, what is returned is publically
> available through Whois. So I don't see the point in restricting this. At
> the very least the create date, update date, status, and registrar of record
> should remain available. Again, this is publically available information. If
> a registrar is using the DomainInfo command to mine data, removing the
> contact information should help that. In any event, they will only move to
> mining Whois data where tracking who is making the request will be more
> difficult, especially if they are able to attack from multiple IP addresses.
>  
> This information is used by some registrars to improve their customer
> experience and confidence. For example, we use the status to determine the
> transferability of a domain. We would prefer to let the customer requesting
> the transfer know right up front that they cannot transfer the domain in its
> current status and give some idea of what they may need to do.
>  
> 4. I understand this to mean that the statuses and methodology of RFC 3731
> section 2.3 must be implemented consistently by all registries. If so, then
> I would agree.
>  
> 5. Agreed.
>  
> 6. If this is referring to the server response described in RFC 3730 section
> 2.9.2.4, I agree. If this is referring to the RECOMMENDation that only the
> gaining and losing registrar be allowed to make <transfer> queries, I would
> still agree.
> 
> 7. I see little if any benefit to knowing the ID of the next message on the
> queue. Regardless of the RFC I would prefer that the <poll> response
> continue to return the ID of the message being acknowledged.
>  
> 8. Agreed.
>  
> Tim
>  
> 
> 
> -------- Original Message --------
> Subject: [registrars] Discussion of EPP 1.0 Transition Issues
> From: "Tim Ruiz" <tim at godaddy.com>
> Date: Tue, October 19, 2004 5:38 am
> To: Registrars at dnso.org
> 
> All,
> 
> The following are issues that apply specifically to the implementation
> of EPP 1.0. There may be others that have been raised that I missed, so
> please let me know. We should discuss these on the list and develop a
> position on each sooner than later since the registries are already in
> implementaiton mode. These positions could be presented and discussed
> with the registries in Cape Town, but I would suggest we request a
> conference call with the registries prior to Cape Town if possible to
> present and discuss our positions.
> 
> 1. The UTC time format must be the mandatory time format for all dates
> and timestamps generated in and through the EPP System.
> 
> 2. Use of unique client and server transaction ids must be possible.
> 
> 3. The output for not owned objects must be restricted if the request is
> not authenticated by the auth-info code. The data to be displayed
> without authendification must still be determined.
> 
> 4. The same unified object status must be available to all objects
> across all registries.
> 
> 5. The ISO-3166/1 standard must be used to reflect countries in objects
> where a country is used.
> 
> 6. The registrar id of the registrar who initiated a transfer must be
> known at time of the transfer.
> 
> 7. A change to the EPP <poll> command response calls for it to return
> the ID of the *next message* on the queue instead of the ID of the
> message that is being acknowledged. Regardless of the EPP 1.0 spec,
> does this really make any sense?
> 
> 8. External Hosts are described in RFC 3731. Although not required by
> the RFC, it would seem to make sense that a Registry provide a method
> of notification of Host name changes so that a registrar may propagate
> that change within its own system as well as with other registries that
> it may have registered it as an External Host. It has been suggested
> that this might be done through the <poll> command.
> 
> Tim 
> 
> 
> ----- End forwarded message -----
> 
> Gruss,
> 
> tom
> 
> (__)        
> (OO)_____  
> (oo)    /|\	A cow is not entirely full of
>   | |--/ | *    milk some of it is hamburger!
>   w w w  w  
> 
> 

Gruss,

tom

(__)        
(OO)_____  
(oo)    /|\	A cow is not entirely full of
  | |--/ | *    milk some of it is hamburger!
  w w w  w