Subject: RE: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00 .txt

From: Michael Haberler <[email-masked]>
Date: Wed, 08 Jun 2005 10:55:41 -0400

What I am suggesting is that the proposal be actually tried out given, say, 
the JPRS resolver (which says it can do a single nonterminal) and lookups 
of numbers at the delegation boundary (likely works) and what happens if a 
longer number (with a DDI appended) and thus points into on of the user 
and/or carrier subtree

I assume it can be made to work, or maybe it works anyway, I'm just curious 
on the results in a setting where you cant assume all numbers are 10 digits

we're currently looking into it over here in non-NANPA land
-Michael
At 15:59 08.06.2005, Lupton, Ronan wrote:
Michael,
Does ITU E164 standard not define certain characteristics of numbering in 
a standard format?

I attach a copy of the specification. I make specific reference to page 13 
of this standard.

I gather it is the fundamental basis for the .e164.arpa addressing structure.
I had a number of conversations re: same at ETSI last week.
DDI (Direct Dial Inwards) allocations are generally relevant to B/P - ISDN 
services are generally the last 4 digits in a given E164 number within the 
national number plan.

Regards,
Ronan Lupton
MCI
-----Original Message-----
From: enum-bounces at ietf.org 
[<mailto:enum-bounces at ietf.org>mailto:enum-bounces at ietf.org] On Behalf Of 
Michael Haberler
Sent: 08 June 2005 12:50
To: Richard Shockey; enum at ietf.org
Subject: Re: [Enum] Fwd: I-D 
ACTION:draft-pfautz-lind-enum-carrier-user-00.txt

at first glance, this looks like it could resolve the user/carrier
discussion while subsuming both flavours under one tree, with the
corresponding cost advantage, and simpler interfacing
A potential issue I could think of - how does this work in a open number
plan (variable number length, and variable length DDI *extension*) ?
-Michael
_______________________________________________
enum mailing list
enum at ietf.org
<https://www1.ietf.org/mailman/listinfo/enum>https://www1.ietf.org/mailman/listinfo/enum 

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 08 Jun 2005 11:57:35 -0400

Roman,
 
I think you refer to Figure 2/E.164 on page 13
 
First, there is nowhere anything about 4 digits
Second you mix up the partial number (which is the DDI)
which is part of the SN and therefore part of the E.164 number,
 
and the ISDN SubAddress, which is not part of the E.164 number (up to 40 dgits)
and therefore not in ENUM.
 
There is no restriction of the lenght of the DDI, as long as the
E.164 number (pilot + DDI) is not exceeding 15 digits.
 
The pilot number is the full E.164 number - DDI ;-)
 
The problem with DDI numbers already exists in "normal" ENUM,
because a user (e.g in Austria or Germany) may either dial the Pilot
number alone or the Pilot + 0 to get to the switchboard. In the first case
by timeout, in the second direct.

or he may dial the extension direct. If he dials a non existing extension,
he also ends up with the switchboard by timeout
 
The problem is that the DDI number plan is up to the PBX admin;
he even does not need to be constent in number lenght, so he may
have a internal number plan such as:
0 for outcalls
2xx
3xx
4xx
5xx
6xxx
7xxx
91
92 for cross-trunks
and he may change this at any time without telling the provider.
 
Ok you may forget 0 and 9, because they are not reachable via DDI.
 
In normal ENUM you delegate the pilot 
say +4350811 from tier 1 Nameserver with NS records to a tier 2 NS
RUN by the enterprise having the PBX with DDI
In the tier 2 NS you enter the NAPTR to reach the switchboard
and additional NAPTRs for each DDI number (subdomain)
 
The basic idea with the Pfautz draft is that you enter 2 non terminal
NAPTRs for each single E.164 number. Since the DDI number space
is administrated by the PBX admin, he may do so, but he would have to
with each extension via the Tier 1 (which may charge for each transaction)
in the above case he is only changing his own tier 2 nameserver
 
In addition, the carrier record needs to be updated in parallel,
so the user is managing carrier records ;-)
 
So DDIs may be implemented, but would require a transaction
in Tier 1 for each change in DDI numbers.
 
best regards
Richard

________________________________

Von: enum-bounces at ietf.org im Auftrag von Michael Haberler
Gesendet: Mi 08.06.2005 16:55
An: Lupton, Ronan; enum at ietf.org
Betreff: RE: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00 .txt

-Michael

---

From: "Klaus Darilion" <[email-masked]>
Date: Thu, 09 Jun 2005 07:43:09 -0400

Hi! 

> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On 
> Behalf Of Stastny Richard
> $Origin 7.6.8.7.9.4.1.e164.arpa.
> 
> * IN NAPTR 100 50 "" "E2U+user"   "" 7.6.8.7.9.4.1.joesenum.com
> 
> * IN NAPTR 100 50 "" "E2U+carrier"   "" 7.6.8.7.9.4.1.telco.net
> 
> Question to the experts: is this allowed?

yes. The problem occours on the second step of the DDDS algorithm: For
each dialed extension, the replacement is the same, e.g.
7.6.8.7.9.4.1.joesenum.com.

Thus, the second NAPTR is for example:

$7.6.8.7.9.4.1.joesenum.com.
@ IN NAPTR 100 50 "" "E2U+sip"
"!^\\+1497867(.*)$!sip:\\1 at sip.joe.com!" .

Using this regexp, you can catch all extension, but it is nearly
impossible the exclude some extensions from enum - for example fax
extensions. You would have to do it this way:
$7.6.8.7.9.4.1.joesenum.com.
@ IN NAPTR 100 50 "" "E2U+sip"
"!^\\+14978670001$!sip:0001 at sip.joe.com!" .
@ IN NAPTR 100 50 "" "E2U+sip"
"!^\\+14978670002$!sip:0002 at sip.joe.com!" .
@ IN NAPTR 100 50 "" "E2U+sip"
"!^\\+14978670004$!sip:0004 at sip.joe.com!" .
@ IN NAPTR 100 50 "" "E2U+sip"
"!^\\+14978670005$!sip:0005 at sip.joe.com!" .
...

That does not scale.

regards,
klaus

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 09 Jun 2005 11:12:38 -0400

Thanks Otmar, Patrik and Klaus for the replies
 
Klaus, with you reply I think I found now a major draw-back with this
approach.
 
in this case the normal way to to this, namely introduce subdomains is broken
 
you cannot use

$7.6.8.7.9.4.1.joesenum.com.
0.0.0.1  IN NAPTR 100 50 "" "E2U+sip" 
"!^*$!sip:0001 at sip.joe.com!" 
 
anymore.
 
But your proposal means that ALL NAPTRS
for all extensions will be returned in one response
which I do not know is possible at for large PBX

Help!

Richard

Von: Klaus Darilion [mailto:klaus.darilion at nic.at]
Gesendet: Do 09.06.2005 13:42
An: Stastny Richard; Michael Haberler; Lupton, Ronan; enum at ietf.org
Betreff: RE: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00 .txt

Hi!

That does not scale.

regards,
klaus

---

From: "Klaus Darilion" <[email-masked]>
Date: Thu, 09 Jun 2005 12:07:31 -0400

> From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] 
>  
> for all extensions will be returned in one response which I 
> do not know is possible at for large PBX

This is just a dirty workaround and does not scale for lot of
extensions. Consider the ENUM resolver has to fetch 1000 NAPTRs and
perform 1000 regexp to find the one matching NAPTR :-(

Maybe someone has a better approach how to handle this?

regards,
klaus

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 09 Jun 2005 13:26:15 -0400

Dear all,
 
CNAME, DNAME and non-terminal NAPTRs
 
I am not a DNS expert and I do not understand DDDS
 
I never understood what a non-terminal NAPTRs is really good for;

So can anybody out there explain to me what the difference between a 
not-terminal NAPTR and a CNAME is in terms of DDDS
 
In the draft-pfautz I-D the non-terminal NAPTR is used like a CNAME
what I need for my DDI problem is a non-terminal NAPTR working similar
to a DNAME
 
I was alo wondering why the example in the draft is:
 
$Origin 9.0.3.5.7.6.8.7.9.4.1.e164.arpa.
   IN NAPTR 100 50 "" "E2U+user"   "" 9.0.3.5.7.6.8.7.9.4.1.joesenum.com
   IN NAPTR 100 50 "" "E2U+carrier"   "" 9.0.3.5.7.6.8.7.9.4.1.telco.net
 
an not just

$Origin 9.0.3.5.7.6.8.7.9.4.1.e164.arpa.
   IN NAPTR 100 50 "" "E2U+user"   "" joesenum.com
   IN NAPTR 100 50 "" "E2U+carrier"   "" 9.0.3.5.7.6.8.7.9.4.1.telco.net
 
While it would make sense tu have a structure like
9.0.3.5.7.6.8.7.9.4.1.telco.net
 
because the telco may host many numbers, it
does not for a single user.
 
It would make sense if there is a rule like:
If you have something like
$Origin 7.6.8.7.9.4.1.e164.arpa.
 *  IN NAPTR 100 50 "" "E2U+user"   "" joesenum.com
 *  IN NAPTR 100 50 "" "E2U+carrier"   ""7.6.8.7.9.4.1.telco.net
 
you may contunue in 
$Origin joseenum.com
with
   9.0.3.5 IN NAPTR 100 10 "u" "E2U+sip" ""!^.*$!sip:info at example.com!" .
   
or in other words, if the ENUM client makes a DNS query for
for NAPTR for 9.0.3.5.7.6.8.7.9.4.1.e164.arpa.
 
and getting back
IN NAPTR 100 50 "" "E2U+user"   "" joesenum.com
in 7.6.8.7.9.4.1.e164.arpa.
he is attaching the rest of 9.0.3.5. (if there is one)
to joseenum.com yielding 9.0.3.5.joseenum,com
 
and makes a second query for this
 
This is of course a hack, but is would be very helpful
 
Richard

Von: Patrik Fältström [mailto:paf at cisco.com]
Gesendet: Do 09.06.2005 18:50
An: Jim Reid
Cc: Clive D.W. Feather; Stastny Richard; Michael Haberler; enum at ietf.org
Betreff: Re: [Enum] Fwd: I-D ACTION:draft-pfautz-lind-enum-carrier-user-00 .txt

On Jun 9, 2005, at 12:19, Jim Reid wrote:

> No, though I guess it all depends on your definition of "this". 
> DNAME was originally invented for reverse lookups of IPv6 addresses 
> that would have been "delegated" on arbitrary bit-boundaries with 
> bit-string labels. [It helped with renumbering of IPv6 networks and 
> multi-homed IPv6 nets.] Although that purpose has now gone away, 
> the DNAME RRtype lives on.
>

I just want to extend this explanation by stating that DNAME was 
designed together with the bitstring label ideas... Those together 
create a tool that makes it INCREDIBLY hard to make sure the zone 
setup is correct, and given approximately 20% of the normal 
delegations are broken already today, that percentage would 
definitely increase given DNAME+bitstring labels.

You WILL shoot yourself in your feet with tools like these.

And, remember that they in all cases I have seen were designed to 
solve problems people had in their management / provisioning systems.

Having humans by hand editing zone files using vi/emacs or whatever 
is over. We should not create hacks in the protocols because of "bad 
administration tools".

I do know we have admin/delegation needs in ENUM, but let's stay with 
those issues, and try to keep management tool bugs out of the 
discussion.

    paf