[enum-wg] Concerning Wildcards and I-ENUM

[Otmar Lendl lendl@localhost]

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@localhost" . 

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@localhost) | nic.at Systems Engineer >