RE: [fwd: my comments to the SPAN list]
- Date: Thu, 24 Oct 2002 10:26:06 +0100
At 11:01 am +0200 24/10/02, Stastny Richard wrote:
> -----Original Message-----
From: Jim Reid [
]
Sent: Thursday, October 24, 2002 10:35 AM
To: axelm@localhost
Subject: Re: [fwd: my comments to the SPAN list]
>>>>> "axelm" == axelm axelm@localhost writes:
axelm> Yes, DNAME support was added in BIND9. But: DNAME is only
axelm> neccessary if you have such weird things like the "shortcut
axelm> dial prefixes" of Austrian cities (Vienna can be reached
axelm> via the prefix "01", but also via "0222").
There may also be a need for DNAME whenever area codes (or
equivalent) get renumbered. [This has happened to London's
area code twice in the last 20-25 years.] An ENUM trial
should explore the use of DNAME for these situations.
This was the major reason for the discussion: area code splits. If
anybody is interested,
in the hassles involved with this, see the sections on area code splits
in the US ENUM
Forum Unified Document 6000. There also the permissive dialing period is
defined:
Hi Folks,
I understand the absolute requirement to support relief codes and
permissive dialling periods (infinite/undetermined in some cases).
DNAME sure looks like a natural solution. The fact that it *was*
seen as being tied up with A6 RRs doesn't mean that it's dangerous.
For folks who really don't like DNAME, there *MAY* be other solutions
using NAPTR processing (i.e. on the client rather than server side)
and * zone file entries.
Personally, I would very much like to see both DNAME (i.e. BIND9.x)
*and* any alternatives used in the trials - I'm interested in the
performance split between client and server, which is a good reason
for doing a trial, IMHO.
=> "should" for B9.x is the maximum strength I can live with - really
I'd prefer it to be the only explicit example mentioned.
Use of IXFR is yet another thing we can test - it's in effect "proprietary"
to B9.x, so there may be other alternatives tested as well. Again, isn't
that why we do trials?
all the best,
Lawrence
--
-----------------------------------------------------------------------
Roke Manor Research : This information is provided "as is" and is not
<
>: intended to create any contractual or legal
<tel:+441794833666> : relationship.
