<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

ETSI on Minimum Requirements for European ENUM Trials


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

<<< Chronological >>> Author    Subject <<< Threads >>>