Subject: [Enum] epp-e164 & naptr objects

From: Chip Sharp <[email-masked]>
Date: Thu, 23 Aug 2001 09:46:34 -0400

Warning - the following is allegedly a technical question. :-)

Can the information required to be entered into DNS for RFC2916  be 
adequately dealt with (in EPP) by defining a <host:naptr> and/or 
<domain:naptr> object?

What other information is needed?  Specific examples and proposals would be 
appreciated.

I understand that EPP is being dealt with in provreg.  I'd like to 
understand what additions to their work are needed for support of RFC2916.

Thanks,
Chip

_______________________________________________
enum mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/enum

---

From: Richard Shockey <[email-masked]>
Date: Thu, 23 Aug 2001 12:18:03 -0400

At 10:06 AM 8/23/2001 -0400, Hollenbeck, Scott wrote:
> >-----Original Message-----
> >From: Chip Sharp [mailto:[email-masked]]
> >Sent: Thursday, August 23, 2001 9:47 AM
> >To: [email-masked]
> >Subject: [Enum] epp-e164 & naptr objects
> >
> >

Ahhh..at last !

>It's certainly possible to define object extensions for NAPTR record
>provisioning; the extension mechanism might actually be easier and more
>intuitively obvious than defining a new object type as currently described
>in epp-e164-00.  That can be fixed with a rewrite.  It's also possible to
>define extensions to provision other RRs if it makes sense to do so.

I certainly agree ... this was the whole purpose of the provreg work 
group.  That is what the E in EPP meant  or the X in XRP, a complimentary 
proposal submitted to the provreg WG by some of my colleagues at 
NeuStar.  Extensibility is the key.

Though it was self-evident to some of us that the provreg work could be 
used by other applications that require provisioning models, IP number 
administration and ENUM were mentioned in the WG early on, the provreg WG 
needed to deal with the central problem of TLD administration first since 
there were political requirements coming from ICANN that required that 
application come first.

>I don't believe anything other than the fields described in 2916 are needed
>unless some non-DNS data is also required somewhere.  If that's the case,
>I'm also open to suggestions.

Well this is where it can get interesting.  Since the administration of 
2916 falls completely outside the procedures outlined by ICANN for TLD's it 
will be up to the relevant national administrations (Tier 1) to develop 
appropriate requiments for data objects.

I'm pretty convinced that there will be additional requirements for data to 
be passed between ENUM Registrars and ENUM Registries. For instance CIC 
codes? PSTN Service provider of record? I can certainly think of others. 
This may vary between country to country.

Though there is no requirement for WHOIS to be exposed as part of a ENUM 
registration, again this is not ICANN, ENUM Registries may be required to 
maintain a "fat registry" of data beyond simple NS, or NAPTR records, Admin 
contact and Technical contact. What data they may be required to maintain 
could be a topic of discussion at groups such as the emerging US ENUM Forum.

I'm confident though that the EPP/XRP protocol will have sufficient tools 
to do the job no matter what the requirements are.

www.enumf.org

><Scott/>

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice 571.434.5651 Cell : 314.503.0640,  Fax: 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.com>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<