E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)
draft-ietf-enum-epp-e164-08

Reviewed by Suzanne Woolf, Gen-ART

Her review:

This draft is ready for publication as a Proposed Standard RFC. It
describes a small but important extension to EPP to support ENUM,
allowing for the mapping of ENUM E.164 numbers to an EPP registry and
then to NAPTR records for use in the DNS.

It's clear and straightforward, and seems adequately detailed to allow
implementors to support E.164 in EPP without adding any unintended
complexity or contradiction. I'm not entirely competent to debug the
XML, but there are no obvious errors, and comparison with the existing
NAPTR spec doesn't show any inconsistency-- it tracks the ENUM
specification quite closely.

The IANA Considerations is brief but seems adequate-- two new
assignments in an existing registry. And the Security Considerations
section is quite clear that this extension introduces no new security
issues but also assumes reliance on mechanisms already in EPP.

Currently, Section 3.1.2 contains this text:

   In addition, the EPP <extension> element MUST
   contain a child <e164:infData> element that identifies the extension
   namespace and the location of the extension schema.  

Those not very familiar with 3730 might assume that this means
that <extension> has now been re-defined so that <e164:infData>
is now require.  I'd suggest rephrasing this so that it is clearer that
this extensions requires <e164:infData>.  Possibly:

  In addition, servers using this extension MUST return
  an <extension> element containing an <e164:infData> child
   element that identifies the extension namespace and the location 
   of the extension schema.

There are similar phrases in the command sections, and it might
be useful to consider re-phrasing them as well.

I think these changes could be made in AUTH48, if the author
decides they are worth making.