Re: [enum-wg] Concerning Wildcards and I-ENUM

[Otmar Lendl lendl@localhost]

On 2006/10/12 10:10, Antoin Verschuren <Antoin.Verschuren@localhost wrote:
> Niall O'Reilly wrote:
>  
> > % dig @ns-pri.ripe.net e164.arpa axfr \
> >   | awk '($4 == "NS") && (/^[0-9]/) { print $1 }' \
> >   | sort | uniq
> > 
> > 	Perhaps it's worth considering desirable administrative constraints
> > 	on the Tier-0 zone, in order to make some such method fornmally
> > 	(rather than accidentally) possible?

I support this idea.

> 
> This was sort of what I was thinking about, but not sure if it's a good
> idea.
> It would build further on the EBL record which was supposed to be a
> temporary solution.
> But now that we see that a demand for more ENUM space might arise, I
> wonder if it's the right path to do that in the countrycode's zone, or
> in the e164.arpa zone to allow separation of registries and their
> authorisation independent of the User ENUM registry, or perhaps in a
> complete different zone per ENUM application.

We're still trying to find a solution for alternate ENUM application
which has IMHO the following requirements:

a) Doesn't work on the user-enum domain level.

   See my last mail. Summary: that doesn't work with different block 
   delegation schemes for different ENUM applications and open numbering plans.

b) Doesn't require full IETF/ITU action for each new application. 

   That's just too slow.

c) Enables per-country opt-in.

   Each country-code should be able to decide whether to opt-in into
   a new ENUM application specific tree or not, and decide where that
   tree will be and who is going to manage it.

d) As little prior knowledge of numbering plans as possible.

e) Efficient lookup strategies.

I could not find a solutions which gets full marks on all these
requirements. Something has to give.

We can't branch at the number level. See a). That's a hard NO GO.

We can't (at least initially) use a new apex. -> b).

If we branch at the country code, we're violating d). 

Searching down the tree for an EBL (or the branch itself) violates e).

What other options are there? Branching off at a fixed digit? For
"normal" country codes, that must be at least 3 digits, though with
+87810 and other delegations like that 5 might be the better option.

For 3 digits, adding 100 EBL records in +1 isn't that much of a
penalty (e.g. for us in +43, we'd just need add 10 EBLs), but doing
it at 5 digits means 10.000 EBLs for +1. Manageable, but doesn't win
the beauty-contest, either.

I just don't see a perfect solution for this problem. The EBL is
the least bad idea we could come up with. I'm open to other
ideas on where the EBLs should be located in the user-enum tree.

> The latter would require only one lookup, where the first needs 3.
> Cashing for countrycode discovery could be quite long, as it rarely
> changes, but NS records in e164.arpa could change more often. 

Yeah, but the NS record contents are irrelevant here.

> I wonder if countrycode discovery could have another benefit for
> applications besides branche discovery. Perhaps billing (dirty word),
> legal regime, specific numberplan properties, distance calculation or
> whatever gadget they might come up with might need countrycode awareness
> anyway.

Indeed. That might be helpful for stuff like the ecrit emergency code
discovery as well.

/ol
-- 
< Otmar Lendl (lendl@localhost) | nic.at Systems Engineer >