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

["Stastny Richard" <Richard.Stastny at oefeg.at>]

> 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