Subject: Re: [Enum] IETF, ENUM and NGN

From: Mike Hammer <[email-masked]>
Date: Thu, 01 Jul 2004 11:40:47 -0400

At 08:11 PM 6/30/2004 -0700, Jeff Williams wrote:
of their personal and private
data such as their name, ENUM number, address, and direct
contact phone number.
Jeff,
While other elements might be private data, the E.164 number is not.  The 
E.164 number MUST be visible to enable universal routing of calls to at 
least some node that can reach the terminal assigned that E.164 number.

The privacy issue is about what OTHER data gets associated with the E.164 
number, that is SPECIFIC to an INDIVIDUAL.  Please get this straight in 
your mind.

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

---

From: Jeff Williams <[email-masked]>
Date: Fri, 02 Jul 2004 00:40:35 -0400

Mike and all,

> least some node that can reach the terminal assigned that E.164 number.

Why?  I don't agree with your assertion here.  As a developer of many years,
making universal routing of calls to any node need not require that data to
be viewable.  I admit freely that it is much easier to code such calls to
data
that is, however.

> number, that is SPECIFIC to an INDIVIDUAL.  Please get this straight in

 Assigned ENUM numbers IS SPECIFIC to an INDIVIDUAL, and as such
needs to be protected for good and valid privacy reasons...

> Mike

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: Mike Hammer <[email-masked]>
Date: Fri, 02 Jul 2004 10:43:26 -0400

At 11:21 PM 7/1/2004 -0700, Jeff Williams wrote:
Mike and all,
Why?  I don't agree with your assertion here.  As a developer of many years,
making universal routing of calls to any node need not require that data to
be viewable.
What is viewable depends on what the software chooses to put on the 
screen.  But, by all means please enlighten me here.

How does a gateway from the PSTN attach to the Internet, receive a call 
from an E.164 number to a target E.164 number route the call, with no 
pre-assumed relationship with that target?

  I admit freely that it is much easier to code such calls to
data
that is, however.
 Assigned ENUM numbers IS SPECIFIC to an INDIVIDUAL, and as such
needs to be protected for good and valid privacy reasons...
So, the PSTN gateway that received the TDM call with a given target E.164 
called party address is by nature of receiving an IAM in violation of 
privacy laws?

Please explain at what point in time the privacy violation occurred?
When the caller dialed it?
When the originating TDM switch queried a NP database indicating it was 
ported to an IP endpoint?  (Or alternatively, the SP queried an internal 
database, which indicates the number is on its IP network rather than TDM 
network.)

When it reached the PSTN GW?
When the PSTN GW queries ENUM and finds the call can be routed to a certain 
service provider?  (This too could be in internal SP database, but for sake 
of completeness, we need to consider calls that span service providers.)

When that service provider translates the anonymous E.164 URI to a 
user-specific URI?

When the INVITE arrives at the called terminal?
It's clear we think differently.  But, I am trying to understand what you 
mean, even though I disagree about the legal judgement.

Mike

Regards,

---

From: Jeff Williams <[email-masked]>
Date: Fri, 02 Jul 2004 23:48:54 -0400

Make and all,

> screen.  But, by all means please enlighten me here.

  First of all you did not answer my question I ask in my previously ask,
which was "Why?".  Could you do that please?  Secondly, your right
of course, what is viewable does in the case of a call, depend on what
the calling software chooses to put on the or any screen.  However no
call from any calling program that I am aware of requires "Data" to
be 'Viewable" as the standards track for ENUM would require in it's
present state.  Hence privacy of assigned user ENUM's are exposed
to hacks unnecessarily and thereby endangering those users to significant
damages...

> pre-assumed relationship with that target?

  It doesn't.  And I didn't infer or suggest that it should/could in my previous
remarks.  I DID suggest that any assigned user ENUM number need not
be viewable for such to be routed.  There are several techniques by
which this can be accomplished, so I will not outline them as to do so
would be too verbose for the purposes of this forum.

> called party address is by nature of receiving an IAM in violation of

  In short, yes.

> Please explain at what point in time the privacy violation occurred?

  At the time the user ENUM is assigned and the user associated with
that number is not allowed to opt-out for said assigned number as
to be non-viewable..

Regards,

---

From: James Seng <[email-masked]>
Date: Tue, 06 Jul 2004 11:47:23 -0400

how about not able to get a delegation needed in e164.arpa?
it is like saying we design this wonderful DNS system but no one is able 
to register anything under it.

james
Jim Reid wrote:
What matters is the operators agree on a domain name for
Infrastructure ENUM. This might as well be e164.arpa since (a) it's
vendor neutral; (b) already an agreed IETF standard; (c) not
controlled by any nation. It's hard to see how any other choice of
domain name could be better (technically or politically). And it
prevents VoIP/SIP applications from getting schizophrenia from
figuring out which domain name they should use based on what network
they're running in today.
_______________________________________________
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: Adrian Georgescu <[email-masked]>
Date: Tue, 06 Jul 2004 14:14:54 -0400

For my understanding, user ENUM consists of already existing telephone 
numbers already in use by end-users. Provider ENUM consists of blocks 
of numbers assigned to providers which in term get assigned to 
end-users.

These number ranges if PROPERLY delegated based on existing E164 
numbering plans in place in each country do NOT overlap so they could 
stay in the same tree. Or do they?

Adrian
On Jul 6, 2004, at 9:09 AM, James Seng wrote:
how about not able to get a delegation needed in e164.arpa?
it is like saying we design this wonderful DNS system but no one is 
able to register anything under it.

james
Jim Reid wrote:

---

From: Jim Reid <[email-masked]>
Date: Tue, 06 Jul 2004 14:22:15 -0400

>>>>> "James" == James Seng <james at seng.cc> writes:

    James> how about not able to get a delegation needed in e164.arpa?

Huh? If an operator uses a private instance of e164.arpa for call
routing or whatever, no delegation is necessary. The telco just
creates an internal version of 1.e164.arpa (say) on their network and
they're done. That's all. It's that easy.

Besides, there are no reasons in principle why delegations are not
possible in the *public* e164.arpa tree. [For User ENUM obviously, not
Infrastructure ENUM.] Provided the relevant Administration approves
the request, any Tier-1 code can be delegated.  And anything below
that becomes a National Matter. So if you can't get a delegation under
your favourite country code, take it up with the authorities in that
country.