You are here: Home > Participate > Join a Discussion > Mailman Archives
<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

Re: ETSI on Minimum Requirements for European ENUM Trials

  • To: "Stastny Richard" < >
    < >
  • From: Richard Shockey < >
  • Date: Wed, 23 Oct 2002 15:08:40 -0400
At 07:29 PM 10/23/2002 +0200, Stastny Richard wrote:

Dear all,

ETSI SPAN11 started last week the work on an ETSI Guide on
TD19r7 ETSI Minimum Interoperability requirements for European ENUM
trials
http://www2.nic.at/mailarch/enumtrial/doc00016.doc

BTW nice piece of work ..an excellent start.... I have some notes and nits from my perspective sitting on the other side of the pond.



-  6.2.: probably should be changed to "it is assumed that there is only
   one tier1 registry per country _code_ within Europe. I'm quite sure
   that there are countries with more than one country code (eg. UK and
   french oversea territories?)

   Stastny: correct.
yes ... and certain British territories are actually part of the NANP aka "1" ... now dont ask me how they may be able to participate in the trial OK :-)


-  6.3.: Perhaps the description of ENUM registrars could be something
   like "ENUM registrars initiate delegations from the tier1 registry to
   ENUM DNS providers (tier 2) on behalf of ENUM registrants (E.164
   number owners). They interact with a validation agency to authorize
   and authenticate the registrant.

   Stastny: please add the proposed text and in addition:
   The ENUM Registrar must provide a web-based interface to the ENUM end
user
   for registration and later modification of his registration data.
   For identification and authentication userid and passwort is
sufficient.

Yep this is good....




-  7.: I suggest to add:
   Gaining experience in provisioning ENUM delegation processes between
   ENUM Registrars and Tier1 Registries. Exploring options for unified
   provisioning protocols across different countries as well as for
   unified validation processes.
agreed ... it should be noted it is not perfectly clear how data to populate T1 or T2 is actually passed between entities...though there has been some discussion of the e164 EPP model.

Title : Extensible Provisioning Protocol E.164 Number Mapping
Author(s) : S. Hollenbeck
Filename : draft-ietf-enum-epp-e164-01.txt
Pages : 20
Date : 2002-8-28

This document describes an Extensible Provisioning Protocol
(EPP) extension mapping for the provisioning and management of E.164
numbers representing domain names stored in a shared central
repository. Specified in XML, this mapping extends the EPP domain
name mapping to provide additional features required for the
provisioning of E.164 numbers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-enum-epp-e164-01.txt

I'm not convinced the EPP transport mechanism is appropriate

You might consider thinking about things like this for future work items ....

Try starting to think how does a IP-PBX actually update data in a Add-Modify-Delete mechanism.

A New Internet-Draft is available from the on-line Internet-Drafts directories.


Title : Extensible Provisioning Protocol Over SOAP
Author(s) : H. Liu et al.
Filename : draft-liu-epp-soap-00.txt
Pages : 24
Date : 2002-9-26

This memo documents a proposal for exchanging EPP (Extensible
Provisioning Protocol) messages as XML documents between a client and
a server via SOAP (Simple Object Access Protocol), using the SOAP
request/response communication model. An EPP message is encapsulated
in the SOAP Body, while the EPP session information is encoded in the
SOAP header, enabling EPP session-oriented messaging over the SOAP
protocol. It is designed to work on top of any transport bindings
defined for SOAP, taking advantage of the variety of SOAP software
tools and environments available for web services.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-liu-epp-soap-00.txt





-  9.: "At least manual interface ..." (Note: exploring options for a
   unified automated Registry-Registrar-Protocol)

   Stastny: can this be enhanced to at lest structured e-mail?

   "WHOIS type capability ... " Imho WHOIS is pretty the worst choice
   for information exchange between registry and registrar: The data
   format is not unified, if using the thin model, records at different
   registrars will lokk different. If using the thick model, records at
   different registries will be different. WHOIS can only be an
   informational service, and therefore it's only application is to
   provide information to the public (there is no authentication anyway,
   so it's quite hard to limit access to WHOIS).

   It has to be discussed if WHOIS (or a comparable protocol/
   information query method) is needed in production, but i
   consider it to be useful during trials.

   Stastny: the WHOIS is a information service. The access to WHOIS
should
   be common within the trial (see proposal on SRV records in Tier 1),
but not
   the content.
I totally agree ... the use of WHOIS in ENUM it is certainly a national matter for ADMIN contact data f ( I dont know why any one would want to in the first place ) but I'm of the increasing opinion that the TECHNICAL contact data MUST be exposed in a WHOIS.

Thoughts?

I'll be very curious to see how discussions of this play out in the trial context.


   Stastny: replace with proposed text, even if empty zones are not
possible
   (see above)

   "Technical and administrative ... " - No one will tell you the OS
   version and configuration details of his name server. I consider it
   useful to have contact information, but requiring anything beyond
   that will scare DNS providers off.

I would say technical contact data is vital...



-  11.1.: "Appropriate logging ... " What's appropriate? If there are no
   problems, logging nothing at all is perfectly appropriate ;)

-  12.: "Name servers should support authentication of DNS queries.."
   Whilst this is of course a desireable capability, it's way off the
   current state of the art of production DNS. It adds another chance of
   failure to the trials (imho).
I'm going to have something more to say about the DNSSEC issues in a forthcoming draft on ENUM Security and Privacy issues but I would say that ANY discussion of DNSSEC in the context of ENUM is premature.

It is not deployed anywhere in any TLD as of this date and it is not clear when and if it will. Any questions or possible requirements about DNSSEC should be deferred till the "Gods of DNS Ops" have spoken.


   "Bind version 9.1 _should_": DON'T require specific software
versions. Bind
   9 is much slower than Bind 8 and (imho) overfeatured for production
   use. For that reason, Bind 8 is still the most widely used Name
   server.

   What were the reasons to require Bind 9.1?

   Stastny: The reason for 9.1 was mainly DNAME. DNAME is needed if
   one wants to "redirect" a whole tree (CNAME redirects only one zone).
   We discussed this for number splits and parallel numbering. IMHO this
   still requires further study and should not be included in the
minimum requirements
   (althouh I want to see a solution).
I agree ... I would certainly recommend trial participants us BIND 9 but every time I see DNAME and ENUM put together I get very very worried ..its not a "good idea' tm.

Other notes:

10...and noted in 12

SIP ..H.323 I found it interesting there was no detail about these services in the document :-)

10.1 Why is there a discussion of the use of TXT records ..in what context? I'm curious ..

12. Why are you specifying that the NAPTR replacement field must always be empty? I know this is TBD but is there a reason for that.




>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<
	    
	    

> or <
	    
	    

>
 <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
  • Post To The List:
<<< Chronological >>> Author    Subject <<< Threads >>>