Subject: [provreg] Proposal: A method in EPP for registry policy discovery

From: Keith Gaughan <[email-masked]>
Date: Thu, 16 Jun 2011 17:55:39 +0100

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.

For this, I'd propose a command, possibly called <policy>, which would work
along the following lines. This would take a single child element, either
<objURI> or <extURI>, which would contain the URI of the object or extension
whose policy is being queried. For example, here are some rough sketches of
response:

REQ:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <policy>
    <objURI>urn:ietf:params:xml:ns:epp-1.0</objURI>
  </policy>
</epp>

RES:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <polData>
      <policy>
        <supports>
          <hello/>
          <login/>
          <logout/>
          <poll/>
        </supports>
      </policy>
    </polData>
  </response>
</epp>

REQ:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <policy>
    <objURI>urn:ietf:params:xml:ns:domain-1.0</objURI>
  </policy>
</epp>

RES:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <polData>
      <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 -->
          <domain:info/>
          <domain:create/>
          <domain:transfer/>
          <!-- This registry supports autorenewal, but not renewal,
               thus <domain:renew> is omitted. -->
          <!-- Omitting <domain:delete> would be like declaring that
               registry requires explicit renewal -->
          <domain:delete/>
          <domain:update/>
        </domain:supports>
        <!-- One or more of these, one for each supported zone -->
        <domain:zone name="gy">
          <!-- Information on the lifecycle such as, supported extension
               periods, maximum period a domain may be renewed up to, &c.
               -->
          <domain:create>
            <domain:period unit="y" default="yes">1</domain:period>
          </domain:create>
          <domain:transfer>
            <!-- Registry supports free transfers only -->
            <domain:period default="yes">0</domain:period>
          </domain:transfer>
          <!-- &c. -->
        </domain:zone>
      </domain:policy>
    </polData>
  </response>
</epp>

REQ:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <policy>
    <extURI>urn:ietf:params:xml:ns:rgp-1.0</extURI>
  </policy>
</epp>

RES:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <polData>
      <rgp:policy xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0">
        <!-- One or more of these, one for each supported zone -->
        <rgp:zone name="gy">
          <!-- Subset of statusValueType - I'm riffing off of CoCCA's
               Pricing and Policy pages here -->
          <rgp:period s="addPeriod" length="1" refund="14"/>
          <rgp:period s="renewPeriod" length="1" refund="14"/>
          <rgp:period s="autoRenewPeriod" length="0" refund="0"/>
          <rgp:period s="transferPeriod" length="0" refund="0"/>
          <rgp:period s="redemptionPeriod" length="28" refund="0"
                      hasRestoreFee="yes"/>
        </rgp:zone>
      </rgp:policy>
    </polData>
  </response>
</epp>

As I said, this is just a rough sketch and needs a lot of work, but I believe
the basic idea to be sound. I'm very much open to any input.

If this is too invasive to the protocol, an alternative would be to have a
standard machine-readable format for registries to publish this information.

-- 
Keith Gaughan, Software Developer
PGP/GPG key ID: 3E896381
Blacknight Internet Solutions Ltd. <http://blacknight.com/>
12A Barrowside Business Park, Carlow, Ireland
Registered in Ireland, Company No.: 370845

---

From: Gavin Brown <[email-masked]>
Date: Thu, 16 Jun 2011 18:33:45 +0100

I'm not sure that server policy should be communicated via EPP. EPP is not a general-purpose registry-registrar communications protocol, it's an object provisioning and management protocol.

As an alternative solution, how about this: an additional element in the server <greeting> element that contains a URI, which points to an XML document that describes the policy elements you've suggested? This would have the advantage of being reusable: eg, every CoCCA based registry could point to a policy document on CoCCA's web site.

G.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Global Registry Services
Innovative Registry Services for ccTLD and gTLD registries
https://www.centralnic.com/grs

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

On 16 Jun 2011, at 17:55, Keith Gaughan <[email-masked]> wrote:

> _______________________________________________
> provreg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/provreg

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 17 Jun 2011 09:11:30 +0200

On 16/06/11 19:33, Gavin Brown wrote:
> I'm not sure that server policy should be communicated via EPP. EPP is not a
> general-purpose registry-registrar communications protocol, it's an object
> provisioning and management protocol.
>
> As an alternative solution, how about this: an additional element in the
> server<greeting>  element that contains a URI, which points to an XML
> document that describes the policy elements you've suggested? This would have
> the advantage of being reusable: eg, every CoCCA based registry could point
> to a policy document on CoCCA's web site.
>
> G.
>

Hi,

this is arguable, but the question of how the policies are accessed is IMHO not 
the main issue. To me, the big question is how expressive, how flexible such 
policy descriptors should be. A formalized policy only makes sense if it is 
targeted to be processed automatically by the registrar's software. If the 
schema is too restricted, registries cannot express their actual policy and the 
registrar software will fall into traps; if it is too flexible, the flexibility 
will mostly stay unused (registry-wise) on the one hand and will require huge 
implementation efforts on the registrar side to cover all potential cases on the 
other hand.

Regards,

Klaus