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

From: "Stastny Richard" <[email-masked]>
Date: Thu, 09 Jun 2005 06:17:52 -0400

Additional thoughts to the handling of DDIs

The need to enter for each single DDI number could
only be avoided if the following wild cards are possible

If in the below example from the draft the number 1-497-867 
is considered the "pilot" number and 5309 the partial number:

$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?

Regards
Richard

Richard Stastny
OeFEG
tel:+43 664 420 4100
enum:+43 780 203 211
callto://fordprefect
http://voipandenum.blogspot.com

> -----Original Message-----
> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf
Of
> Stastny Richard
> Sent: Wednesday, June 08, 2005 6:00 PM
> To: Michael Haberler; Lupton, Ronan; enum at ietf.org
> Subject: Re: [Enum] Fwd: I-D
ACTION:draft-pfautz-lind-enum-carrier-user-00
> .txt
> 
> 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
> 
> 
> 
> 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/mail
ma
> n/listinfo/enum
> >
> >
> >
> 
> 
> _______________________________________________
> enum mailing list
> enum at ietf.org
> https://www1.ietf.org/mailman/listinfo/enum
> 
> 
> 
> 
> _______________________________________________
> enum mailing list
> enum at ietf.org
> https://www1.ietf.org/mailman/listinfo/enum

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

---

From: Otmar Lendl <[email-masked]>
Date: Thu, 09 Jun 2005 07:24:17 -0400

> Question to the experts: is this allowed?

Two remarks on this:

* You need two more RRs as the wildcard does not cover the
  $origin itself, i.e.:

	@ 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

* Similar setups are common in the wildcard MX record case, e.g.
  I just tried:

  *.test          MX      10 mail
  *.test          MX      20 other-mailhost

  and this works without any problems.

I haven't looked at the regex and replacement part of the DDDS algorithm yet.
Testing that is next on my agenda.

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

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 09 Jun 2005 07:32:49 -0400

On Jun 9, 2005, at 06:15, Stastny Richard wrote:
If in the below example from the draft the number 1-497-867
is considered the "pilot" number and 5309 the partial number:
$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, but whether you get what you want out of this when querying is  
questionable.

The problems with wildcards are the following:
- When issuing a query for Owner FOO, Class IN and Type NAPTR, you  
will get a match ONLY if there is no other record with the same  
Owner, regardless of Type. This imply, if you have NS, or SOA, or DS  
or whatever with Owner FOO, you will get "no such record" even though  
the wildcard is there.

- This is especially important when using NAPTR for  
"delegation"...how does this work with DNSSEC, and what chain of  
trust will you get?

So, whether the above will work or not depends on what other records  
exists in the same zone, what the queries are etc.

I would say "possible, but be very very careful".
    paf
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 09 Jun 2005 08:50:03 -0400

> The problems with wildcards are the following:
[...]
> exists in the same zone, what the queries are etc.

Isn't this what DNAME was invented for?

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: Jim Reid <[email-masked]>
Date: Thu, 09 Jun 2005 12:22:52 -0400

On Jun 9, 2005, at 13:48, Clive D.W. Feather wrote:
Patrik Fältström said:
The problems with wildcards are the following:
[...]
So, whether the above will work or not depends on what other records
exists in the same zone, what the queries are etc.
Isn't this what DNAME was invented for?
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.

It can be (ab)used for many things such as kludging around some of the 
horrors of wildcarding. Though IMO DNAME records really shouldn't be 
used for that sort of thing. DNAME *might* be useful in ENUM for things 
like area code changes or renumbering a DDI block. However be very, 
very careful,  just like Patrik said about wildcarding. CNAME synthesis 
can make life very exciting and not always in a good way....

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 09 Jun 2005 12:46:36 -0400

On Jun 9, 2005, at 08:48, Clive D.W. Feather wrote:
Patrik Fältström said:
The problems with wildcards are the following:
[...]
So, whether the above will work or not depends on what other records
exists in the same zone, what the queries are etc.
Isn't this what DNAME was invented for?
....yes, and why DNAME is not recommended.
   paf
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 09 Jun 2005 12:51:28 -0400

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

---

From: Jim Reid <[email-masked]>
Date: Thu, 09 Jun 2005 15:18:40 -0400

On Jun 9, 2005, at 17:50, Patrik Fältström wrote:
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.
I could not agree more. Using DNAME or wildcards to kludge around 
deficiencies in a provisioning system or name server configuration is a 
recipe for trouble. This is particularly true for ENUM. It's even worse 
when the QNAME that matches a wildcard or gets rewritten on 
encountering a DNAME then gets to match against regexps in the NAPTR 
records.

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.
Indeed.
Remember the saying "when the only tool you have is a hammer, every 
problem looks like a nail"? I fear some people are trying to solve the 
ENUM provisioning problem by using the DNAME and DNS wildcard hammers.