Re: Proposal: A method in EPP for registry policy discovery

Keith Gaughan <[email protected]> 2011-06-16 18:56
> This proposal comes out of the comments Jothan has been making recently, which
> I agree wholeheartedly with.
> 
> As a registrar, one of our great problems registry policy discovery. This is
> of particular importance with it comes to ccTLDs, whose policies can vary
> drastically. For instance:
> 
>  * what commands does the registry support with particular objects,
>  * what is the lifecycle of a domain in a particular zone,
>  * does removing a domain from redemption incur a cost to the registrar,
>  * how long after registration, transfer, and renewal must it be before a
>    domain can be transferred or renewed,
>  * what periods does a registry support for registrations, transfers, and
>    renewals,
>  * does the registry support the poll command,
>  * for contacts, which types does the <postalInfo> element support (this is a
>    crapshoot and registries, in my experience, never document this),
>  * does the registry support registrant modification,
>  * are there per-command limits.
> 
> These are just the ones I could think of off the top of my head.
 
If not done already, I believe you can find other examples/ideas in
section 4.4 of my draft at
http://www.deepcore.org/ietf/draft-mevzek-epp-implementor-experience-00.txt

However, I fear to have the same opinion than Klaus, meaning that it
would be hard to specify clearly all details for everyone. For
example, pricing components would be probably better left out of such
scope.

There was however, I believe in some past CENTR meeting, a ccTLD
registry explaining they have all of their EPP business rules encoded
in an XML document which is parsed and used by their EPP server as is,
or during tests maybe,  sorry I do not remember details.

Also something else that is true for all new possible extension that
would be useful in all EPP servers: if you can not have support of
current registries, starting with gTLDs, then the extension even if
very useful in itself, would be practically not useful if not used by
enough registry operators. So there would be probably a lot of non
technical work there, to convince operators to adhere.

I do however completely agree with you that for registrars the current
situation is difficult, since registry policies are not often clear
nor clearly available, even less in a kind of standard fashion. I'm
not sure however the IETF could do anything in that aspect, maybe
something would be better to conduct among ccTLDs organizations such
as CENTR, or inside ICANN Registrars/Registries consistuencies.

However if interested, please find below some quick ideas:

>       <domain:policy xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
>         <domain:supports>
>           <!-- No support for <domain:check> as the registry expects
>                registrars to use an external DAC service -->

It would be useful then to know DAC is prefered, so something should
still be provided there.

>           <domain:info/>

Can the registrar do a domain:info on a domain it manages ? With or
without the associated authInfo? Is the content retrieved different?
In what manner?

>           <domain:create/>

What are the minimum/maximum years allowed? Which contacts are
mandatory, which are optional, in what cardinality, etc.

>         <!-- One or more of these, one for each supported zone -->
>         <domain:zone name="gy">

Yes, but I'm not sure it's orthogonal with the list you provide above.
For example, in one zone, domain:delete may be possible, and not in
another. So probably everything should be per zone.

-- 
Patrick Mevzek
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg