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

[Ballot comment]
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.

[Ballot discuss]
Sent to PAF and others:

OLD:

-  An  element that contains a NAPTR order value.

  -  An  element that contains a NAPTR preference value.

  -  An OPTIONAL  element that contains a NAPTR flags
      value.

  -  An OPTIONAL  element that contains a NAPTR service
      value.

  -  An OPTIONAL  element that contains a NAPTR regular
      expression value.

  -  An OPTIONAL  element that contains a NAPTR
      replacement value.

NEW:

  -  An  element that contains a NAPTR order value.

  -  An  element that contains a NAPTR preference value.

  -  An OPTIONAL  element that contains a NAPTR flags
      value.

  -  An  element that contains a NAPTR service
      value.

  -  An OPTIONAL  element that contains a NAPTR regular
      expression value.

  -  An OPTIONAL  element that contains a NAPTR
      replacement value.
flags remains OPTIONAL because if it is not present, this is the
case of the last paragraph of 2.4.1 in 3761

The service value cannot be OPTIONAL according to 2.4.2, right?

Under that last paragraph of 2.4.1, both regex and replacement
might not be present so they remain optional, right?

Does preference have to be there, since it is advisory in ENUM?
Does it become OPTIONAL?

[Ballot comment]
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.

[Ballot comment]
Currently, Section 3.1.2 contains this text:

  In addition, the EPP  element MUST
  contain a child  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  has now been re-defined so that
is now require.  I'd suggest rephrasing this so that it is clearer that
this extensions requires .  Possibly:

  In addition, servers using this extension MUST return
  an  element containing an  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.

[Ballot comment]
Currently, Section 3.1.2 contains this text:

  In addition, the EPP  element MUST
  contain a child  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  has now been re-defined so that
is now require.  I'd suggest rephrasing this so that it is clearer that
this extensions requires .  Possibly:

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

AD review was to change the names in the xml registrations to not be just "e164" because
this might be a registration needed later for a different purpose.  The 06 rev made this fix.