Subject: [Enum] Fwd: objections: draft-ietf-enum-epp-e164-06.txt

From: Richard Shockey <[email-masked]>
Date: Tue, 26 Oct 2004 13:59:34 -0400

Date: Mon, 25 Oct 2004 14:20:47 -0400 (EDT)
From: Frank Thompson <fot at ca.afilias.info>
To: iesg at iesg.org
Cc: ietf at ietf.org
Subject: objections: draft-ietf-enum-epp-e164-06.txt
Sender: ietf-bounces at ietf.org
Hi All,
I would like to raise an issue with this draft which is currently in "Last
Call" in regards to the storage of the <e164:natpr> extension element:
Currently:
        3.1.2  EPP <info> Command
        .
        .
        The <e164:infData> element contains one or more <e164:naptr> elements
        that contain the following child elements:
        .
        .
        3.2.1  EPP <create> Command
        .
        .
        The <e164:create> element contains one or more <e164:naptr>
        elements that contain the following child elements:
        .
        .
        3.2.5  EPP <update> Command
        .
        .
        The <e164:update> element contains one or more <e164:add> or
        <e164:rem> elements.  Each <e164:add> and <e164:rem> element
        contains an <e164:naptr> element that contains the following
        child elements:
        .
        .
Objection:
        The mandatory inclusion of one or more <e164:naptr> elements is
the major point of contension.  By way of using the current epp schema for
domain mapping, <ns> elements may be used to point to external DNS servers
which will host the owning NAPTR records.  Thus creating a "thin" enum
registry while still accepting and generating "referral" e164 domains.
This allows the registry to host the native NAPTR records and all the
personal details that come along with that data or allow an external name
service to host these dynamic NAPTR records.
        As a further extension to the current support for <e164:naptr> is
the ability to allow <e164:cname> or <e164:dname> support.  These would
work much like the above <ns> approach, in that the zone generated
by the registry would point to an external DNS that would then resolve
the actual NAPTR records for public use.  While these are more experimental
additions, they are a valuable addition to the draft, while enum trials
are taking place to see how usability case studies perform in the real 
world.

        To ensure the integrity of the e164 domain, only one of the four
types may be associated with an e164 domain at a time.  The four types are
<ns>, <e164:naptr>, <e164:cname> and <e164:dname>.  This way the zone
generated for the e164 domain names will have a deterministic output each
and every time.
frank thompson
Afilias Canada Inc.
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Richard Shockey <[email-masked]>
Date: Tue, 26 Oct 2004 15:10:59 -0400

At 02:20 PM 10/25/2004, Frank Thompson wrote:
Hi All,
Since there was no discussion of this objection during WG last call could 
you at least explain why you waited till precisely the last minute to object?

        .
Objection:
        The mandatory inclusion of one or more <e164:naptr> elements is
the major point of contension.  By way of using the current epp schema for
domain mapping, <ns> elements may be used to point to external DNS servers
which will host the owning NAPTR records.  Thus creating a "thin" enum
registry while still accepting and generating "referral" e164 domains.
This allows the registry to host the native NAPTR records and all the
personal details that come along with that data or allow an external name
service to host these dynamic NAPTR records.
        As a further extension to the current support for <e164:naptr> is
the ability to allow <e164:cname> or <e164:dname> support.
Could you detail what cname or dname have to do with this? The use of 
either in the ENUM context have been considered harmful in the past.

These would
work much like the above <ns> approach, in that the zone generated
by the registry would point to an external DNS that would then resolve
the actual NAPTR records for public use.  While these are more experimental
additions, they are a valuable addition to the draft, while enum trials
are taking place to see how usability case studies perform in the real world.
Well a better way to deal this would have been to permit the original draft 
to proceed to RFC and propose these as extensions.