During Robert's talk on Infrastructure ENUM in Austria I heard some harrumphes on the mentioning of us using wildcard records. While I can see that wildcards are a dangerous issue, I really doubt that we can avoid them in our setting. I've explained the issue recently to the Denic ENUM list; here is an English version of the argument: The basic premise on the Denic list was that end-users should roll out their ENUM zones instead of using wildcards (especially as the new wildcard behavior as defined by RFC4592 can lead to unexpected result due to "empty non-terminals"). In order to roll out a wildcard into individual entries you need to know the number length used within that PBX or more generally, that prefix. This is certainly a non-issue in all countries which have fixed length telephone numbers. Germany and Austria use open numbering plans, though, where e.g. PBX operators are free to devise their own schemes behind their pilot number. For user-ENUM this is not a problem, as the PBX maintainer is also the DNS admin for the ENUM zone: he knows what numbering-plan he has implemented on the PBX, he thus can generate the appropriate (non-wildcard) NAPTR records in his own ENUM zone file. Infrastructure ENUM is different, though: We (as the Registry) see only the number blocks as given from the NRA to the carriers, and not a) the length of numbers assigned to subscribers b) whatever extensions the subscribers themselves add to those numbers. Right now, PBX operators do not have to tell their carriers about extension they provision on their PBXs. They don't even have to be constant length, schemes where -9XX is the FAX box of -XX are common. The same is true for direct calls to voice-mail. In other words, the carriers themselves often don't know the length of telephone numbers within their own blocks. They just know the length of the pilot number they have give out to their customers. This, too can vary quite a bit: Consider Vienna (+43 1), where the current rules say: * "normal" number length is 7 digit. (e.g. +43 1 5056416) * Carriers usually get blocks of 10000 numbers, e.g. +43 1 236* * Customers connected via ISDN PRIs can apply for shorter number, down to 5 digits, e.g. +43 1 59966) * There are two legacy 4 digit numbers, +43 1 4177 and +43 1 4000 (University and City Hall). * In all cases customer are free to define their own extension numbers up to a total number length of 14 digits (under certain circumstances, 15 is legit as well). For the default number length in Vienna, this means e.g. +43 1 5056416 ABCD. There are now two issues: 1) Is there a way for us to learn about the length of numbers in use? 2) If not, can't we just roll out the zone anyway? ad 1): For that to happen, all PBX operators (That need not be an enterprise. A simple ISDN BRI in P2P mode is enough) need to tell their carriers about their installation and the carriers need forward that information (plus all their normal assignment info (which also can vary within a block) to us so that we can generate the proper non-wildcard records. This is extremely unlikely to happen. ad 2) consider e.g. the record *.6.3.2.1.i.3.4.e164.arpa. NAPTR 10 10 "u" "E2U+sip" "!^(.*)$!sip:\\1@enum.sil.at!" . which corresponds to +43 1 236, which is a block owned by Silverserver. This one is provisioned in our I-ENUM database as one single record. Let's assume we roll that out to cover all possible assignement: there are 4 digits Silverserver can assign and 4 more that the customer can add. This means 8 digits, thus 10^8 possible records. Shorter numbers are of course also possible, so we have to add another 10^4 + 10^5 + 10^6 + 10^7 records. A full roll-out of this one single block add thus 111 million NAPTR records to our zonefile. This is not a viable option for us. -------------- Thus: For I-ENUM in Austria, we need wildcards. Corrolary: The ENUM v2 scheme that Patrick and Olof came up with will neither solve User-ENUM vs. I-ENUM branching, nor will it be suitable for an I-ENUM deployment in a country with an open numbering plan. Please convince me that I'm wrong about this one. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer >