Subject: [Enum] New Enumservice NoPSTN?

From: "Stastny Richard" <[email-masked]>
Date: Mon, 22 Mar 2004 12:18:57 +0100

Working currently on the draft for the enum-dip-indicator for the tel:
URI, as discussed on the IPTEL-list, and also thinking about the
pstn-indicator, as discussed recently on the SIPPING-list, I encoutered
the following minor problem.

An ENUM client (e.g. in a SIP server) currently works in the following
way:

If it gets an E.164 number in, it is querying the domain e164.arpa
related to this number in the DNS for NAPTR, and if he get a result back
(one or more NAPTRs), fine. 

If there is no domain related to this number in the DNS, there is
currently the intrinsic assumption, that the number may exist on the
PSTN or at least the PSTN finally knows that the number does not exist.
So the call may be routed to the PSTN if the SIP-server is able to do
so.

For ENUM-only number ranges we have a problem here. ENUM-only number
ranges exist only in the DNS. The PSTN is recognizing the number range
as ENUM-only, so any call originating on the PSTN is routed to a gateway
capable of doing an ENUM query. If such a gateway is not finding an
entry for the specific number, he should have a logic built in not to
route the call back to the PSTN, but to signal this fact back to the
user (e.g. SIT). 

If the above mentioned SIP-server is querying an ENUM-only number range,
finding no entry, routing the call to the PSTN, the call is finally
routed to an ENUM-enable gateway by the PSTN and properly treated.

So this is a minor problem, but it is not nice to bother the PSTN or
even to need it to properly treat a call originating on the Internet.

There are two solutions coming to my mind:

A. Populate the DNS for this number range with all numbers possible, and
enter a proper default NAPTR
B: use a wildcard for the whole number range

But both solutions raise the question how the NAPTR record finally
should look like.

One solution could be to use the ENUMservice "ann" (as defined in ETSI
TS 102 072), but this service is more intented for end-user information
and may be also in addition to other enumservices. Furthermore this
enumservice has until know not even been discussed at IETF.

Another solution could be to define an enumservice "nopstn", "noentry"
or "void". The question here is which URI should be used to keep the
syntax?

One way could be to use http://.....html and point to a web-page, where
the entity responsible for the number range places some text.

On the other hand, SIP-servers or any other application querying ENUM
could immediately recognize that there is no such number.

What is the opinion of the group and are there any additional proposals?

Is this the group where this should be discussed and/or in IPTEL or
SIPPING?

regards

Richard Stastny
OeFEG
+43 664 420 4100

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

---

From: Richard Shockey <[email-masked]>
Date: Mon, 22 Mar 2004 15:56:37 -0500

A
>(one or more NAPTRs), fine.

its done ... it substitutes the SIP URI in the To: field and proceeds to 
create a session

>So the call may be routed to the PSTN if the SIP-server is able to do

Well it depends on network topology ..if the 1 hop edge SIP proxy executes 
a query and gets a 404 that would indicate a default condition of PSTN 
routing and IMHO the TEL URI needs to be modified to indicate that a ENUM 
query has been made.

>ranges exist only in the DNS.

You mean E.164 numbers that cannot be routed on the PSTN

>The PSTN is recognizing the number range

OK ..no problem

Spell this out not everyone knows what SIT tones means though I have put 
them on my answering machine to stop predictive dialers... ( the tone 
generated by the switch when the number is unreachable . usually used in 
number disconnect situations.)

>routed to an ENUM-enable gateway by the PSTN and properly treated.

Well here is where you seem to be losing me . if it is a ENUM only range 
and the 1st hop proxy gets a 404 .. it insert the dip indicator...then pass 
to the PSTN..
Unless the 1st hop proxy has knowledge of ENUM number ranges locally and 
can interpret a 404 as call failure and not attempt to pass the call across.

>even to need it to properly treat a call originating on the Internet.

OK I get it .. the PSTN carriers do not want to be bothered by trying to 
route calls from IP only number ranges ..both situations would create 
failure ( SIT) but the latter is unecessary.

>enter a proper default NAPTR

Never going to happen ...

>B: use a wildcard for the whole number range

not going to happen either...

>But both solutions raise the question how the NAPTR record finally

Well

>or "void". The question here is which URI should be used to keep the

I'm still not clear why these error conditions in SIP cannot be dealt with 
with extensions to the tel URL or why local edge proxy's cannot be made 
aware of ENUM number ranges in order to prevent necessary PSTN call routing.

This is a interesting case in ENUM bahaivor that should be documented ..but 
I'd rather see decision trees like this one dealt with at the edge and not 
higher up the network.

>the entity responsible for the number range places some text.

huh?

>Is this the group where this should be discussed and/or in IPTEL or

Well IMHO probably IPTEL but it has relevance here...

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:[email-masked]
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: "Tim Ruiz" <[email-masked]>
Date: Mon, 22 Mar 2004 16:31:12 -0600

Richard,

I follow this list with interest. I feel less than qualified to participate
much but I've been learning a lot.

Recently a set of new sTLD applications were posted publicly by ICANN at: 

http://www.icann.org/announcements/announcement-19mar04.htm

I found the .MOBI and .TEL applications of particular interest, especially
the .TEL application from pulver.com:

http://www.icann.org/tlds/stld-apps-19mar04/tel-pulver.htm

I was wondering if you have had a chance to look at that. It appears to my
less qualified eye that it would conflict with ENUM. Where you aware of it?
Is my reading of it correct?

Tim Ruiz
Go Daddy Software, Inc.

---

From: Marian Durkovic <[email-masked]>
Date: Tue, 23 Mar 2004 08:58:52 +0100

> aware of ENUM number ranges in order to prevent necessary PSTN call routing.

Well, since ENUM-only ranges are to be expected under several country codes
and also globally (like +87810) it's not feasible to put all those ranges
statically into _every_ SIP proxy around the globe.

Anyway, this problem again rises the question about "smart" wildcards in
ENUM. I think it's not possible to populate every unused number under
ENUM-only range with some record, since we'll end up with billions of
records, and we still don't catch every possible misdialing - users
can dial anything (incomplete number, wrong number, too long number etc.):

+87810 12
+87810 1115553  or even
+87810 1235671253652635172536153267156215367215312527651352167

Instead, we need to look for a solution, which allows the "default route"
in ENUM, i.e. how to route all numbers under some prefix not having explicit
NAPTR record to this "default" route. In other words, we need "smart"
wildcard - i.e. the wildcard which will _not_ depend on presence/absence of
other records. This will also be of high benefit for DDI ranges and all 
the like.

	With kind regards,

		M.

--------------------------------------------------------------------------
----                                                                  ----
----   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: "Conroy, Lawrence (SMTP)" <[email-masked]>
Date: Tue, 23 Mar 2004 10:27:14 +0000

Hi Folks,
   at the risk of going way off-topic for ENUM (I haven't seen all of 
the messages quoted ?):

Note: before anyone jumps in to complain that wildcards are ALWAYS a 
bad idea,
       please spell out for idiots such as myself why it won't work in 
this situation.
       (i.e. not that it is difficult or acts in an unexpected way, but 
exactly what
       it does that is not what's required here).

(i)  This comes about due to some implicit assumptions that are outside 
the protocol.
  -   Specifically, what to do if there is no ENUM domain for a given 
E.164 number.
      Most of the time, dumping to the PSTN works, but this *is* an 
ASSUMPTION and
      is broken in some cases. The protocol is fine, the assumption may 
not be.
(ii) I don't understand what's so smart about the proposed wildcard at 
the apex of
      an "ENUM-only" number range (i.e. in a Tier 1 server).
      It comes up again and again, but I *had* thought that with a 
standard wildcard,
      if there's a delegation for a queried leaf sub-domain (i.e. there 
*is* an ENUM-only
      number) then that will get returned, else the wildcard will be 
returned.
      The only time that you'll have a problem is if there is ANY 
intermediary RR under
      the wildcard (so delegating for a subsidiary block is out, or at 
least there must
      be another wildcard "under" that block). So... what's smart about 
this wildcard?

all the best,
   Lawrence

On 23 Mar 2004, at 7:58 am, Marian Durkovic wrote:
<snip>

---

From: Jim Reid <[email-masked]>
Date: Tue, 23 Mar 2004 18:56:15 +0000

>>>>> "Tim" == Tim Ruiz <[email-masked]> writes:

    Tim> http://www.icann.org/announcements/announcement-19mar04.htm

    Tim> I found the .MOBI and .TEL applications of particular
    Tim> interest, especially the .TEL application from pulver.com:

    Tim> http://www.icann.org/tlds/stld-apps-19mar04/tel-pulver.htm

    Tim> I was wondering if you have had a chance to look at that. It
    Tim> appears to my less qualified eye that it would conflict with
    Tim> ENUM.  Is my reading of it correct?

Yes. It doesn't conflict with ENUM: the proposal merely copies the
ENUM name space under .tel instead of 164.arpa. Therefore it doesn't
offer anything new. And IMO, for that reason alone ICANN should reject
this application out of hand. If anything, the proposal is worse than
e164.arpa because there appear to be none of the necessary safeguards
that already apply to the e164.arpa tree.

If this TLD was created, then there would be all sorts of conflicts
such as confusion with the ENUM tree. [Where is your phone number
registered, .tel or .e164.arpa? And if it's both, which one is right?]
This is just a re-run of the "golden tree" rationale which has been
understood and generally accepted. Other nasties that lurk in this
proposed .tel concern national sovereignty. It's up to a government,
not Pulver, what gets done to its E.164 resources. Governments and
regulators are also likely to be concerned about things like consumer
protection, data privacy, slamming, hijacking, competition policy,
transparency, etc, etc.

---

From: Jim Reid <[email-masked]>
Date: Tue, 23 Mar 2004 20:00:14 +0000

>>>>> "Marian" == Marian Durkovic <[email-masked]> writes:

    Marian> Anyway, this problem again rises the question about
    Marian> "smart" wildcards in ENUM. I think it's not possible to
    Marian> populate every unused number under ENUM-only range with
    Marian> some record, since we'll end up with billions of records,
    Marian> and we still don't catch every possible misdialing - users
    Marian> can dial anything (incomplete number, wrong number, too
    Marian> long number etc.):

Oh please, not yet another salespitch for wildcard RRs! :-(

There's absolutely no need to add resource records for non-existent
domain names (numbers). [Which is an impossibility in the DNS, but put
that to one side.] This is how the DNS works today. And it works just
fine.

An application is free to lookup whatever.it.likes.e164.arpa. If this
name exists, the application presumably gets back some valid NAPTR
records and all is good. If the name doesn't exist, the DNS returns an
NXDOMAIN. The application can then decide for itself what it should do
next. It could apply a default rule such as "route a call for this
number to SIP gateway foo" or report an error like "ENUM doesn't
recognise this number". ie the rule is in the application where it
belongs, not the DNS.

As for misdialling, so what? Why should an ENUM lookup for a broken
number be expected to work? [For some definition of "work".] Surely,
these should fail in essentially the same way as a misdialled or
invalid number on the PSTN?

    Marian> Instead, we need to look for a solution, which allows the
    Marian> "default route" in ENUM, i.e. how to route all numbers
    Marian> under some prefix not having explicit NAPTR record to this
    Marian> "default" route. In other words, we need "smart" wildcard

The juxtaposition of "smart" and "wildcard" in the context of DNS is
an oxymoron. :-) Have you forgotten the furore when Verisign put a
wildcard A record in .com which pointed at their sitefinder website?
This broke huge chunks of the internet. Wildcard RRs in e164.arpa are
likely to have comparable unpleasant consequences once ENUM systems
are widely deployed.

    Marian> - i.e. the wildcard which will _not_ depend on
    Marian> presence/absence of other records. This will also be of
    Marian> high benefit for DDI ranges and all the like.

Such a wildcard, if it could be created, would contradict the way the
world's name servers and the DNS protocol works today. A wildcard in
the DNS is only matched if the name being looked up does not exist as
*any* record type. In other words, it depends on the presence or
absence of other resource records. That won't change without a rewrite
of RFC103[45] and a very long period of migration. Good luck getting
that through IETF!

BTW, the excellent IAB statement on DNS wildcard RRs should be
mandatory reading for anyone thinking about deploying them. It's at:

	http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html

---

From: RJ Auburn <[email-masked]>
Date: Tue, 23 Mar 2004 12:41:20 -0800

I would also like to understand a bit more about some of the concerns 
of using wild card records in enum tree's.

Lets use the example where I own a complete range of numbers (lets use 
+1-555-666-1xxx as an example) and I want everything to end up on my 
sip server located at sip.voxeo.net. With wild cards this is very easy 
to do with the following record:

1.6.6.6.5.5.5.1.e164.arpa. NAPTR   0 0 "u" "E2U+sip" 
"!^(.*)$!sip:\[email-masked]!" .

Without wild card records I would end up having to have 1000 records 
and they must each be a maintained and updated individually. For large 
companies that may want all their calls routed to a single proxy server 
I can see this being  a major pain to keep updated.

What do folks think of this? As a service provider that manages ten's 
of thousands of phone numbers I really would like to have something 
that does not require me to maintain that many records.

Is there another way to do this that works better? If so I would love 
to hear about it.

	RJ

---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800

On Mar 23, 2004, at 02:27, Conroy, Lawrence (SMTP) wrote:

> (i)  This comes about due to some implicit assumptions that are 
> outside the protocol.

---

From: Jeff Williams <[email-masked]>
Date: Tue, 23 Mar 2004 22:18:55 -0800

Jim and all,

  Sitefinder didn't break anything.  Wildcard entries for DNS are widely
desired and utilized.  Haralds take is not broadly shared despite the
IAB's endorsement.  The Wildcard argument raged several times
before on other forum's fora.  The gospel according to Harald/IAB
is only one book in the ongoing development of the DNS Bible...

>         http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html

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: Jeff Williams <[email-masked]>
Date: Tue, 23 Mar 2004 22:25:51 -0800

RJ and all,

> "!^(.*)$!sip:\[email-masked]!" .

  Good approach...

> I can see this being  a major pain to keep updated.

 Not only a pain but also prone to error making or other errors that
would likely go unnoticed or denied for some time before corrected..

> Is there another way to do this that works better? If so I would love

  I would also...  Ask Harald!  >;)  And good luck with whatever answer
he MAY provide...

Regards,

---

From: Marian Durkovic <[email-masked]>
Date: Wed, 24 Mar 2004 10:44:06 +0100

> of using wild card records in enum tree's.

The basic problem is that wildcard records work fine _only_ in case there's
no other record present in the zone. You can't do something like this

1.1.1.1         IN NAPTR ......
*               IN NAPTR ......

because the 1.1.1.1 record blocks also anything.1.1.1, anything.1.1 and 
anything.1 The result is, that query for 2.2.2.1 returns NXDOMAIN
and not the wildcard as you would perhaps expect.  
See the section 4.3.3 of RFC1034 for details.

The other problem mentioned here was that wildcards match anything, which is
not always desired, however this could be easily avoided by using smart
regexpr field - for example in our DDI ranges we now use a modified regexpr
syntax:

$ORIGIN 6.9.2.7.5.2.1.2.4.e164.arpa.
* IN  NAPTR 100 10 "u" "E2U+sip" "!^\\+421257296(...)$!sip:2\\[email-masked]!" .

and this regexpr only matches _exactly_ 3 digits of PBX extension - so any
misdialed numbers with incorrect legth are disallowed.

So - if you want to use wildcards:

1) don't place anything else in the zone
2) formulate the regexpr precisely in order to exactly match your needs.

Also note, that the solution for use of wildcards in DNS SEC is not (yet?)
known.  

> that does not require me to maintain that many records.

I fully share your view and that's why we're using wildcards here.

	With kind regards,

		M.

----   Marian Durkovic                       network  manager         ----
----                                                                  ----

---

From: Marian Durkovic <[email-masked]>
Date: Wed, 24 Mar 2004 11:54:56 +0100

On Tue, Mar 23, 2004 at 08:00:14PM +0000, Jim Reid wrote:
> domain names (numbers).

Well, as Richard pointed out, there probably _is_ a need to do that - in case
you want to influence the default behaviour encoded in applications.

For ENUM-only range, there's no routing information in the PSTN, and the
only usable info is in the ENUM tree. If application applies the 
default behaviour of routing all NXDOMAINs into PSTN, and PSTN
is instructed to route ENUM-only ranges back to some IP gateway, you
1) unnecessarily bother PSTN and 2) you might easily create a loop.

What Richard is looking for is the method how to tell the aplication "please
_never_ use PSTN in case that NAPTR for the exact number does not exist".

> of RFC103[45] and a very long period of migration. Good luck getting

I don't think there's any need to redefine the RFC103[45]. The "default route"
behaviour might probably be also achieved by some other means, like another
record in the zone, another flags in NAPTR or another infrastructure ENUM
zone. For example, the following approach might work:

Fictive ENUM-only zone:  +421 700 ... 

$ORIGIN  0.0.7.1.2.4.e164.arpa.
* IN  NAPTR 10 10 "d"   ->   would be the default record for the +421 700 ...
  IN  NAPTR 10 10 "e"   ->   would be the redirector for exact records
                             pointing to other DNS zone e.g. 700.mydomain.org
                             or perhaps even  E.0.0.7.1.2.4.e164.arpa.

Then you can disable PSTN fallback or set other options in the default record
and proceed with normal ENUM rules in the exact tree.

As mentioned before, this will be of high benefit also for DDI ranges, since
here you can set the default record to use the VoIP gateway attached to PBX
and list only exceptions in the exact tree.

	With kind regards,

		M.

----   Marian Durkovic                       network  manager         ----
----                                                                  ----