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

[Jeff Williams <jwkckid1 at ix.netcom.com>]

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..

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

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



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