Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM)

From: "Stastny Richard" <[email-masked]>
Date: Tue, 29 Jun 2004 04:27:03 -0400

> There is no technical reason why 'public'
> ENUM cannot be applied to this problem (I am purposely using 'public' and
> ignoring the artificial and loosely defined concepts of 'user' and
> 'carrier'
> ENUM - everyone has their own understanding of each it seems).

Hi Jason,

Sorry for the somewhat delayed answer, I was busy.
I think you made a very good point, but there may be a distinction
between 'publi'! and 'private'.

Let's try an analysis of the ENUM 'market' and the 'customers'.

Historically ENUM started with the following idea:
1. A subscriber has already an E.164 number on the PSTN
(this was the only way to get an ENUM entry),
and he may now decide on his own to request an
entry in ENUM (opt-in), given his country has
also decided to opt-in.

He may now place URI's in his ENUM entry, pointing in principle
to whatever a URI may point to, e.g. a sip or mailto URI.

Where he gets the URI from in the first place was his own business.

This was not a good business model, because it was to complicated,
confusing to have two terminations, one on the PSTN and one on
the Internet, and finally after three years nobody is able to
get a delegation in any country anyway. So only some freaks
used it.

There was only one potential business: linking IP PBX together:
In this case you could reach the same extension from the PSTN and
from the Internet, so from a end-user point the same device rings.
The user may also just dial a number and the IP PBX checks ENUM
First and if nothing is found, it dumps the call to the PSTN.
If the company knows that some other companies they are dealing
with are also in ENUM, they may save substantial money.

Note: this may now also be an option again for residential subscribers
considering the new ATA's with FXO-ports (e.g. the SPA-3000, Azatel, etc)

2. Where did the above mentioned freaks get the SIP URI's from?
>From "providers" like FWD, sipphone, iptel, or DYI.
Now these providers all had numeric userID. Why? Because it
is easier to dial them on IP Phones and especially ATAs.
These providers now started to link each other together using
"cross trunking" access codes, but also some of them wanted to implement
ENUM. This is useful, but where to get numbers from. What they needed
where numbers NOT yet existing on the PSTN, so no opt-in is required.
Some countries considered to open special number ranges for this
purpose, but again these numbers are not available really,
and if, they will be non-geographic numbers
The above mentioned providers in most cases had no (direct)
interworking with the PSTN.

3. Some providers started to interwork with the PSTN and here
it showed clearly that customer primarily wanted local geographic 
numbers. Period. These numbers differ from the above mentioned opt-in
scheme in 1. that they really terminate on IP, either single numbers
ported out or whole number ranges. If these providers want to link
each other via ENUM, ALL numbers must be in ENUM, so we have now
a clash with the original opt-in model. This problem may still be
solved insofar that a user may opt-in with a PSTN line on his
own, but with a VoIP service automatically by his provider (e.g.
he agrees that his number will be in ENUM (privacy provided) if
he is using this service). There are even ways to accommodate
both in one tree.

Note: one basic attribute of all these options is that the user
has in addition to his E.164 number a public URI assigned. He may
be reached via this URI regardless of ENUM. So if a calling
user knows the URI, he may reach the called party in any case.

Or in other words, ENUM is opt-in for the CALLING User also.

Sofar the story of public "User" ENUM in e164.arpa. The major
problem of e164.arpa is that it is simply not available, so one
may get the idea to set up the same principle just in another
tree (temporarily?) (silver tree), so every operator may join
with his number ranges.

4. Now we have other customers for "ENUM" in addition. Any provider
using VoIP internally in his network (e.g YahooBB!, Comcast, etc.)
is currently interconnecting via the PSTN. Logically both the
providers and the users may benefit if these operators would
interconnect via IP. The big difference between these providers
and the above mentioned three options is that the subscribers
of these operators DO NOT GET AN URI (at least not a public reachable
one). There are many reason for this, e.g. the providers do not
want to make the internals of there networks public, privacy again 
(because ALL numbers of an operator needs to be in),
but the major reason is: if you make a URI public, you also need
to agree on zero-termination. There will also be a clash with
already opted-in users.
This tree may finally be the authoritative NP tree pointing
for each E.164 number to the provider hosting it and MUST be able
to do this even if the PSTN ceases to exist.

5. I just want to add one option for completeness: some providers
want also to announce not only the numbers they host, but also the
number they may make available on the PSTN via their gateways. ENUM
is not designed for this, one should use TRIP or OSP for this purpose.

I currently do not see a possibility to get all requirements
for all 4 options workable in one tree. I also do not see
any advantage for option 4 candidates to go for e164.arpa,
because they need a solution NOW and they may do this in any
tree (public or private) (see also ETSI draft TS 102 055)

So I see two possibilities for User and Infrastructure ENUM are:

1. Find a way to implement everything in one tree
(which I consider not possible, but I am open for proposals)

2. Make two trees, one for above option 1.-3. and another
one for option 4.

There is no problem having two trees in parallel, a provider
(or even the user himself) may query public User ENUM first
and public or private Infrastructure ENUM afterwards.

Talking about two trees, of course there will be more trees at
the beginning, but if every operator gets delegated only
the numbers he is hosting, any two trees may be merged without
any problem (if no transit routes are in).

This leaves the question of e164.arpa itself. For Infrastructure
ENUM there is no need to go into e164.arpa and wait until hell freezes
over until all countries have decided eventually to opt-in.

Sorry to say, but the same is valid for "User" ENUM. The proposal
here is to set up a silver tree immediately by all interested parties,
which may or may not be folded back to e164.arpa if it gets useful.
Countries already having e164.arpa implemented may be copied over
to the silver tree in the meantime.

Best regards
Richard

> -----Original Message-----
> From: Livingood, Jason [mailto:Jason_Livingood at cable.comcast.com]
> Sent: Friday, June 25, 2004 5:16 PM
> To: 'Fullbrook Kim (UK)'; 'enum at ietf.org'
> Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM)
> 
> Kim wrote:
> 
> > The intent of the ENUM DNS (from RFC 2916) is that it can be "used for
> identifying
> > available services connected to one E.164 number" giving examples of
> re-directs, email >
> > address and web page.
> > Someone can wardial the DNS using E.164 numbers to get back a list of
> SIP
> URIs and
> > potentially other information such as email addresses. My definition of
> a
> phone book
> > obtained by this means is a list of valid SIP URIs which contain some
> user-specific
> > information.
> 
> I agree that this is possible, which begs the question of *why* a rational
> person would choose to register a number in ENUM and request with their SP
> that service addresses (email addr, IM ID, mobile #, etc.) be associated
> with their E.164 number?
> 
> The only use case I can reasonably imagine is one for businesses, whereby
> 1-800-COMPANY is associated in ENUM with a variety addresses for that
> company (www.company.com, support at company.com, etc.).  These are entities
> which want to share as much contact information as possible, compared to
> consumers which generally wish to share as little as possible.  This
> business use is perhaps not a sufficient justification for investment in
> ENUM infrastructure in various countries (unless establishing a working
> business model is a thing of the past - but I think the bubble days are
> gone).
> 
> What we seem to have, however, is a massive new market for VoIP services
> that would find ENUM to be a very helpful solution to enable softswitches
> (or SIP gateways, whatever) to make on-net vs. PSTN routing decisions.
> The
> ultimate goal for these providers is to route calls over IP networks,
> without touching the PSTN (and therefore incurring various charges
> according
> to the PSTN regulatory regime).  There is no technical reason why 'public'
> ENUM cannot be applied to this problem (I am purposely using 'public' and
> ignoring the artificial and loosely defined concepts of 'user' and
> 'carrier'
> ENUM - everyone has their own understanding of each it seems).
> 
> Going back to Steve Lind's question of (paraphrasing) what problem the
> IETF
> is trying to solve, I still don't see an answer.  IMHO, ENUM can be used
> by
> Voice Service Providers (VSPs?), be they carriers, telcos, ILECs, CLECs,
> IXCs, ITSPs, ICSPs, ISPs, ASPs, etc. (whatever the acronym du jour is for
> describing voice).  It will be impossible to solve some constantly-
> shifting
> debate about 'privacy' in ENUM since no one seems to be able to agree on
> what privacy is (which is quite natural).
> 
> However, privacy can be more readily defined and agreed upon at the
> national
> level, which is how the public ENUM delegations occur.  Each country is
> likely to have different ways of viewing personal information and privacy,
> and have different laws, rules, and regulations to this effect.  Within
> countries, different providers may be treated differently and have
> different
> standards to meet for notifying or seeking the consent of  customers of
> the
> entry of their TN into ENUM (such as a highly regulated traditional telco
> vs. an unregulated ISP).  So it appears to me, at least, that privacy
> issues
> are best addressed locally, in each country.  And if that is the case,
> what
> is the point of much of the discussion on this list in the past several
> weeks?  What is the technical problem at hand?
> 
> Jason Livingood
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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: Jim Reid <[email-masked]>
Date: Tue, 29 Jun 2004 08:50:49 -0400

>>>>> "Richard" == Stastny Richard <Richard.Stastny at oefeg.at> writes:

    Richard> Sofar the story of public "User" ENUM in e164.arpa. The
    Richard> major problem of e164.arpa is that it is simply not
    Richard> available, so one may get the idea to set up the same
    Richard> principle just in another tree (temporarily?) (silver
    Richard> tree), so every operator may join with his number ranges.

Sorry Richard, this is too simplistic. Your so-called silver tree
could only work if all the operators reached a consensus on the domain
name of that tree and who got to operate and populate it. There's
probably about as much chance of that happening as I have of winning
Miss World. A unique and consistent naming scheme needs to be deployed
in order to avoid all sorts of confusion and bad practices that will
deter users and cripple the uptake of ENUM-based services. And as soon
as anyone starts talking about entering E.164 numbers into the DNS,
the usual government and regulatory issues raise their head. For
instance I cannot imagine the Chinese government agreeing to +86 going
under a registry operated in Austria. Or vice versa.

Maybe your silver tree could fly if all the VoIP providers and their
fellow travellers co-operated on setting this up. But so far all I see
are competing, mutually exclusive naming schemes which seem to be
about protecting market share or locking service providers and end
users into a vendor-specific solution. Getting co-operation seems
unlikely, even if there was agreement on who did what and how costs
were recovered. On top of that I can't see how VoIP provider A would
be comfortable exposing their customer's "phone numbers" in some
private, shared tree to VoIP provider B.

    Richard> I currently do not see a possibility to get all
    Richard> requirements for all 4 options workable in one tree.

Indeed. User and Infrastucture ENUM (to use those weasel terms) are
different things and cannot possibly exist in the same tree. They can
of course use the same domain name, but with different sets of name
servers providing different data to different constituencies: one for
the public internet and one for private telco-like usage. Since the
same sorts of applications are likely to live in both places -- ie
VoIP to SIP servers -- it would be sensible to use the same domain
name. That would avoid the messy complexity of applications having to
figure out where they are today to decide what domain name they should
lookup.

    Richard> There is no problem having two trees in parallel, a
    Richard> provider (or even the user himself) may query public User
    Richard> ENUM first and public or private Infrastructure ENUM
    Richard> afterwards.

I don't understand this. An end user should never, ever see a private
ENUM tree. Even if querying both trees was possible, how is the user
or application supposed to know which one holds the data it's supposed
to use? If my phone number is in both places each with 1 NAPTR record
pointing at different SIP servers, which one does the application
connect to? Now suppose one of those SIP servers lives deep in some
telco's net and is unreachable from another operator's net. Or the
internet. Or vice versa.

    Richard> Talking about two trees, of course there will be more
    Richard> trees at the beginning, but if every operator gets
    Richard> delegated only the numbers he is hosting, any two trees
    Richard> may be merged without any problem (if no transit routes
    Richard> are in).

This can never work. Number portability means block delegations to
operators will become increasingly fragmented over time. Delegations
will probably have to be made for individual numbers (or perhaps an
organisation's DDI block). If not, providers could use their control
over the end user's DNS content for all sorts of anti-competitive
practices. Like making it difficult to change the customer's
delegation to another provider.

FYI merging DNS trees is far from the simple exercise you seem to
think it is. Read on...

    Richard> This leaves the question of e164.arpa itself. For
    Richard> Infrastructure ENUM there is no need to go into e164.arpa
    Richard> and wait until hell freezes over until all countries have
    Richard> decided eventually to opt-in.

Wrong. Operators can (and probably should) use a private version of
e164.arpa today. This doesn't need any involvement in the Tier-0 and
Tier-1 stuff or ITU's interim procedures. e164.arpa is the IETF/IAB
agreed domain name for ENUM. It's neutral and not controlled by any
commercial interest or nation. So it's the obvious choice for the
unique and consistent naming scheme that Infrastructure ENUM
needs. There is no viable alternative. [BTW don't confuse the domain
name e164.arpa with its public expression on the internet today.] This
would also make it easier for operators to interwork and perhaps link
their private trees: ie nobody has to figure out the DNS gunk needed
to merge say enum.pulver.com with e164.at or enum.bt.intra.

    Richard> Sorry to say, but the same is valid for "User" ENUM. The
    Richard> proposal here is to set up a silver tree immediately by
    Richard> all interested parties, which may or may not be folded
    Richard> back to e164.arpa if it gets useful.  Countries already
    Richard> having e164.arpa implemented may be copied over to the
    Richard> silver tree in the meantime.

Richard, you should not be making statements like this. Merging trees
and migrating domain names is a very, very painful process. [I know
because I've done it. Have you?] Even for the most trivial of cases in
controlled environments, this exercise is difficult, time-consuming
and all too easy to get wrong. In an ENUM world with as little as a
few hundred individually managed zones, migrating or merging them will
be effectively impossible. Now scale this to say a few million
delegations... For bonus points, deal with zones that have NAPTR
records pointing at URIs inside the tree that's being merged.

Please remember that once a domain name is registered and gets used,
it lives forever in things like application software, configuration
files, address books, search engine databases, web links, documents &
stationery, web browser bookmarks, etc, etc. Once someone starts
populating phone numbers or whatever under RichardsSilverTree.at,
they're going to be pretty much stuck with that until long after hell
freezes over. I sometimes still get email sent to an address I stopped
using 10+ years and 5 jobs ago.

This is one reason why there needs to be considerably more thought
about the choice of domain name for Infrastructure ENUM. You seem to
be saying that any old name can be used and moved elsewhere at some
point in future with a wave of a magic wand. It's not going to be that
simple. It can't be. Trust me on this. I've done fairly big domain
name migrations/mergers and know just how hard this is to do. It's
even harder when trying to maintain continuity of service. And harder
still when you've no idea what applications are out there and what
they look up or how they'll break if their favourite domain names get
changed. 

I think we agree there must be a single, consistent name space for
Infrastructure ENUM. The question then becomes one of implementation:
what domain name is used and how it gets realised. This is orthogonal
to what happens with the public e164.arpa name space. Please don't
confuse these two things even if the same domain name happens to apply
to both.

---

From: "Christian de Larrinaga" <[email-masked]>
Date: Tue, 29 Jun 2004 09:50:39 -0400

Jim

you wrote. .

> Operators can (and probably should) use a private version of

cdel:--< what specifically do you propose? It sounds like you are proposing
non routable private e164.arpa zones behind firewalls?

and ...

cdel:---< By infrasructure ENUM do you mean ENUM that is not e164.arpa and
is established for and by operators to interoperate between each other in
particular when a e164 number is not entered into the e164.arpa tree? i.e.,
not the operator's internal private ENUM tree nor e164.arpa but something
else?

i.e., in your own words of a few months ago not really ENUM but ENUM-like?

Christian

---

From: Jim Reid <[email-masked]>
Date: Tue, 29 Jun 2004 12:59:11 -0400

>>>>> "Christian" == Christian de Larrinaga <cdel at firsthand.net> writes:

    Christian> cdel:--< what specifically do you propose? It sounds
    Christian> like you are proposing non routable private e164.arpa
    Christian> zones behind firewalls?

In simple terms, yes. Sort of. Each operator has their own e164.arpa
tree which is private to them and used for internal purposes like call
routing. These trees won't need any opt-in principle as they could be
used for all numbers served by the operator, including unlisted ones.
Some operators may want to share or link their private trees, for
example in some sort of joint venture. This is one reason why these
trees should be anchored under a single domain name.

    Christian> cdel:---< By infrasructure ENUM do you mean ENUM that
    Christian> is not e164.arpa and is established for and by
    Christian> operators to interoperate between each other in
    Christian> particular when a e164 number is not entered into the
    Christian> e164.arpa tree? i.e., not the operator's internal
    Christian> private ENUM tree nor e164.arpa but something else?

No. ENUM is when an E.164 number is entered under e164.arpa according
to RFC3761. Infrastructure ENUM is when an operator populates their
private e164.arpa tree and uses the data there for internal purposes
such as call routing. End users will have no access to this tree or
direct control over what's stored there. Operators might or might not
choose to expose these private trees to each other.

E.164 numbers entered under any domain name other than e164.arpa don't
comply with my understanding of ENUM: ie RFC3761.

---

From: "Christian de Larrinaga" <[email-masked]>
Date: Tue, 29 Jun 2004 13:44:26 -0400

-----Original Message-----
From: Jim Reid [mailto:jim at rfc1035.com]
Sent: 29 June 2004 17:49
To: cdel at firsthand.net
Cc: Stastny Richard; enum at ietf.org
Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM)

christian:-> just so I've got this straight! You propose we use the name of
the domain e164.arpa (ONLY) by all operators on their private DNS (for
infrastructure use and some intra-operator connections) as well as e164.arpa
for public (for public open delegations)?

i.e., rather than setup a separate domain name by operators such as
e164.operator.foo all ENUM is handled in e164.arpa public and private trees.

And then to rely on the network configuration around that DNS to route ENUM
lookups to the appropriate DNS server whether public or private
(infrastructure)?

This suggests to me that you might get different answers to an ENUM
(e164.arpa) look up depending on where you are?

How do you ensure that public e164.arpa has first priority so that users
public ENUM NAPTR records take precedence over operator (private ENUM)?

cdel:--> a point well made :-)

Christian

---

From: Jim Reid <[email-masked]>
Date: Tue, 29 Jun 2004 14:27:27 -0400

>>>>> "Christian" == Christian de Larrinaga <cdel at firsthand.net> writes:

    Christian> just so I've got this straight! You
    Christian> propose we use the name of the domain e164.arpa (ONLY)
    Christian> by all operators on their private DNS (for
    Christian> infrastructure use and some intra-operator connections)
    Christian> as well as e164.arpa for public (for public open
    Christian> delegations)?

Yes.

    Christian> i.e., rather than setup a separate domain name by
    Christian> operators such as e164.operator.foo all ENUM is handled
    Christian> in e164.arpa public and private trees.

Yes. ENUM => e164.arpa. Always. Anywhere else isn't ENUM.

    Christian> And then to rely on the network configuration around
    Christian> that DNS to route ENUM lookups to the appropriate DNS
    Christian> server whether public or private (infrastructure)?

Yes.

    Christian> This suggests to me that you might get different
    Christian> answers to an ENUM (e164.arpa) look up depending on
    Christian> where you are?

Yes.

    Christian> How do you ensure that public e164.arpa has first
    Christian> priority so that users public ENUM NAPTR records take
    Christian> precedence over operator (private ENUM)?

You don't: that's a policy decision and implementation detail. And
anyway who's to say whether the public or private tree takes
precedence? Or even if precedence is appropriate? If my application is
in some operator's net, it looks up <number>.e164.arpa in their
private tree and the answer determines what the application
does. Likewise if it's on the internet, the application will query the
public e164.arpa tree and uses that answer. ie Where the application
lives determines what name space it gets to see and what answer the
application gets *for the same query*.

This is no different from how most big organisations do DNS today. If
something's on the corporate intranet, they see the internal name
space for example.com, complete with internal-only reachable web
sites, mail servers and so on. When something's on the internet, they
see the public face of example.com. That may or may not be very
different from the internal name space.

---

From: "Christian de Larrinaga" <[email-masked]>
Date: Tue, 29 Jun 2004 17:48:29 -0400

From: Jim Reid
Sent: 29 June 2004 19:22

Yes.

Christian-> So much for DNS being the universal name space!

Christian -> Leaving aside for the moment whether it is a good thing to
encourage large corporates' to believe their view of the outside world is
just an expression of their own world view and should be shaped to fit!

The example you use of example.com has problems as of course example.com (in
your example) owns the lease to the domain example.com and so has every
godlike right to amend the world order for those living in its realm
(irritatingly!) - but I would argue not outside it - thank goodness!

Bearing that point in mind e164.arpa has absolutely nothing to do with
example.com or carrier.foo for that matter.

Now if you setup a domain such as ibm.com, that is recognised as a genuine
registered existant domain with unique qualities on the Internet, within
your own DNS and you serve information from this domain to members of the
public as if you are that entity then you are I think placing yourself in a
position of representing yourself as that domain.  That has serious legal
consequences.

But also looking at this from a practical perspective. As a travelled user
when I want to reach my family from my SIP phone using a hotel room's
Internet access (just think wistfully ahead!) I will expect having spent my
Sunday programming in their 25 various devices and lifestyle options to
match, to be able to reach them through whatever device is on duty at that
time as set up in the relevant ENUM NAPTR record that I worked so hard
getting right.

So I will be mighty slaked off to find some spotty Hotel network VoIP
operator claims no knowledge of what's happened to the NS records for the
appropriate domain in e164.arpa because of course his e164.arpa is the
doublethink reality version.

As Peter suggested using Application layer tunnelling to captivate user
applications within these goldfish bowl domains I don't see why I shouldn't
use similar to get through and around them should they become a reality!

Christian

---

From: Jeff Williams <[email-masked]>
Date: Tue, 29 Jun 2004 21:15:13 -0400

Richard and all,

  Your #2 possibility looks feasible.  I would need to study and test
the effects of #4 Idea before I could be comfortable with it though.
So I will turn that over to our R&D folks with my personal participation,
and see how well your #2 possibility actually works before committing..

> > weeks?  What is the technical problem at hand?

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 jwkckid1 at ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827

---

From: Jeff Williams <[email-masked]>
Date: Tue, 29 Jun 2004 21:40:39 -0400

Jim and all,

Jim Reid wrote:

> Miss World.

  Good point here Jim, and of course your right IMHO.  Oh and I prefer the

Miss Nude World contest of which I have again been ask to be a judge.  >:)

But I am sure you would not qualify for that contest either, or at least I
hope
you wouldn't!  >:)

> A unique and consistent naming scheme needs to be deployed
> fellow travellers co-operated on setting this up.

  I don't see a chance of this happening either..

> But so far all I see

  Very well stated points here Jim!  Well done.  And this in part was
my and our members concerns with publicly viewable or available
Assigned ENUM's to users.

> delegation to another provider.

  Yes this was discussed some time ago, and also remained relatively
unsolved, so that subject line was dropped...  Glad you brought it
back up though here.

> needs.

  Do you mean an agreed upon TLD for ENUM here?

> There is no viable alternative. [BTW don't confuse the domain
> their private trees: ie nobody has to figure out the DNS gunk need

Regards,

---

From: Marian Durkovic <[email-masked]>
Date: Wed, 30 Jun 2004 03:02:56 -0400

Jim,

   I strongly disagree with your proposal to "overlay" public e164.arpa
by each telco with its own private tree. This would mean, that completely
unrelated and unathorized entities (i.e. telco X in country A) will be 
suggested to replace authoritative data from national (e.g. 1.2.4.e164.arpa) 
domain delegated by ITU/RIPE by any data (or garbage) they will. 
I think this undermines the basic principle of DNS operation, where only 
one entity is authoritative for a given domain and creates the state, 
where several thousand (!) different zone file versions could exist for 
the same domain. 

   IMHO different tree is a must here, and lookups into different
trees are supported in software now.

	With kind regards,

		M.

> different from the internal name space.

--------------------------------------------------------------------------
----                                                                  ----
----   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: md at bts.sk    ----
----                                                                  ----
--------------------------------------------------------------------------