ETSI on Minimum Requirements for European ENUM Trials
- Date: Wed, 23 Oct 2002 19:29:39 +0200
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
The work was initiated by European partizipants of the ITU-T SG2 Q1
Rapp.Meeting
in Copenhagen September 2002 dealing with ENUM Trials and by the results
of pre-BOF
concerning ENUM Trials in Europe at the RIPE-Meeting in Rhodes the week
before.
It is planned, that this work will progressed by e-mail and a revised
draft will
Be discussed at a joint meeting with ETSI TIPHON WG4 that will take
place on
5-6 December 2002 at the ETSI Headquarter in Sophia Antipolis.
The document should be finalized in a meeting from 14-17 January 2003.
Any additional input from the ripe-list participants is appricated.
One comment was already sent to the SPAN11_NAR list, to prevent
duplicate comments
I include the contribution below.
Best regards
Richard STASTNY
OeFEG/Telekom Austria
Box 147, A-1103 Vienna, Austria
tel:+43 664 420 4100
fax:+43 1 797 80 13
-----Original Message-----
From: Stastny Richard
Sent: Wednesday, October 23, 2002 7:07 PM
To: 'SPAN11_nar : ETSI SPAN11_nar list'
Cc: 'Lawrence Conroy'; Rudolf Brandner; 'axelm@localhost
Subject: Comments on ENUM Minimum Requirements
To the ad-hoc team on ENUM minimum requirements,
First I want to thank all of you on the exellent work you did in Sophia
last week.
Second, I want to include Lawrence Conroy and Rudolf Brandner, my
co-authors
of the ID draft-brander-enumservices-compendium-00.txt in the discussion
Third, I already received a comment from Alex Mayrhofer (nic.at)
regarding the draft document.
I forward you these comments (adding some additional comments):
6. The Roles in ENUM: The document is not consistent in the way it
talks about "ENUM DNS Provider" and "Tier 2". One should imho agree
on
one of the two names for the role of providing name servers below the
tier 1 registry.
Stastny: I would suggest to use the term ENUM DNS Provider at Tier 2
in 6. and add in 6.4:
The ENUM DNS Provider operates the ENUM Tier 2 Name Servers. (see
also below)
- 6.1.: The tier 1 registry does not in all models point directly to
the name servers holding the zones in which the NAPTR record resides.
There may be delegations in between.
It is not true that an international query will go via the home tier1
registry. It will start from the root servers down, traversing the
tier0 and the foreign tier1 registry, but in most cases it will not
touch the home tier1 registry at all. The clients are supposed to use
their provider's DNS for recursive queries, not the home tier1 DNS
(The document recommends disabling recursion on ENUM DNS servers, so
querying the home tier1 for foreign data will fail in that case!)
Stastny: Delete the second sentence, because it is wrong.
- 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.
- 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.
- 6.4.: The ENUM DNS provider not only has to host NAPTR records, but
authoritative zones for each of the delegations containing NAPTR
and other record types. He is not responsible for the content of the
NAPTR record, only for the technical aspect of hosting it.
Contentwise, the ENUM Registrant (number assignee) is repsonsible for
it's content (imho!).
Stastny: proposed text: The ENUM DNS Provider at Tier 2 will be
responsible
for the authoritative zones for each of the delegations assiciated
with
individual E.164 numbers of the particular national numbering plan
included
in the ENUM trial. This zones will be used for the storage of NAPTR
and other
record types by the ENUM End User. The ENUM end user is responsible
for the
content of these records.
Stastny: Comments on 6.6 later.
Stastny: Add to 6.7 something like this:
ENUM end users needs to be provided by the ENUM DNS Provider with an
access
to a web-base interface to allow the addition, deletion and
modification of
the (above mentioned) records in the zones associated with the
registered
E.164 numbers.
For identification and authentication userid and passwort is
sufficient.
- 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.
- 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.
There will of course be need for private information exchange between
registries and registrars, but this exchange will most probably take
place via the provisioning interface.
Additionally, i'd like to add that there has to be an interface
between registrant (number assignee) and ENUM DNS provider allowing
modification of NAPTR contents. Using an unified protocol/mechanism
would greatly increase the interopability between applications and
different ENUM DNS providers.
Stastny: see 6.7
Stastny on 10:
Comments and further input on bullet point 3 to be provided later
Last bullet point: at least one URI: We have defined in our trial,
that
the mailto: URI provided with the registration (the e-mail address
where
the confirmation is sent to) is inserted automatically in the zone,
so there
is at least one NAPTR in the zone. This record can only be modified,
but not
deleted.
- 11.: "Pointers are correctly...": I'd replace that with "ENUM
delegations at the tier 1 registry point to tier2 name servers which
must be authoritative for that zone". They do not point to NAPTR
records. It may be a quite frequent case that the domain may be empty
(besides the neccessary records [SOA, NS]) because the user has not
yet decided which service to use, but has already initiated
delegation.
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.
Basically, it may be wise to point to relevant RFC's, and extend
those recommendations/requirements with ENUM specific requirements
rather than reinvent the wheel.
Stastny: Axel provided me in the meantime with the list of RFCs:
1034
1123
2181
2182
and specific for ENUM DNS provider also 3404(obsoletes 2915) and
2916bis
also of interest 1591.
See also
http://www.denic.de/doc/rfc/ whic lists the usual suspects.
- 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).
"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).
But: DNS is a standardized protocol, so any name server providing a
correct implementation of that protocol qualifies. Some less, some
more.
In terms of code diversity, it is quite unwise to use the same
version of software on all authoritative servers for a specific zone.
- 13.2.1: "Change of ENUM DNS Provider" - this is usually called
"redelegation".
I'd add "Change of ENUM registrar" - this is usually called
"Transfer".
- 13.3: I'd add "TSP initiated cease - Registrant has cancelled his
contract with his telephony provider and therefore lost his number
assignment."
- 13.4: I'd add "Disputes because of technical issues - e.g. lame
delegations".
Sofar our first comments,
Regards
Richard Stastny
