Subject: Re: [Enum] Summary on NoPSTN dicussion

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 25 Mar 2004 14:25:06 +0000

Stastny Richard said:
> B. use a (one, common) second common tree (e164shadow.arpa, where you put 
> in only the wildcards for the number ranges in question. The processing
> assumption now should be: 
[...]
> C. Use individual second shadow trees, eg on a national level, eg in
> Austria e164shadow.at would be used. The problem here is how one can 
> find out the domain names of the individual trees. 
> One solution is to do it with a table in each server (which is not good).
>  
> The other solution is to put pointers in e164.arpa, eg SRV RR or even MX RR. 
[...]
> Since the structure of the delegations in e164.arpa varies (Tier 1 levels),
> there is no easy way to find out the level of the pointers, even if they are
> only on the Tier 1 layer.

If the shadow tree is shadow.e164.arpa, and if the delegation rule is that
the national authority getting <N>.e164.arpa is also delegated
<N>.shadow.e164.arpa (so the UK Tier 1 operator has both 4.4.e164.arpa and
4.4.shadow.e164.arpa), doesn't that give you both B and C without needing
to create another special SLD?

Obviously, "shadow" can be replaced by something shorter if felt desirable, 
such as "w" (for "wildcards").

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Jim Reid <[email-masked]>
Date: Thu, 25 Mar 2004 15:23:35 +0000

>>>>> "Richard" == Stastny Richard <[email-masked]> writes:

    Richard> 4. Now the real problem starts: If the ENUM-query returns
    Richard> NXDOMAIN, the current assumption of all clients is: the
    Richard> call is routed to the PSTN if the server is able to do so
    Richard> (eventually with the ;enumdi set.

    Richard> The solutions proposed for this sofar are.

    Richard> A. use tables in each server.

Yes, this is unacceptable.

    Richard> B. use a (one, common) second common tree

    Richard> C. Use individual second shadow trees

B and C are ugly and evil. Alternate trees, however well intentioned,
give me the heebie-jeebies.

    Richard> D. Are there additional possibilities or proposals?

Yes. Use the additional information that's in the NXDOMAIN response.
This will include the SOA record for the zone enclosing the name that
was looked up. The name of that zone could be looked up to get a
NAPTR for a default SIP gateway or whatever. An example might clarify
this. 

Consider the non-existent phone number 1234567890.

An ENUM lookup of 0.9.8.7.6.5.4.3.2.1.e164.arpa returns NXDOMAIN. The
response includes a SOA record for 5.4.3.2.1.e164.arpa -- the
enclosing zone for this name. This will be in the Authority Section of
the reply. In other words, the name servers for 5.4.3.2.1.e164.arpa
are saying 0.9.8.7.6.5.4.3.2.1.e164.arpa doesn't exist. If I then
lookup 5.4.3.2.1.e164.arpa, this could have a NAPTR that gives me the
name of a SIP gateway that will do the Right Thing for 1234567890.

There's no need for wildcards or shadow tree ickiness. And it's nice
and clean for things like 800 and 900 numbers or DDI blocks. Calls to
these numbers will get shunted to the right "gateway". This does of
course make things a little bit trickier for a Tier-1 registry that
delegates every individual E.164 number.

BTW, what about NODATA responses from the DNS? ie The name exists, but
not as the QTYPE (NAPTR?) that was requested....

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 25 Mar 2004 16:45:07 +0100

Hi Jim,
let me see if I understand you proposal (I am not a DNS expert, sorry),
and if it works how it is intended. This may solve some other problems, too.

> delegates every individual E.164 number.
[Richard>] 
If I want to have a spezial policy for a number block, I put in a NAPTR
In the zone delegating the numbers to the next tier. This could either
be a default gateway as requested or a VOID NAPTR (for discussions sake)

So if a client gets a NXDOMAIN, he just has to do another lookup to
The domain returned in the SOA. If again no NAPTR is returned, another
SOA is return from the next higher zone. So he queries here for NAPTR.
So this can even be nested from bottom up. This is very nice, because
it would also solve the DDI and switchboard problem with PBX.
> not as the QTYPE (NAPTR?) that was requested....
[Richard>] 
Could you please elaborate, I do not understand this.

Regards
Richard

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 25 Mar 2004 18:30:20 +0100

> NAPTR for a default SIP gateway or whatever. An example might clarify

Jim,

this is a cute idea, especially for DDI on PBXes. For 800 numbers,
this could be a replacement for freenum.org.

I see issues (not showstoppers) with it, though:

* I'm not sure whether the current resolver libraries are designed
to pass additional information returned in an error response back to
the calling application. The typical gethostbyname - type functions
certainly don't. I haven't seen a standardised API to NAPTR
queries yet (all the code I have seen (asterisk, ser) by now does
manual response parsing -- yuck.), maybe you're early enough to
get this added.

* The scheme only works on zone boundaries. If we (as 3.4.e164.arpa Tier1)
were to implement this on +43780 (which is under discussion as ENUM-only
number range) we would have to delegate 0.8.7.3.4.e164.arpa to ourselves
first, and then delegate individual numbers from within that zone.

That violates our basic assumption that all delegation from the Tier1
will be within the 3.4.e164.arpa zone. Yes, one can program around
that, but it certainly won't make things easier for us.

> not as the QTYPE (NAPTR?) that was requested....

ditto with SRVFAIL. 

/ol
-- 
< Otmar Lendl ([email-masked]) | nic.at Systems Engineer >

---

From: Jim Reid <[email-masked]>
Date: Thu, 25 Mar 2004 17:36:57 +0000

>>  Yes. Use the additional information that's in the NXDOMAIN
    >> response.  This will include the SOA record for the zone
    >> enclosing the name that was looked up. The name of that zone
    >> could be looked up to get a NAPTR for a default SIP gateway or
    >> whatever. An example might clarify this.
    >> 
    >> An ENUM lookup of 0.9.8.7.6.5.4.3.2.1.e164.arpa returns
    >> NXDOMAIN. The response includes a SOA record for
    >> 5.4.3.2.1.e164.arpa -- the enclosing zone for this name. This
    >> will be in the Authority Section of the reply. In other words,
    >> the name servers for 5.4.3.2.1.e164.arpa are saying
    >> 0.9.8.7.6.5.4.3.2.1.e164.arpa doesn't exist. If I then lookup
    >> 5.4.3.2.1.e164.arpa, this could have a NAPTR that gives me the
    >> There's no need for wildcards or shadow tree ickiness. And it's
    >> nice and clean for things like 800 and 900 numbers or DDI
    >> blocks. Calls to these numbers will get shunted to the right
    >> "gateway". This does of course make things a little bit
    >> trickier for a Tier-1 registry that delegates every individual
    >> E.164 number.

    Richard> So if a client gets a NXDOMAIN, he just has to do another
    Richard> lookup to The domain returned in the SOA.

Yes, but he *doesn't* have to do this. He should of course, but...

    Richard> If again no NAPTR is returned, another SOA is return from
    Richard> the next higher zone. So he queries here for NAPTR.

Nope! The SOA record is returned for the closest enclosing zone: the
delegation point. Let's take the example above. I get an NXDOMAIN when
looking up 0.9.8.7.6.5.4.3.2.1.e164.arpa. The SOA record for the
nearest delegation point, 5.4.3.2.1.e164.arpa, is returned in that
response. So I now look for a NAPTR (say) for 5.4.3.2.1.e164.arpa. If
this doesn't exist, I get an NXDOMAIN back. This time the *same* SOA
record will be returned because the 5.4.3.2.1.e164.arpa zone is the
nearest delegation point to 5.4.3.2.1.e164.arpa.

Now, I suppose an (idiot) application could walk up the tree, trying
4.3.2.1.e164.arpa, 3.2.1.e164.arpa, etc looking for the next highest
delegation point and hypothetical default NAPTR. But this is ugly and
should be avoided. Imagine the implications for a 10-12 digit phone
number.

    >>  BTW, what about NODATA responses from the DNS? ie The name
    >> exists, but not as the QTYPE (NAPTR?) that was requested....

    Richard> [Richard>] Could you please elaborate, I do not
    Richard> understand this.

Sure. Suppose I ask for NAPTRs for 0.9.8.7.6.5.4.3.2.1.e164.arpa.
There aren't any. But the name has a TXT record. Or an MX record.
Or... In this case, the server returns a NODATA response. The Answer
Section is empty, but the reply's status field is NOERROR, not
NXDOMAIN. The name 0.9.8.7.6.5.4.3.2.1.e164.arpa exists, but not as
the QTYPE -- NAPTR in this example -- that was looked up. This corner
case may need to be covered. There's nothing in RFC2916(bis) that says
only NAPTR records can exist as leaf nodes of e164.arpa. Clients
must/should be prepared to handle any legal resource records that
could get returned.

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 25 Mar 2004 18:48:26 +0100

> must/should be prepared to handle any legal resource records that

Even if there are NAPTR records, you still might not get a NAPTR with
enumservice for voice. My guess is that you should handle both cases
in the same way.

/ol

---

From: "Samia M'timet" <[email-masked]>
Date: Thu, 25 Mar 2004 17:08:58 +0100

On Thu, 25 Mar 2004 15:23:35 +0000

> delegates every individual E.164 number.

==> This is the option we followed for the User-ENUM french trial : we stuck at the *real* numbering resources allocation. At Tier-1 registry we delegate blocks of E.164 numbers as they are in the real numbering plan.

Consequences :

- no "validation" problems 

- no need for a ".tel" alternative root for Infrastructure-ENUM

-- 
Samia M'timet				
AFNIC

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 25 Mar 2004 22:19:54 +0100

IA0KDQoJDQoNCgk+ICAgIFJpY2hhcmQ+IFNvIGlmIGEgY2xpZW50IGdldHMgYSBOWERPTUFJTiwgaGUganVzdCBoYXMgdG8gZG8gYW5vdGhlcg0KCT4gICAgUmljaGFyZD4gbG9va3VwIHRvIFRoZSBkb21haW4gcmV0dXJuZWQgaW4gdGhlIFNPQS4NCgkNCgk+IFllcywgYnV0IGhlICpkb2Vzbid0KiBoYXZlIHRvIGRvIHRoaXMuIEhlIHNob3VsZCBvZiBjb3Vyc2UsIGJ1dC4uLg0KCSANCglJIHRoaW5rIHdlIHNob3VsZCBmaW5hbGx5IHdyaXRlIGhpcyB1cCBzb21ld2hlcmUNCgkNCgk+ICAgIFJpY2hhcmQ+IElmIGFnYWluIG5vIE5BUFRSIGlzIHJldHVybmVkLCBhbm90aGVyIFNPQSBpcyByZXR1cm4gZnJvbQ0KCT4gICAgUmljaGFyZD4gdGhlIG5leHQgaGlnaGVyIHpvbmUuIFNvIGhlIHF1ZXJpZXMgaGVyZSBmb3IgTkFQVFIuDQoJDQoJPk5vcGUhIFRoZSBTT0EgcmVjb3JkIGlzIHJldHVybmVkIGZvciB0aGUgY2xvc2VzdCBlbmNsb3Npbmcgem9uZTogdGhlDQoJPmRlbGVnYXRpb24gcG9pbnQuIExldCdzIHRha2UgdGhlIGV4YW1wbGUgYWJvdmUuIEkgZ2V0IGFuIE5YRE9NQUlOIHdoZW4NCgk+bG9va2luZyB1cCAwLjkuOC43LjYuNS40LjMuMi4xLmUxNjQuYXJwYS4gVGhlIFNPQSByZWNvcmQgZm9yIHRoZQ0KCT5uZWFyZXN0IGRlbGVnYXRpb24gcG9pbnQsIDUuNC4zLjIuMS5lMTY0LmFycGEsIGlzIHJldHVybmVkIGluIHRoYXQNCgk+cmVzcG9uc2UuIFNvIEkgbm93IGxvb2sgZm9yIGEgTkFQVFIgKHNheSkgZm9yIDUuNC4zLjIuMS5lMTY0LmFycGEuIElmDQoJPnRoaXMgZG9lc24ndCBleGlzdCwgSSBnZXQgYW4gTlhET01BSU4gYmFjay4gVGhpcyB0aW1lIHRoZSAqc2FtZSogU09BDQoJPnJlY29yZCB3aWxsIGJlIHJldHVybmVkIGJlY2F1c2UgdGhlIDUuNC4zLjIuMS5lMTY0LmFycGEgem9uZSBpcyB0aGUNCgk+bmVhcmVzdCBkZWxlZ2F0aW9uIHBvaW50IHRvIDUuNC4zLjIuMS5lMTY0LmFycGEuDQoJDQoJPk5vdywgSSBzdXBwb3NlIGFuIChpZGlvdCkgYXBwbGljYXRpb24gY291bGQgd2FsayB1cCB0aGUgdHJlZSwgdHJ5aW5nDQoJPjQuMy4yLjEuZTE2NC5hcnBhLCAzLjIuMS5lMTY0LmFycGEsIGV0YyBsb29raW5nIGZvciB0aGUgbmV4dCBoaWdoZXN0DQoJPmRlbGVnYXRpb24gcG9pbnQgYW5kIGh5cG90aGV0aWNhbCBkZWZhdWx0IE5BUFRSLiBCdXQgdGhpcyBpcyB1Z2x5IGFuZA0KCT5zaG91bGQgYmUgYXZvaWRlZC4gSW1hZ2luZSB0aGUgaW1wbGljYXRpb25zIGZvciBhIDEwLTEyIGRpZ2l0IHBob25lDQoJPm51bWJlci4NCgkgDQoJSWYgIEkgdW5kZXJzdGFuZCBpdCBjb3JyZWN0bHkseW91IHdvdWxkbnQgaGF2ZSB0byBnbyB1cCBkaWdpdCBwZXIgZGlnaXQuDQoJSWYgeW91IGhhdmUgYSBkZWxlZ2F0aW9uIHBvaW50IGF0IDIuMS5lMTY0LmFycGEgYW5kDQoJYW5vdGhlciBvbmUgYnkgNS40LjMuMi4xLmUxNjQuYXJwYSANCgkgDQoJeW91IHF1ZXJ5IGZvciA1LjQuMy4yLjEuZTE2NC5hcnBhIGFuZCBnZXQgYWdhaW4gTlhET01BSU4gd2l0aCBTT0EgNS40LjMuMi4xLmUxNjQuYXJwYQ0KCXNvIHlvdSBxdWVyeSBmb3IgNC4zLjIuMS5lMTY0LmFycGEgYW5kIGdldCBOWERPTUFJTiB3aXRoIFNPQSAyLjEuZTE2NC5hcnBhDQoJc28gSSBxdWVyeSBub3cgZm9yIDIuMS5lMTY0LmFycGENCglvciBkaWQgSSBnZXQgc29tZXRoaW5nIHdyb25nDQoJDQoJICAgID4+ICBCVFcsIHdoYXQgYWJvdXQgTk9EQVRBIHJlc3BvbnNlcyBmcm9tIHRoZSBETlM/IGllIFRoZSBuYW1lDQoJICAgID4+IGV4aXN0cywgYnV0IG5vdCBhcyB0aGUgUVRZUEUgKE5BUFRSPykgdGhhdCB3YXMgcmVxdWVzdGVkLi4uLg0KCQ0KCSAgICBSaWNoYXJkPiBbUmljaGFyZD5dIENvdWxkIHlvdSBwbGVhc2UgZWxhYm9yYXRlLCBJIGRvIG5vdA0KCSAgICBSaWNoYXJkPiB1bmRlcnN0YW5kIHRoaXMuDQoJDQoJPlN1cmUuIFN1cHBvc2UgSSBhc2sgZm9yIE5BUFRScyBmb3IgMC45LjguNy42LjUuNC4zLjIuMS5lMTY0LmFycGEuDQoJPlRoZXJlIGFyZW4ndCBhbnkuIEJ1dCB0aGUgbmFtZSBoYXMgYSBUWFQgcmVjb3JkLiBPciBhbiBNWCByZWNvcmQuDQoJPk9yLi4uIEluIHRoaXMgY2FzZSwgdGhlIHNlcnZlciByZXR1cm5zIGEgTk9EQVRBIHJlc3BvbnNlLiBUaGUgQW5zd2VyDQoJPlNlY3Rpb24gaXMgZW1wdHksIGJ1dCB0aGUgcmVwbHkncyBzdGF0dXMgZmllbGQgaXMgTk9FUlJPUiwgbm90DQoJPk5YRE9NQUlOLiBUaGUgbmFtZSAwLjkuOC43LjYuNS40LjMuMi4xLmUxNjQuYXJwYSBleGlzdHMsIGJ1dCBub3QgYXMNCgk+dGhlIFFUWVBFIC0tIE5BUFRSIGluIHRoaXMgZXhhbXBsZSAtLSB0aGF0IHdhcyBsb29rZWQgdXAuIFRoaXMgY29ybmVyDQoJPmNhc2UgbWF5IG5lZWQgdG8gYmUgY292ZXJlZC4gVGhlcmUncyBub3RoaW5nIGluIFJGQzI5MTYoYmlzKSB0aGF0IHNheXMNCgk+b25seSBOQVBUUiByZWNvcmRzIGNhbiBleGlzdCBhcyBsZWFmIG5vZGVzIG9mIGUxNjQuYXJwYS4gQ2xpZW50cw0KCT5tdXN0L3Nob3VsZCBiZSBwcmVwYXJlZCB0byBoYW5kbGUgYW55IGxlZ2FsIHJlc291cmNlIHJlY29yZHMgdGhhdA0KCT5jb3VsZCBnZXQgcmV0dXJuZWQuDQoJIA0KCW9rLiBCVFcgd2UgaGF2ZSBUWFQgcmVjb3JkcywgYnV0IG5vdCB3aXRob3V0IE5BUFRScy4NCgkgDQoJUmljaGFyZA0KCQ0KDQo=_______________________________________________enum mailing [email-masked]://www1.ietf.org/mailman/listinfo/enum

---

From: Jim Reid <[email-masked]>
Date: Thu, 25 Mar 2004 22:42:33 +0000

>>>>> "Richard" == Stastny Richard <[email-masked]> writes:

    Richard> 	I think we should finally write his up somewhere

Yes, I agree. A draft on resolver behaviour for ENUM applications is
needed. This might lead on to documenting and recommending an API for
ENUM-aware applications. Another follow-on could be something about a
standard naming convention for the default "whatever" -- SIP gateway,
web server, etc -- for some delegation point. This is a bit like the
idea the RIPE DNS WG had for locating whois servers with SRV records.
	
    >> Now, I suppose an (idiot) application could walk up the tree,
    >> trying 4.3.2.1.e164.arpa, 3.2.1.e164.arpa, etc looking for the
    >> next highest delegation point and hypothetical default
    >> NAPTR. But this is ugly and should be avoided. Imagine the
    >> implications for a 10-12 digit phone number.
	 
    Richard> 	If I understand it correctly,you wouldnt have to go up
    Richard> digit per digit.  If you have a delegation point at
    Richard> 2.1.e164.arpa and another one by 5.4.3.2.1.e164.arpa

Yes. But it would be less offensive to go down the tree and get the
actual delegation points than go upwards trying to guess where they
are. A downwards traversal of the tree is how DNS works anyway. And
name servers will be caching the delegation info as they're resolving
queries. So the name servers should already know where delegations
occur without having to guess where they might be.

---

From: Jeff Williams <[email-masked]>
Date: Thu, 25 Mar 2004 18:34:53 -0800

Clive and all,

> to create another special SLD?

  I think it does, yes. Nicely illustrated..

> such as "w" (for "wildcards").

  Ah yes!  Good point here as well...  But Harald wont agree or like
it anyway...  :/

Regards,
--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail [email-masked]
 Registered Email addr with the USPS
Contact Number: 214-244-4827

---

From: Marian Durkovic <[email-masked]>
Date: Fri, 26 Mar 2004 09:38:43 +0100

Jim,

   how would you like to do that? Going up the tree is easy - the authority
section will give you the information about the current delegation zone, so
you only need 1 query per delegation, as Richard pointed out.

   But there's no query to learn the delegation downwards...

        With kind regards,

--------------------------------------------------------------------------
----                                                                  ----
----   Marian Durkovic                       network  manager         ----
----                                                                  ----
----   Slovak Technical University           Tel: +421 2 524 51 301   ----
----   Computer Centre, Nam. Slobody 17      Fax: +421 2 524 94 351   ----
----   812 43 Bratislava, Slovak Republic    E-mail/sip: [email-masked]    ----
----                                                                  ----
--------------------------------------------------------------------------

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 25 Mar 2004 13:08:20 +0100

Dear colleagues,

There was a lot of discussions on-list and off-list on this issue,
so I will try to summarize at least my view of the problem.
I will also include my current view on the ;enumdi
and the ;pstn indicator for the tel: URI

ENUM-enabled UAs and Servers are currently processing 
received E.164 numbers (either in a tel:+xxx URI or in a sip: URI
in the format sip:[email-masked];user=phone) in the following way:
(for simplicity I am only dealing with voice calls)
Please holler if I got something wrong or you disagree

1. Query ENUM (in e164.arpa)

2. if a NAPTR is found with an "enumservice" sip or voice:sip,
handle the call as if you have received a sip: URI in the format
sip:[email-masked] in the first place.

3. If a NAPTR is found with an "enumservice" voice:tel
3a. and the tel: URI is pointing to a different number,
query ENUM again for this number
3b. if the tel: URI is the same as the AUS, forward the
call to the PSTN, if you are able to do so.

Note: here the proposed ;pstn indicator may come in handy:
In 3a you may use it in the NAPTR to prevent a second ENUM-query
and force the call to the PSTN.
In 3b the server may add ;pstn to inform the next proxy about
The decision to force the call to the PSTN. On the other hand,
In this case also the ;enumdi indicator may be used just to prevent
an ENUM query. Result: ;pstn is used in ENUM - ;enumdi is used in 
signalling.

4. Now the real problem starts: If the ENUM-query returns NXDOMAIN,
the current assumption of all clients is: the call is routed to the
PSTN if the server is able to do so (eventually with the ;enumdi set.

This means, we refer the problem to the PSTN. This is not nice for
various reasons:
1. we are bothering the PSTN in some cases unnecessarily 
2. the PSTN may not know what to do either and bounce the
call back, which is creating loops
3. and finally: what are we doing if there is no PSTN anymore ;-)
Ok, this seems far reached, but Internet Telephony should be finally 
self-containing.

So what are the additional policies we may want to tell an ENUM-
client?

1. No such number (unassigned number)
1a. The whole number range (number block)is unassigned
1b. There are numbers assigned in this number range, but if you
do not find one in ENUM, you also will not find one on the PSTN, so
it makes no sense to route it to the PSTN (ENUM-only)
2. Default routing for the whole number range (number block) to a VoIP
gateway.
2a. The whole block is routed, there are no individual entries in ENUM
(e.g. 1-800 numbers)
2b. There are numbers in ENUM, but if you do not find an entry, route
the call to the default gateway given. One example for this case may be
a VoIP provider operating an island only connected to the PSTN. Some
of the users are also in ENUM (opt-in). If he provider now opens up access
to the Internet via a gateway (border element, ...), he may want to route
all calls for his users not in ENUM to the gateway provided by default

Case 1a and 2a can be dealt with in e164.arpa with wildcards, because no
Additional entries below exist.
Case 1b and 2b cannot be dealt within e164.arpa, because wildcards do
not support this.

The solutions proposed for this sofar are.

A. use tables in each server. This is not a good idea and does not help
ENUM-enable UA. The information should be stored in a global accessible and public database (DNS).

If the ENUM-query returns NXDOMAIN, the call is not routed to the PSTN
In any case, the server queries e164shadow.arpa, and only if no entry
is found there, the call is routed to the PSTN. The management and
delegation procedures of the tree are the same as for e164.arpa.
The second tree would contain only wildcard NAPTR RR for number ranges

This would be the optimal solution proposed sofar. The problem is that
a common agreement and a definition on the second tree is necessary.

The other solution is to put pointers in e164.arpa, eg SRV RR or even MX RR. 
The MX record would give eg the root of the other tree, and each tree
would be structured in the sane way like e164.arpa, so the same algorithms
can be used.

It was proposed to search either top down (faster) or bottom up (more 
flexible), because this would allow sub-policies in number ranges.

D. Are there additional possibilities or proposals?

Finally I come to the last issue:

For case 1a and 1b above (no such number) an "enumservice" is necessary
to indicate that there exists no such number, neither in ENUM nor on the
PSTN.

Proposals sofar are:

Use a special flag e.g. "n" or "v"
Use a "enumservice" e.g. "E2U+NONE" or "E2U+VOID" or only "VOID"

Also here additional proposals are invited.

Best regards

Richard