[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Jim,

A test of the adequacy of the system you propose should be the ability of a call to an E.164 number from any random entry point into the IP domain (e.g. from any -- confederated or not -- service provider's gateway) MUST be able to be completed, except where unassigned, out of service, or protected by a subscriber feature.

Rather than relying on "joint ventures" to "share or link their private trees" (at which point privacy issues may arise) wouldn't it be better for the public ENUM to provide that linkage?

If I understand correctly this could be a 3-stage process:

1) PSTN call causes NP dip and resolves to an IP-domain indication
   Local database determines TDM routing to IP Gateway
   PSTN call routed to nearest IP Gateway
   (optional if call originates in IP)

2) Public ENUM search resolves to Service Provider (SP) URI address
   DNS search gives corresponding IP address
   IP setup message routed to SP
   (SP is public operator/carrier, enterprise, or opt-in end-user)

3) Private "ENUM" search (on local part of URI) resolves to Subscriber URI address
DNS search gives corresponding IP address
IP setup message sent to Subscriber
(optional if SP was end-user; subscriber is operator/carrier customer or
enterprise end-point)

I assume there will still be haggling over the design of the public ENUM, but at least it could be one complete, consistent, regulated, equal-access, market-neutral tree.

Mike


At 05:48 PM 6/29/2004 +0100, Jim Reid wrote: 
>>>>> "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.

_______________________________________________
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