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

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

Mike,

I agree what you said below, but there a some minor caveats:

-Most "network" operators are still dreaming of NATs, Session Border
Controller, etc. you name it.

-regarding golden NP databases: you live in a country with a centralized
NP databases, there a many countries (including my own) where very operator
is running his own (private) NP database.

- I also agree with end-to-end and that the final routing method on IP is 
DNS and URI, but then URIs need to be routable and public.
Exactly that is what some "network" operators do not want.

-These operators are also dreaming of termination charges for
incoming calls to their network. If I ask them if I get charged
(maybe also on distance) accessing a webpage, I earn a blank stare.

I think many people from telco (NGN) land still need a learning phase how
the Internet works.

Richard

> -----Original Message-----
> From: Mike Hammer [mailto:mhammer at cisco.com]
> Sent: Tuesday, June 29, 2004 6:23 PM
> To: Stastny Richard; Livingood, Jason; enum at ietf.org
> Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM)
> 
> Richard,
> 
> The discussion below triggered some (possibly related) thoughts:
> 
> "NATs are evil!"  Let's not recreate the issues that occurred with IP
> layer
> addressing, where public and private addressing spaces create problems.
> 
> "Those who do not learn from history are condemned to repeat it." George
> Santyana
> 
> KISS:  Keep It Simple and Stupid (or to follow Occam's Razor:  the simpler
> solution will be the better one)
> 
> E.164 numbers are used for routing and it works globally because it is one
> coherent system.  If you look at the Number Portability system, it is
> coordinated and consistent.  There is no discussion of golden versus
> silver
> NP trees.  The fact that some of these numbers are migrating to the IP
> domain should not change that characteristic.
> 
> The reason E.164 numbers work is that a call can be routed to a switch
> where it can be determined that the number terminates at a terminal or it
> is unassigned.  The ability to make that determination should either
> reside
> in the ENUM system or at the "switch/host" that ENUM points to (just like
> in NP).
> 
> One of the consequences of pushing intelligence to the edge is that the
> edge devices have to take on the responsibilities that come with doing
> that.  If the end-host want to be the switch (call controller), then it
> needs to handle all that being a "switch" entails.  If not, it needs to
> hide behind a service provider device that is willing to step up to those
> responsibilities.
> 
> Once an address is translated from an ENUM E.164 number to another address
> type, such as a sip: URI, then the ENUM work is done.  Everything after
> that is a normal DNS process, or in the case of routing a SIP INVITE to
> that sip: URI, if further translation of one sip address to another is
> needed, that is a SIP process, no longer an ENUM concern.
> 
> My forward-looking assumption is that service providers in the IP domain,
> will eventually want to base their network design and dependencies on the
> URI addressing schemes, not necessarily the E.164 addressing.  (Remember
> when mail addresses were assigned numbers?)  ENUM will work best if it
> does
> not try to solve all the problems that really belong solely to the pure
> non-E.164 IP domain technologies.
> 
> Then again, my head may still be ringing from the concert I attended last
> night, and I will come to my senses before too long, and see that this
> complexity is somehow necessary and desirable.
> 
> Mike
> 
> 
> At 10:20 AM 6/29/2004 +0200, Stastny Richard wrote:
> > > 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


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