E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)
RFC 4114

Note: This ballot was opened for revision 08 and is now closed.

(Allison Mankin) (was Discuss, Yes) Yes

Comment (2004-12-22)
No email
send info
I had taken a Discuss to fix the OPTIONALs which needed to map to what was
optional or not in 3761, rather than NAPTR.  This was based on a query by Thomas.
The document now has a correct mapping to the record used by 3761, so it should
guide practice effectively.

(Jon Peterson) Yes

(Harald Alvestrand) No Objection

Comment (2004-11-18 for -)
No email
send info
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.

(Bill Fenner) No Objection

(Ted Hardie) No Objection

Comment (2004-11-16 for -)
No email
send info
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.

(Sam Hartman) No Objection

(Russ Housley) No Objection

(David Kessens) No Objection

(Thomas Narten) No Objection

(Bert Wijnen) No Objection

(Alex Zinin) No Objection

(Scott Hollenbeck) Recuse