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

From: "Stastny Richard" <[email-masked]>
Date: Sat, 19 Jun 2004 11:22:21 -0400

Christian de Larrinaga [mailto:cdel at firsthand.net]  writes:

>Fullbrook Kim (UK)Sent: 18 June 2004 15:20

>>the only way forward which acknowledges privacy concerns seems to be
>>"Operator ENUM" and  not implementing open "User ENUM".

>Well perhaps for your company but I don't believe this is a general
>observation applicable to all.

>Privacy concerns as other operational issues differ between Operator and
>direct user usage of ENUM. These stem from the different ambitions for ENUM
>use and of course the existant regulatory frameworks that govern operators
>and of users themselves.

Fully agree

And to Kim: how and by whom should this decision be made?

IETF is not involved in this dicussion policy-wise and could "decide" 
by humming only anyway; there is no voting. 

Regulators can only decide on user ENUM
by not opting in for their country. Regulators have no say in infrastructure
ENUM, because this is a sole decision of the providers joining a
confederation. Confeds could also choose any tree they jointly decide upon,
it is not necessary to do it in a TLD. .tel is a mock attack.

BTW: this could be an advantage for Infrastructure ENUM,
so regulators watch out ;-)

So let's implement both and let the market decide.

Richard

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

---

From: "Peter Williams" <[email-masked]>
Date: Sat, 19 Jun 2004 12:39:37 -0400

Richard:
To Jeff: You know what my problem with all privacy advocates is?
They are trespassing my privacy by trying to limit my freedom of decision,
including my human right to make idiotic decisions ;-)

You perhaps not living in the US, where many corporate privacy policies 
exist (in fact are essentially mandated, with those who violate their 
required freedom of choice of publish or not being punished by their 
insurers).

While policy publication is effecitvely mandator, the policies are based on 
a big lie - one that actively deceives most users. Liberty and Freedom 
having different meanings in Europe from US: privacy is libertarian ideal 
protected by rights in the US, but you must assert them in the US for them 
to have any value. You must assert the expectation of privacy, and maintain 
evidence of the currency of that expectation to deter your counterarguer 
from asserting laches - the doctrine that make your older assertion 
valueless at the time the telco (or other party) violates its own rules.

If for example you do not read the privacy policy of //.com, you cannot 
assert your process rights to hold the company accountable to its policy - 
assuming the policy has any accountability rules to start with. And how many 
American users read it? Thus, how many Americans have any recourse in 
practice?

This is privacy marketing at its best. Perfectly reasonable way of making 
money ; sell the assurance of privacy, but provide 20% functionality for 80% 
of users.

So lets see what we can do better in IETF, for the wider internet culture 
that also addresses European and Asian ways of thinking about privacy - 
which may have different obligations.

E2U maps {numeric descriptor -> set of URIs.} where the tel class URI allows 
one to rewrite the descriptor, and thus restart the resolver at a new 
discovery point better turned to the architecture of that redirected 
numbering scheme.

And the URI can include https URLs, where the agent initiating privacyE2U 
can access a W3C capability/privacy policy in (Signed) XML, and the agent 
can access the SSL-layers negotiation of telematic communication 
requirements via the certificates exhanged in a realtime handshake with the 
user's policy server, according to IETF standards. Having established these 
parameters, neither XML or SSL need to be used further in delivering an 
actual telematic service once the E2U service completes.

So, we have in ENUM, via URI/URL resolution, all the mechanism we need for 2 
layer privacy enhancement of ENUM (PEEM WG?). SO lets start thinking about 
this for the BOF. We have via the W3C work the means of showing and 
involving users in setting up the privacy practices for a T.323 conference, 
so there n expectation and restriction policies can be resolved as a part of 
the DNS-based E2U discovery process; and we have the secure handshake of SSL 
which identifies the security association requirements than can parameterize 
the T.120 proxies the users invoke subsequently in order to commute the 
numeric descriptor into an actual telematic session via an instance of 
infrastructure ENUM for T.120 switches.

Peter.

---

From: "Stastny Richard" <[email-masked]>
Date: Sat, 19 Jun 2004 13:20:46 -0400

NO, I am not living in the US.
 
I will need some time to parse what you are proposing,
just a question upfront: are you serious?
 
I first thought you are proposing to route each call
to an US citizen through a lawyer (CFtoL) e.g. if I call you I get an
annoncement: "Talk to my lawyer first"
 
On the other hand I like your idea to replace US lawyers by BOTs ;-)
 
regards
Richard

	-----UrsprÃngliche Nachricht----- 
	Von: Peter Williams [mailto:home_pw at msn.com] 
	Gesendet: Sa 19.06.2004 18:31 
	An: Stastny Richard; jwkckid1 at ix.netcom.com 
	Cc: enum at ietf.org 
	Betreff: RE: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM)

	

	

	

	Peter.

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 22 Jun 2004 08:55:45 -0400

So privacy is already implemented within Cisco ;-)
It says that I have no right to send messages to this recipient.
Is the systemadministrator with Cisco also a lawyer?

This would also be a solution for privacy in ENUM:
You publish numbers but you cannot reach them
Problem solved
Richard

-----Original Message-----
From: Systemadministrator 
Sent: Tuesday, June 22, 2004 10:06 AM
To: mhammer at cisco.com
Subject: Unzustellbar: RE: ENUM Privacy (was RE: [Enum] User ENUM vs
Operator ENUM)

Ihre Nachricht hat einige oder alle Empfanger nicht erreicht.

      Betreff:	RE: AW: ENUM Privacy (was RE: [Enum] User ENUM vs
Operator  ENUM)
      Gesendet am:	22.06.2004 10:05

Folgende Empfanger konnten nicht erreicht werden:

      'Mike Hammer' am 22.06.2004 10:06
            Sie sind nicht berechtigt, Nachrichten an diesen Empfanger
zu senden. Wenden Sie sich an den Systemadministrator.
            <mail.oefeg.at #5.7.1 smtp;550 5.7.1 <mhammer at cisco.com>...
Relaying denied>

---

From: Mike Hammer <[email-masked]>
Date: Tue, 22 Jun 2004 18:32:48 -0400

Richard,
Not sure what you sent, but there is spam-checking software that may have 
filtered your message out for some reason (false positive).

Unfortunately a lot does still get through.
Mike
At 10:15 AM 6/22/2004 +0200, Stastny Richard wrote:
So privacy is already implemented within Cisco ;-)
It says that I have no right to send messages to this recipient.
Is the systemadministrator with Cisco also a lawyer?
This would also be a solution for privacy in ENUM:
You publish numbers but you cannot reach them
Problem solved
Richard
-----Original Message-----
From: Systemadministrator
Sent: Tuesday, June 22, 2004 10:06 AM
To: mhammer at cisco.com
Subject: Unzustellbar: RE: ENUM Privacy (was RE: [Enum] User ENUM vs
Operator ENUM)

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 24 Jun 2004 18:25:31 -0400

No, what Mike meant here is mcu simpler:
 
assume you have number +437801234567
so you have an ENUM domain
7.6.5.4.3.2.1.0.8.7.3.4.e164.arpa
in this domain you put a NAPTR with
e.g. enumservice E2U+sip
and a URI sip:437801234567 at bigtelco.com
 
within your SIP server the user jdoe gets an alias 437801234567
(or the other way round)
 
so only infromation somebody gets querying ENUM for
the number +437801234567
is in addition is the provider.
 
But user jdoe may still be reached via sip:jdoe at bigtelco.com
for somebody knowing this.
 
Richard

	-----UrsprÃngliche Nachricht----- 
	Von: Fullbrook Kim (UK) [mailto:Kim.Fullbrook at O2.COM] 
	Gesendet: Do 24.06.2004 10:45 
	An: 'enum at ietf.org' 
	Cc: 
	Betreff: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM)

	It's not clear to me exactly what you're suggesting here. 

	- If the DNS you're referring to is private then no concerns. 
	- If the DNS is publicly accessible then are you saying that in the DNS the E.164 number only has a domain name corresponding to it without a username   e.g. 12345678909 -> sip:bigtelco.com   ?  This would be an incomplete URI and would need some other mechanism to provide call routing to a specific user, perhaps a full ENUM DNS which is only accessible by Operators.  This "two tier" system would get rid of most of the privacy concerns but with the downside of some duplication of material.  Could be a solution worthy of further study.

	- If the DNS is publicly accessible with the URI in usual format e.g. 12345678909 -> sip:jdoe at bigtelco.com  then we are back to the same situation already described: anyone can "war dial" the DNS and build up a list of SIP URIs of subscribers which is effectively a publicly accessible phone book without "opt out".

	Kim. 

	-----Original Message----- 
	From: Mike Hammer [mailto:mhammer at cisco.com] 
	Sent: 22 June 2004 20:38 
	To: Jeff Williams 
	Cc: enum at ietf.org; Stastny Richard 
	Subject: Re: AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM) 

	<Original note edited> 

	I would argue that for any E.164 number in the form of a domain name that 
	is found within the DNS, if the resulting records point simply to 
	information of a service or a service provider address that does not 
	provide more information specific to an individual subscriber, then no 
	privacy violation has occurred.  Any messages sent to that address, be they 
	http, email, im, sip, h323, or whatever can then be handled on their own 
	terms.  Routing happens. 

  _____  

	========================================================
	This electronic message contains information from the mmO2 plc Group 
	which may be privileged or confidential. The information is intended to
	be for the use of the individual(s) or entity named above. If you are not
	the intended recipient be aware that any disclosure, copying
	distribution or use of the contents of this information is prohibited. If you
	have received this electronic message in error, please notify us
	by telephone or email (to the numbers or address above) immediately.
	========================================================

---

From: "Fullbrook Kim (UK)" <[email-masked]>
Date: Fri, 25 Jun 2004 05:11:57 -0400

Summarising what's being said here, making a call to <any e.164> is just mapped to sip:<any e.164>@telco.com  i.e. a call to 1234567890 becomes a call to sip:1234567890 at bigtelco.com    

If we stand back from the immediate ENUM issues here, would we all agree that the underlying intent in the SIP world is to move to a world of "user friendly" addresses (SIP URI)  rather than E.164 numbers ?  E.164 numbers are retained for compatibility reasons but this is a secondary form of addressing.

Given this, that the primary means of addressing SIP services is e.g. johndoe at bigtelco.com    this implies there has to be another mapping database behind the scenes to map the 1234567890  on to johndoe    This second mapping database would surely be an ENUM database accessible only by operators, thereby reinforcing the case for separating out "user ENUM" - which does the first mapping - from "Operator ENUM"  - which does the second ?   

While I'm quite comfortable with this model because it does deal appropriately with the privacy difficulties while also ensuring call routing is maintained, I am concerned that the deployment is now different to my interpretation of what the RFCs originally intended which is a single global domain structure.  We have a missing step which is to specify how the "Operator ENUM" structure is set up and separated from the "user ENUM".  A number of valid suggestions have already been made on this list but surely the first step is to gain agreement on this principle for the way forward, or propose an alternative which deals with the privacy concerns ?

Kim.

-----Original Message-----
From: Stastny Richard [mailto:Richard.Stastny at oefeg.at] 
Sent: 24 June 2004 21:26
To: enum at ietf.org
Subject: Re: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM)

 

<
FONT SIZE=2>But user jdoe may still be reached via sip:jdoe at bigtelco.com
for somebody knowing this.
 
Richard

        -----Ursprüngliche Nachricht----- 

        Kim. 

        -----Original Message----- 

        <Original note edited> 

  _____  

========================================================This electronic message contains information from the mmO2 plc Group which may be privileged or confidential. The information is intended tobe for the use of the individual(s) or entity named above. If you are notthe intended recipient be aware that any disclosure, copyingdistribution or use of the contents of this information is prohibited. If youhave received this electronic message in error, please notify usby telephone or email (to the numbers or address above) immediately.========================================================
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 25 Jun 2004 11:53:37 -0400

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

---

From: "Peter Williams" <[email-masked]>
Date: Fri, 25 Jun 2004 16:58:10 -0400

AFAIK, nobody was talking about violating any law. I just pointed out
that ENUM will cause "personal data" to be published in the DNS. In
the context that EU Data Protection law defines that term: ie
something that identifies a living person. If that personal data gets
stored on computers in the EU, the use of that data is subject to the
provisions of EU Data Protection legislation. That, Richard, is not
bullshit. It's a fact.
Under the US-EU protocol, US companies who violate EU data protection laws 
get some immunity from tort suits if they have the US-styled privacy 
policies - which address the issues the EU is concerned about for its users 
and its consumers. US Consumers here will also be subject to those rules, 
note, as they may cache the DNS ENUM data in address books, and in their 
home routers, etc.

The rash of privacy policies you see in the US is 100% induced by the threat 
of data protection suits, in European courts of American companies - for 
improper disclosure of personal data about EU persons in a manner not 
conforming to their stated policies (which must conform to a safe-haven 
clause in the US/EU protocol, furthermore.)

This whole issue in ENUM is complicated by the fact that IAB members are 
clearly setting the standards and operational practices for ENUM, rather 
than an self-managing, self-directing IETF WG. Authority derived from DARPA 
research contracts (controlling .arpa via IAB member fiat) and authority 
from the DoC for ICANN need clarification to see where US stands on the 
US/EU protocol for DNS routing data that is personal in nature.

---

From: "Peter Williams" <[email-masked]>
Date: Sat, 26 Jun 2004 14:08:02 -0400

As I understand it, the DPA does not cover personal web sites or data
that I ask to be published; it covers the use of that data by the people
storing it. In the case of a web hosting service, that's the whole point
(i.e. it's what I'm paying them to do).
Many of these protection schemes that address privacy issues (both in the 
US, and the EU) regulate providers, who can be reasonably assumed to have 
subscribers with certain expectations about privacy. Privacy is a hard 
social issue, with no clear definition. However, there are accepted 
inflections in public law, statutes and administrative law. We have public 
data whose sole purpose is sharing, personal data that needs protection 
against unwarranted exploitation by third parties, private information that 
one secures appropriately with a technical mechanism, and other important 
categories.

Richard has a certain belief about the privacy expectations of all ENUM 
Provider subscribers, and argues (rather coarsely) his position. His 
argument is articulate, but rather unpursuasive, as the basis for his claims 
are his personal expectations as a subscriber. He happens to be a person 
with low expectations about certain elements of his personal data, viewing 
that data has necessarily public in order to achieve his individual 
communication goals.

Now, if you believe that the web hosting service has to find what personal
data I've just pushed to my web site, then notify the Government to say 
what
that data is and how they're using it, then we're in LaLa Land.
As a potential service provider, lwc, if your website is based on FrontPage, 
say, and it offers a registration and messaging module for others who can 
post memos to your site, YOU might be advised to pay a visit to the 
registrar. I would expect you to do this for any website YOU host at a third 
party service bureau, a web site you host yourself, or for a DNS server that 
you operate or cause to be operated - and which distributes personal data 
about others to others.

Your need to comply with data protection regulation, if any, is, "of 
course," a private and privileged disclosure matter to be shared by you and 
your legal advisor.

When the DPA first came in and the DP Registrar was totally overwhelmed 
with
paperwork flying in their direction; notification of personally published 
data
would be an absurdity that WILL be ignored as it would make that look like 
a
very quiet day in the office.
The US Federal government consider many suggestions made to address the 
problem of people setting and publishing their expectations of privacy.  It 
chose decentralized disclosure making, rather than EU-style registration of 
disclosures by central bodies; with obvioius impact on the ease by which the 
scheme could be engendered and indirectly managed into place over time, on a 
massive scale.

In the US commercial arena, the practices for expectation setting settled on 
placing obligations on the party with most control and the most to gain from 
exploitation - the telematic service provider. That is, certain (ambiguous) 
privacy expectations were presumed for all consumers, and a provider may 
disclose a policy in order to negotiate those expectations down to something 
acceptable to that person, engaging with the user as they subscribe, or as 
they use the service (if the providers policy provides notice of its ability 
to change) or if the user is not a susbcriber.

If one expects DNS Providers to do this is, then that random neural firing 
is,
in my opinion, equally bizarre.
An ENUM provider is not a classical DNS service provider: ENUM necessarily 
binds two name forms from two (or more than two) distinct naming 
authorities. the ENUM provider will be asserting control of that binding of 
different personal data items, much as a CA binds several personal names in 
its certificates. In each case, the ENUM provider goes beyond DNS, and goes 
onto exercise direct control over the delivery of privacy-enhanced (ENUM) or 
security-enhanced services in the case of ENUM service enhaced with offline 
certificate chain URIs.

While an EU TTP operating ENUM service may attempt to claim it is an 
unknowing outsourcing contractor supporting a relationship between a 
subscriber and a SIP-enabled  telco, the US TTPs currently fighting  for 
control of ENUM business through ICANN and IAB-related law suits are 
unlikely to proceed on this course: they need to assert control for their 
assurance to have much economic value: CISCO can provide critical 
infastructure-grade servers and operational knowhow to a telco just as well 
as it can supply it to ******, say, when acting as a TTP operating DNS 
servers mastering a critical infrastructure zone within .arpa.

In short:
If I want to publish my contacts, then "Get Your Tanks Off My Lawn".
If I want to control who gets to see what contacts, then I'll use
a PUA system, with a "global" entry in ENUM pointing to that.

Contracts suggest that the data is not personal in nature. While contracts 
often contain personal data, the use of the contract form already suggests 
the parties are quite sophisticated, and can negotiate privacy issues (if 
any) in the terms of the contract - probably with the advice of appropriate 
legal professionals. The terms may involve the removal of equipment from 
lawns, if the parties so desire, and can select any security- or 
privacy-filtering technology that the parties may agree to. In the UK, in 
particular, third party rights may be implied here, as third parties now 
have certain rights even though they are not parties to contracts  
addressing telematic services or information upon which they are induced to 
rely by the contracting parties.

The IETF and (eventually) IANA and the ITU/IAB have done their job.
But ICANN have not, and neither (in the US) has the DoC - in revising the 
procurement contract it places (and must surely revise) with ICANN to 
address ENUM - given ENUM must use .arpa delegated zones, by IAB mandate. 
The DOC actions must be publicly reviewed, and the influence of IAB over DoC 
must be similarly disclosed, if there is any. IAB is acting for and as IETF. 
Quite properly it discloses its ITU communications (somewhat late, note, for 
public input), and will surely and necessarily disclose its US government 
communications on the topic of ENUM regulation. We must recall that IAB has 
considerable influence over the technical standards controlling operators of 
those regions of the DNS it designates as critical infrastructure, and has 
had a history of assigning a critical infrastructure contract (to RIPE) 
showing coordination with the Internet Society on a topic related to ENUM, 
and disclosed in an Informational RFC specifically discussing ENUM planning.

I have a mechanism to do at least the global publication.
We have several mechanisms for performing the act of publishing personal 
data for distribiution by the DNS, and for use in delivering an 
IETF-standardized or a proprietary E2U-based telematic data lookup service. 
And there are IAB mandates essentially on how operators MUST then distribute 
and control the data that has been so published in the ENUM portion of the 
DNS. There is, also, evidence of attempts to scope an IETF WG session on the 
topic of amending the IAB mandate on the options for such distribution, 
taking input from a closed European Standardization organization; and there 
is evidence of specific and maintained resistance to the call for the 
sub-session addressing the possible change in mandate to consider privacy 
issues, as propery articulated by members of the IETF ENUM WG mailing list

Now, on the PUA stuff you can bury it in Legal issues until hell freezes 
over.
For the rest, it's my risk, and my choice. I don't live in California.
Unforuantely, CA law may address your activities, in much the same way that 
national laws derived from the EU directive in question threaten Americans 
with liability for their actions.
all the best,
  Lawrence
On 25 Jun 2004, at 20:15, Stastny Richard wrote:
<snip>
I know that people in the UK are paranoic about
privacy, e.g. 30% are unlisted in the phonebook,
in Austria this 5-10%. But UK is not really Europe.
<snip>
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Livingood, Jason" <[email-masked]>
Date: Sat, 26 Jun 2004 16:46:13 -0400

> AFAIK, nobody was talking about violating any law. I just
> pointed out that ENUM will cause "personal data" to be 
> published in the DNS. In the context that EU Data Protection 
> law defines that term: ie something that identifies a living 
> person. 

So I think the operative question then (in a perhaps futile attempt to keep
things simple) is whether or not a telephone number (either in standalone
E.164 structure 12346567890, or in a SIP URI sip:12346567890 at foo.com) is
indeed considered "personal data" or not.  I don't happen to believe it is
but then I'm not a lawyer either.  If someone can show a legal precedent for
this or make a good arguement to this effect, please do so.

Jason Livingood

---

From: Mike Hammer <[email-masked]>
Date: Tue, 29 Jun 2004 12:34:12 -0400

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'
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
> 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:
>

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 29 Jun 2004 12:45:23 -0400

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

> Sent: Tuesday, June 29, 2004 6:23 PM
> To: Stastny Richard; Livingood, Jason; enum at ietf.org
> > > > 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
> > > is trying to solve, I still don't see an answer.  IMHO, ENUM can be
> used
> > > by
> > > standards to meet for notifying or seeking the consent of  customers
> of
> > > the

---

From: Mike Hammer <[email-masked]>
Date: Tue, 29 Jun 2004 18:18:28 -0400

At 04:23 PM 6/29/2004 -0400, James McEachern wrote:
Mike,
   > 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)
Does this mean that ENUM is only available to numbers that have been
"ported out" to the IP-domain, and are marked as such in NP databases?
I was focusing on what happens to E.164 numbers that do port to the IP 
domain, but do not preclude the use for numbers that had not.  My issue was 
not so much for those that do use ENUM as it is for those E.164 users in 
the IP domain that do not have some minimal ENUM presence even in the form 
of a fronting carrier.

   >
   > 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)
I thought that the ENUM search returned the full URI, although in the case
of SIP the initial routing might be on the basis of just the domain.  Again,
in the case of SIP, isn't step 3 really performed by the SIP proxy the
target user has registered with, rather than by ENUM?
I was leaving the nature of the content of the local part of the URI to the 
agreement between the operator and the subscriber regarding privacy.  But, 
yes, in either case the routing of the call is a SIP operation, not an ENUM 
directory operation.

   >
   > 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 thought that Private (or Carrier, or Infrastructure) "ENUM" was orthogonal
to all of this, and could potentially be used even if the E.164 had never
been ported to the IP-domain at all.
That is possible.  I use the quotes around ENUM in this step, because the 
nature of the database operation is a local implementation issue, that 
could be structured as an ENUM database or not.  But, at this point the 
local part could be an E.164 number or some random variable.

Mike

Jim

---

From: "Peter Williams" <[email-masked]>
Date: Tue, 29 Jun 2004 22:07:55 -0400

From: "Christian de Larrinaga" <cdel at firsthand.net>
Reply-To: cdel at firsthand.net
To: "Peter Williams" <home_pw at msn.com>, <jim at rfc1035.com>
CC: enum at ietf.org
Subject: RE: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM)
Date: Tue, 29 Jun 2004 18:49:56 +0100
christian :--> Thanks for the clear presentation of this idea.
But does it matter if it is SSL or IPSEC with or without BGP4 policy? i.e.,
would it be better to allow user to define network architecture rather than
imposing SSL only for ENUM use as a one size fits all? Or have I
misunderstood you?

It does not matter. I would agree that we need to let IP networks be 
designed according to the way the edges actually require services to ve 
delivered.

I was thinking ahead by focussing on SSL VPNs, so we address the privacy 
issues created by E2U wholly within the IP stack.

Im not sure Jim's proposal requires any IETF standards action. Its a purely 
operational matter. As the IAB mandates are only Informational RFCs (and 
mainly a statement of intent about the purposes of the .arpa zones), there 
is nothing binding in them on any operator. There is no lack of compliance 
in using private DNS sources for E2U discovery.

Christian

---

From: "James McEachern" <[email-masked]>
Date: Tue, 29 Jun 2004 23:42:00 -0400

Mike,

 > To maintain parallel choices available in the PSTN, it would be good if
 > the
 > call originator (who might be conceivable paying for the QoS) could
 > choose
 > the long distance "carrier" used to reach the terminating service
 > provider
 > network.  But, I am not entirely sure what that would mean in the context
 > of ITSPs, ISPs, and current non-regulatory frameworks.  

I also am unsure what the concept of a "long distance carrier" would mean in
the context of the end-to-end model, and in a universe where Session Border
Controllers, NAT's B2BUAs and other evils do not exist.

 > I am absolutely
 > sure that making that choice possible so as to avoid the need for any
 > regulation would definitely be good.  I'm just hoping that those seeking
 > business advantage don't invite unintended consequences.
 > 
 > Mike
 > 
 >

---

From: "James McEachern" <[email-masked]>
Date: Tue, 29 Jun 2004 23:53:37 -0400

Mike,

 > domain, but do not preclude the use for numbers that had not.  

If an E.164 number has not been ported to the IP-domain, then would people
who dial the number from the PSTN ever see the results of an ENUM query?  Is
that acceptable?  Or is there an expectation that the PSTN switches would
have to perform an ENUM dip even if the number had not been ported to the
IP-domain?  Am I missing something?

 > My issue was

If an E.164 user in the IP-domain does not opt-in to ENUM, and does not have
even a minimal ENUM presence in the form of a fronting carrier, doesn't that
mean that it is not possible to reach them by dialing an E.164 number?
Isn't that likely their intent?

James

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 30 Jun 2004 03:36:27 -0400

Jim wrote:
> 
> Richard, *please* fix your mail software. It is very annoying to get
> needless base-64 encodings of UTF-8 that's actually just ASCII text.
> Even more irritating is finding a mail tool to translate that encoding
> back to ASCII so that your words of wisdom can be read. Grrr!
[Richard>] 
I told you already many times that I have to use Microsoft Outlook(TM)
Web Access if I am not in the office and that I have no choice here.

On the other hand, I consider UTF-8 as a valid standard and seemingly
most normal mail SW is able to understand it. Even the IETF archive
has been updated to decipher it.

Anyway, as a courtesy, I tried to send you a previous e-mail direct
via a different account, but this mail got rejected by your mail server
as spam and I was told to get lost.

This btw happened to others too.

Richard

---

From: Mike Hammer <[email-masked]>
Date: Wed, 30 Jun 2004 10:54:42 -0400

At 11:46 PM 6/29/2004 -0400, James McEachern wrote:
Mike,
If an E.164 number has not been ported to the IP-domain, then would people
who dial the number from the PSTN ever see the results of an ENUM query?  Is
that acceptable?  Or is there an expectation that the PSTN switches would
have to perform an ENUM dip even if the number had not been ported to the
IP-domain?  Am I missing something?
If you are calling from a TDM switch and the call should terminate to a TDM 
switch, then ENUM will likely not be involved.  I thought the earlier 
question was whether an ENUM entry for a number could exist that indicates 
to go direct to a PSTN GW, because it is in the TDM domain.

My original issue was that if a number had ported from TDM to IP domains, 
and a call is routed to PSTN GW, then when GW does an ENUM dip to try to 
further route it, it ought to have a hit and not a miss.  There is no sense 
having an E.164 number in the IP domain if you can not route a call to it.

If an E.164 user in the IP-domain does not opt-in to ENUM, and does not have
even a minimal ENUM presence in the form of a fronting carrier, doesn't that
mean that it is not possible to reach them by dialing an E.164 number?
That seems very likely.
Isn't that likely their intent?
I view using up an E.164 and it not being reachable as malfeasance.  Would 
it be acceptable to have a range of IPv4 addresses assigned, but not reachable?

The problem here is that there are both "names" (e.g. URI) and "addresses" 
(IP) on the Internet, but for PSTN the E.164 serves both purposes, which is 
why ability to route is a concern.

Also, to address another email comment, the "Inter" in Internet means that 
it is a "network of networks" where the interworking at GWs needs to work 
well.  And as I had noted before, the "opt-in" aspect is not compatible 
with the end-to-end principle, where addressing and routing are concerned.

Mike

James

---

From: "Peter Williams" <[email-masked]>
Date: Wed, 30 Jun 2004 12:39:12 -0400

As Peter suggested using Application layer tunnelling to captivate user
applications within these goldfish bowl domains I don't see why I shouldn't
use similar to get through and around them should they become a reality!

Christian
Dont get too upset at common practice. Privacy and control are orthognal 
axies of operational security. To get privacy, public ENUM providers (or 
their TTPs) wil have to cede some control. Security and Privacy via 
comparmentalization is a well understood practice.

IF we reason by analogy,PABXs have long had public number to private 
exchange number mappings, to save costs, and route the call across the 
preferred providers network (as selected by the PABX). Im not aware of the 
PSTN having collapsed because of a private zone was created to manage public 
E.164 names. Quite the opposite, US telcos started offering "VPN services" 
to manage those names way back in 1950!

Can the determined corporate user use a calling card, and use source routing 
via AT&T 1800CALLATT number to avoid the local poilicy? of course.

Im a security engineer; I dont get to trust provider or operator conformance 
to standards, or make assumptiosn that software works correctly