Re: ETSI on Minimum Requirements for European ENUM Trials
- 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>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<