Subject: Re: [Enum] User ENUM vs Operator ENUM

From: "Stastny Richard" <[email-masked]>
Date: Sat, 12 Jun 2004 11:59:11 -0400

>As someone who was also in Telco-purdah and so only with Internet
>access today,
>I'm impressed with the level of discussion on the ML in the last couple
>of days.

Me too, so the issue seems to get more interest then earlier,
and this may also give an indication that a BoF at the next IETF
is useful.
 
Before somebody starts asking what this mysterios meeting
at BT was, it was a mini ETSI TISPAN WG4 meeting scheduled
conveniently after the VON and dedicated to forward the ETSI
draft on infrastructure ENUM.
 
We did good progress in discussion, caused also by the fact that
it was a small but top-class group, consiting of Lawrence, Tony
Holmes, Marco Bernardi and Paul Rosbotham.
 
One item I can offer for the BoF is to present the status of
the discussion and the document in ETSI on the IETF.
 
Lawrence and James added nicely what I missed in my first
e-mail, but one item is still missing that was already discussed
in the last ETSI Meeting in Sophia Antipolis, also mention
at the VON in Mike Pluke's presentation on UCI and Personal User Agents,
and was again discussed yesterday.
 
This issue is of importance for the ENUM WG regarding "enumservices"
and is also related somehow to sipping.
 
It is for importance also for User ENUM, but may even be more important
for Infrastructure ENUM. iENUM is about information hiding: hinding
internal structures, hiding personal information and also hiding services
available. So a negotiation is necessary. on the other hand, as
already pointed out, the most important infromation in iENUM is
the operator, which means that in principle only one NAPTR
containing e.g. a SIP or h323 URI e.g. sip:\\1 at prov.net.
 
The enumservice to be used is the already proposed and discussed
service resolution service (srs), which indicates the fact that
the final communcation method to be used is to be negotiated by
the personal user agents.
 
regards
Richard

	-----UrsprÃngliche Nachricht----- 
	Von: Conroy, Lawrence (SMTP) [mailto:lwc at roke.co.uk] 
	Gesendet: Sa 12.06.2004 17:06 
	An: Stastny Richard 
	Cc: enum at ietf.org 
	Betreff: Re: [Enum] User ENUM vs Operator ENUM

	Hi Folks,
	  (recipients pruned - I suspect you're all on the ML :)
	
	As someone who was also in Telco-purdah and so only with Internet
	access today,
	I'm impressed with the level of discussion on the ML in the last couple
	of days.
	
	I second//third the comments on the VON - it was hectic, and interest
	in ENUM or
	ENUM-like systems is strong.
	
	As James S. says, the issue for some of the ITCSPs (i.e. lots of
	people, now that
	the bureaucracy has processed the EU Framework so that it's finally
	embodied in real
	live forms one can fill in and send off) is that one can get PSTN
	number ranges, but
	ENUM availability is at best erratic - bizarre but true.
	Note - there are a LOT of small ITCSPs "out there", so ENUM for
	interconnect
	is a "slam dunk" - it's about the only realistic way to do this stuff.
	
	One of the issues that came up both at the VON and afterwards is the
	way that
	sets of SPs can form into consortia/confederations/clubs. We discussed
	the concept
	of a "three ring circus" to try to classify interoperation modes.
	
	SP clubs in the "inner ring" allow "direct" SIP connections from one
	member's servers
	to a customer of another member. One might expect an example of this to
	be a single Company
	that provides service in more than one country (but judging from the
	way some such companies'
	divisions interwork, maybe not :).
	
	The next ring is a confederation of SPs who use an "IP Point of
	Interconnect" for sessions
	between members of the club, and so expose the Contact/Gateway
	information for E.164 numbers
	to members, but not to others (or to "the public"). Note - this differs
	in that the calls still
	traverse defined gateways rather than going "direct", but ENUM is still
	a pretty obvious choice
	to identify these IP POIs to other 'Club members'.
	
	Finally, in the outermost ring, the SPs don't use ENUM so all sessions
	have to go via a standard
	SCN/PSTN interconnect - the fact that a customer is "on VoIP" is no
	one's business. A degenerate
	case is a single Operator that uses ENUM "in-house" to route their
	sessions, but doesn't expose
	this to anyone else. From outside this barrier, it's a standard SCN
	provider.
	
	Now... note that in the middle and outer ring, there's no full mesh to
	end customers, so sessions
	traverse defined border elements. This is (I believe) tied in to
	Richard's comments that Infrastructure
	ENUM identifies the destination network and so supports routeing the
	session rather than delivering
	the session to the end user.
	
	user ENUM, OTOH, is about selecting between different sessions and/or
	delivering an end user's choice
	of URI  - this is not the same as iENUM.
	
	Thus it's perfectly possible to have both user ENUM domain content and,
	in addition, Infrastructure
	ENUM domain content, and they need not be the same, even when queried
	from the same place. For example,
	I could have a user ENUM domain for +441794833000 with a NAPTR that
	points to tel:+441794511603.
	The originating end user (or the system that acts as their agent) could
	decide to place a call to this
	number, and make a request of "the Infrastructure" to set up the call.
	Then, the SP might look up this destination number in Infrastructure
	ENUM to find out how to route it,
	and could find that it's possible to send it to an IP POI, or even
	directly to a SIP URI (as this is a
	"VoIP customer" and the SP is part of a close-knit club that allows
	such direct connection).
	I'd expect the "CSP of record" for +441794511603 to have complete
	control over population of the content
	for the Infrastructure ENUM domain. Conversely, it's perfectly possible
	for there to be a user ENUM
	registration for this that might include content that the originating
	user doesn't want to use in this
	case; nevertheless, it's still under the control of the customer who is
	provided service via this E.164
	number - NOT their SP.
	
	In short, whilst split horizon will almost certainly be useful in the
	three-ring circus of SP clubs,
	it's very tricky to use one tree for both user *and* Infrastructure
	ENUM as there may be two sets of
	data for the same ENUM domain (even from the same querying node's
	perspective).
	
	One last joker in the pack:
	It's possible/probable that the Infrastructure ENUM content includes
	Routing numbers. Not only are these
	of no earthy use to an End user as they can't place a call using them,
	they may not be much use for every
	SP either, even if they're exposed to all Operators.
	For example, a RN is often not usable outside a particular country.
	Thus it's important that such entries
	include the "phone context" as well, so that processing at an
	originating SP is easier - it must be given
	enough information to know that it can't use this entry directly, but
	needs to find a transit that can.
	
	... and with that, back to your normal service (and back to the BCP for
	me).
	
	all the best,
	   Lawrence

	On 12 Jun 2004, at 10:45, Stastny Richard wrote:
	> A short recap of  the status:
	>
	> On one side you have User ENUM, which means this is End-user to
	> End-user on the
	> Internet. This implies that the calling user has direct access to the
	> data in the DNS and
	> also can do something with the retrieved data. It also implies that
	> the called user
	> has direct or indirect managing access to the data in the DNS,
	> especially he is provided
	> by his VoIP SP with a public accessible URI. It also means that you
	> may use the information
	> provided in DNS for establishing communication, but if you know the
	> URI you also
	> be able to establish the communication without using ENUM. ENUM is
	> only necessary
	> to establish communication form the PSTN because you cannot enter a
	> URI. It also
	> implies that there is zero termination charge to reach the called
	> party. User ENUM
	> should be implemented in e164.arpa, but could also be implemented in
	> other trees.
	> If in all trees the rule is obeyed that only the entity having the
	> right to use
	> the E.164 number in the first place is the domain name holder, a later
	> merging of the trees is not a problem.
	>
	>
	> On the other side you have operator ENUM: Operator ENUM is used to
	> route
	> calls between operators - as the name implies, and NOT end-user. So
	> operator
	> ENUM is all about linking controlled VoIP islands together. Other
	> buzzword coming into my
	> mind is walled-garden, termination charges, hiding of end-user
	> information, session border controllers, NGN, cable-networks, IMS,
	> 3GPP, MMS routing
	> etc..
	>
	> User ENUM and operator ENUM are orthogonal to each other regarding
	> opt-in
	> numbers, because operator ENUM can really be considered as part ot the
	> PSTN.
	> For opt-in ENUM entries, one looks first in User ENUM, and if no entry
	> is
	> found, he looks in a (or more) Operator ENUM trees, and finally as a
	> last resort
	> he dumps the call to the "real" PSTN.  Done correctly, he should find
	> the information
	> in operator ENUM finally always, especially if no conventional PSTN
	> exists in 5-10 years.
	>
	> On hack in this is the now created ENUM-enabled number ranges which
	> can only
	> be resolved in User ENUM.
	>
	> For operator ENUM the same applies as for User ENUM:
	> If in all trees the rule is obeyed that only the entity having the
	> right to use
	> the E.164 number in the first place is the domain name holder, a later
	> merging of the trees is not a problem (but see high-jacking below).
	> The only difference here is that
	> the domain name holder in this case is the operator, because there
	> is nor opt-in from the user, which also implies that either the
	> information
	> is not in a public DNS, not in a public accessible DNS, or if in a
	> public
	> accessible DNS, the information does not disclose any "privacy"
	> information.
	>
	> This means you may find in a domain related to a number e.g.
	> +4319793321 only NAPTRs in the form e.g.
	> sip:+4319793321 at provider.net,  which is in essencey
	> all what operator ENUM is about:
	> finding the operator or service provider hosting the number.
	>
	> One word about high-jacking of numbers: in User ENUM high-jacking
	> is an issue because the number exists on the PSTN and on the Internet,
	> at least for opt-in numbers (not for ENUM-enabled numbers).
	>
	> In operator ENUM high-jacking of numbers would not be a problem,
	> if zero-termination would apply and also if calls would only be routed
	> to the destination network (no transit function).
	>
	> This means, if everybody would put in operater ENUM only the numbers
	> he is hosting (and why should he put in other numbers, because he
	> cannot
	> terminate it), as said above, the whole could start out with 10
	> differnt trees,
	> but merging trees would not be a problem, because there would be
	> no "domain name disputes".
	>
	> There is only one problem with this: operator ENUM created by
	> con-federations
	> will also be used for transit routing:
	>
	> Take the following (virtual) example: US-cable operators aggree to use
	> a common "private" database to route calls between numbers hosted by
	> these cable operators directly between also privatly agreed upon
	> IP-based
	> Point of interconnect. All other calls will be routed to the "PSTN".
	>
	> Now one  UK-cable operator joins the club. The easiest thing to do is
	> to route
	> ALL calls to +44 to this cable operator via the PoI of this UK
	> operator. So ENUM
	> is used to find the terminating network (for the numbers the UK
	> operator is
	> hosting himself, and as a transit (bypass) network for all other
	> UK-numbers.
	> One could call this legal high-jacking ;-)
	>
	> The problem only starts here of another UK operator is joining the club
	> or if two trees are merged.
	>
	> To summarize:
	>
	> -User ENUM and operator ENUM are in principle
	> orthogonal and may co-exists.
	>
	> -Starting with more than one tree in both of them is not optimal, but
	> causes problems later when merging only if number or number-ranges
	> are high-jacked (legally or illegally). So having a parking tree
	> besides
	> e164.arpa for user ENUM is NOT a problem if some minum rules
	> are obeyed
	>
	> If  User ENUM or Operator ENUM finally survives is not decided
	> by ENUM, it will be decided in the battle between NGN vs Internet
	> (or Zero termination vs Termination charges)
	>
	> best regards
	> Richard
	>
	>
	>
	> _______________________________________________
	> enum mailing list
	> enum at ietf.org
	> https://www1.ietf.org/mailman/listinfo/enum
	
	--
	
	Visit our website at www.roke.co.uk
	
	Roke Manor Research Ltd, Roke Manor, Romsey, Hampshire SO51 0ZN, UK.
	
	The information contained in this e-mail and any attachments is confidential to
	Roke Manor Research Ltd and must not be passed to any third party without
	permission. This communication is for information only and shall not create or
	change any contractual relationship.

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

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 16 Jun 2004 00:43:35 -0400

Since (at least in User ENUM aka e164.arpa) the should
be the domain name holder of the domain corresponding to 
the E.164 number and therefor should be able to modify the
contents of his domain, he may change the URIs pointing
to his service providers, what could be understood as number 
portability (changing his SP). He may also transfer the domain
from one ENUM provider to another
 
This only works if the delegations are done (sorry Patrik, this
was the main reason for the Tiers) directly from Tier 1 (the
national level to the Tier 2 (the level containing the NAPTRs)
 
Since NP is not an issue between countries ;-), this grouping
is possible (also for national policies). There could be a Tier1a
and 1b for various reasons (e.g +1) or a grouping according
to differnt number types e.g. 800 numbers will always be 
800 numbers.
 
So NP is not an issue in User ENUM. It is an issue
in Infrastructure ENUM  because operators again
want to have block delegations for simple routing
to gateways and hiding of information.
 
Although in some countries NP is only necessary
for "public available telephony services" (PATS) and
most VoIP services are non-PATS (this terminology is
EU centric) = ECS (electronic communications services),
we should provide for NP from the beginning to avoid
later hazzles.
 
We should also not forget the block allocation was the
number 1 reason for number exhaust. If new number ranges
used for VoIP are handed out with block size 1 there will
be more numbers available then now in use.
 
Richard

	-----UrsprÃngliche Nachricht----- 
	Von: Mike Hammer [mailto:mhammer at cisco.com] 
	Gesendet: Di 15.06.2004 20:25 
	An: Peter Williams; jseng at pobox.org.sg; enum at ietf.org 
	Cc: 
	Betreff: Re: [Enum] User ENUM vs Operator ENUM

	Peter,
	
	Speaking of operational and inter-operability issues, assignment of blocks
	of numbers to service providers and the marketing "stickiness" of users not
	want to change their phone numbers was only recently alleviated by number
	portability in the PSTN and mobile networks.
	
	ENUM inherits this issue when they use E.164 numbering scheme.  Yet, I keep
	hearing on this list references to handling of blocks of numbers.  Although
	these numbers can be hierarchically structured, the reality may be more
	like batches of random numbers.  The probability is that a number block of
	any size will diminish as the number of service providers (operators)
	increases.
	
	I would hope that the probability that numbers will frequently migrate,
	increasing the possibility that every other number in a sequence belongs to
	a different user or service provider, will be a prime consideration for the
	administration and operation of the ENUM directory structure(s?).  I am not
	very confident of this at the moment, but hope to be shown that number
	portability in ENUM is not an issue.
	
	Mike

	At 09:23 AM 6/15/2004 -0700, Peter Williams wrote:
	>James,
	>
	>The nature of ENUM - as a telematic service - has strong parallels to EDI,
	>and PKI/VPNs in its likely provider-centered adoption practices. As a
	>white pages-style directory service mapping PSDN and PSTN NSAPs to names
	>in name spaces manged by late 1980s-style name servers, it obviously has
	>strong parallels to Steve Kille's & other's X.500 efforts (and
	>Marshall/Einar's NADF efforts just outside of IETF) in the 1990s. In all
	>these cases, we have experience of the operational and adoption arcs. When
	>rescoping the WG work targets for ENUM, now, we may be able to articulate
	>a rationale for any new work by specifically asking: so what is the
	>consensus on expected ENUM deployment and operations, today - and compare
	>these goals to the experience from the parallels?
	>
	>There is a strong tradition in certain large US companies that standards
	>making is always about market making. The investment made to get a
	>standard adopted requires payoff - in the form of capturing a large
	>market, all in one go. This tradition has become more prevalent in IETF
	>over the last 10 years! as the IETF has adapted to the business investment
	>climate it necessarily operates in.
	>
	>If one structures the standards right, one can protect the future revenue
	>stream of such a capture - by creating barrier's to entry in the
	>operational phase. Structuring proprietary management processes abound
	>standards adopting the provider/supplier architectural design pattern is
	>one such technique: proprietary security is another: enabling bilateral
	>fee arrangement and token counting are a third. Management, security and
	>billing are the commercial value-adds - that properly justify future
	>service fees - that are worth protecting, today.
	>
	>In my view, if adoption depends on standardizing elements currently deemed
	>out of scope, we standardize them. Looking at the current scoping of a WG
	>and the practices of defending that scope is one way of understanding the
	>(entirely legitimate) motivations of the commercial players - and their
	>assumed models of adoption and deployment. While these models may be right
	>for a portending provider's business, they may not be right for wider
	>community goals. In setting WG items, we have to consider arguments wider
	>than the advocacy of the large companies.
	>
	>I reiterated my position in the opening of this memo ( as someone who has
	>a certain anguish about his historical role in fixing the un-IETF (but
	>perfecty legitimate) behaviour of VeriSign in internet-style standards
	>making, and as someone who sees evidence of others engaged (quite
	>properly) in technical marketing via standards). What I am unclear on is
	>the answer to the question, given the merits of the ENUM discovery
	>technology. Many of the ENUM characteristics suggest that
	>provider-centered, proprietary backroom management and security regimes
	>may be the right thing to do. If we go this operations route, we must do
	>so knowingly and openly, however.
	>
	>
	>
	>>From: James Seng <jseng at pobox.org.sg>
	>>To: enum at ietf.org
	>>CC: "'enum at ietf.org'" <enum at ietf.org>, "Yu, James" <james.yu at neustar.biz>
	>>Subject: Re: [Enum] User ENUM vs Operator ENUM
	>>Date: Tue, 15 Jun 2004 21:58:05 +0800
	>>
	>>On 15 June 2004 pm 21:35, Yu, James wrote:
	>> > Access control is a way to limited access to the service info. in carrier
	>> > ENUM if the carrier community does not want the general public to access
	>> > that info.    Whether and how to do it are implementation issues.  This
	>> > subject is certainly not one we need to discuss here.
	>>
	>>why not? ops have always been discussed in ietf.
	>>
	>> > Also retrieving the service info. for a TN from Carrier ENUM does not mean
	>> > the call/message/transaction processing may continue.
	>>
	>>of cos. but *that is* outside the scope of ENUM  if we crawl higher and look
	>>at other interoperability issues.
	>>
	>>james
	>>

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 17 Jun 2004 05:00:44 -0400

James Baskin wrote:
 
> On Tue, 15 Jun 2004 at 16:33:09 -0400, Richard Stastny wrote:
> >
> RFC 3761 states:
> <!--StartFragment-->
> Holders of E.164 numbers which want to be listed in DNS
> should contact the appropriate zone administrator according to the
> policy which is attached to the zone.  One should start looking for
> this information by examining the SOA resource record associated with
> the zone, just like in normal DNS operations.
> Of course, as with other domains, policies for such listings will be
> controlled on a subdomain basis and may differ in different parts of
> the world.
> <!--EndFragment-->
> 
> Nothing in RFC3761 distinguishes categories such as end user or carrier.
> I believe it is incorrect to equate e164.arpa with "user ENUM."
> What Richard describes, above, might be a description of the policy for
> a particular domain, but the policy could be very different in other
> domains.
> A policy could be developed that provides for both user-controlled and
> carrier-controlled (infrastructure) NAPTRs in the same domain.
>
[Richard>] It is true that RFC3761 does allow for user and carrier ENUM
implementations, but 
1. all other bodies (ITU-T, ETSI and all other For a dealing with e164.arpa
assumed (maybe wrongly) that the end-user is in control of the domain 
corresponding to his E.164 number and they assumed also that e164.arpa
is opt-in (both for calling and called user, to use PSTN terminology)

2. Opt-in for the calling user also means that the end-user may query
ENUM by himself and gets a useful result back (e.g featuring a Snom or
an IX66).

If you mix now user and carrier ENUM in the same domain, looking up a 
E.164 number in e164.arpa will be a lottery. With some country codes
or even operators you get a useful result back, in other you don't.
I cannot imagine that you can sell this confusion to a user.

But there are other problems too (see below)
 
> There has been talk about user/public ENUM and Infrastructure ENUM
> (iENUM) being orthogonal, with the conclusion that they must be handled
> in separate domains.  I don't see the logic in such a conclusion.  If,
> for example, a different Enumservice were registered for iENUM, then
> an iENUM NAPTR could easily coexist with user-specified NAPTRs for
> other registered Enumservices in a single ENUM tree -- no split DNS,
> no other undesirable DNS options needed.
[Richard>] I do not think that this can work. Even if the structure
is the same (every fully qualified number exists in the tree), you 
would have two domain name holders: the user and the operator
Q1: who decides on the Nameserver operator, especially if the user
is or is wanting to operate his own NS (a company)
Q2: Who is admistrating the access right
Q2: how do you distinguish between ENUM and iENUM NAPTRs (different
services, different flags, ...?)

What is worse is that user ENUM and infrastructure ENUM may require
different structures. Operators like block delegations. The whole idea
is a nightmare administratively.
> 
> (Question: Would it be possible for one NAPTR to exist in a particular
> level
> of the ENUM tree along with NS records pointing to a lower level that
> contains additional NAPTRs for different Enumservices?  (E.g., to allow
> a user to control the domain where those additional NAPTRs reside.))
> 
> Please forgive me if I have used incorrect terminology or if the
> suggestion
> violates some rule of DNS operation.  Flame me, but also tell me where
> I have gone wrong.
[Richard>] No need to flame, the issue is tricky and it took us a while
to find this out. The answer is yes and no.

The basic problem is: you may place NAPTRs anywhere in the tree together
with NS records (at delegation points), but you just do not see them. 
The good thing (?): you may not control the domain, if at least one
Delegation is made. The bad thing: you may not define default NAPTRs
for the number range (easily).

The reason is: if you query a FQDN und this FQDN does exist, you get
the NAPTRs back in the FQDN, you never see the NAPTR above.

Example: you query +43 1 797284032 (my office extension), you get
back a NAPTR. If there is also a NAPTR in +43 1 7972840, you just
do not see it (note: I am using E.164 numbers in this example to stay 
sane, the reader may convert this to 0.4.8.2.7.9.7.1.3.4.e164.arpa
on his own ;-)

What is even worse: if you query +43 1 797284077 (a not existing
extension, you get back NXDOMAIN. It would be nice at least in this 
case to get back the NAPTR in +43 1 7972840, but DNS does not do this.

The only way to get back a NAPTR in this case would be to put
in a wildcard NAPTR in +43 1 7972840 and do no other delegations.
This could be used for routing of whole numbering blocks as long
as not ONE single number is delegated (e.g. ported) somewhere else.

Thanks to Jim Reed we found another solution: you may put in a normal
NAPTR there and if you get back an NXDOMAIN for +43 1 797284077, you 
get also back in the response the enclosing zone, which would be
in this case +43 1 7972840. Now you may do a second query for
this domain and may get the NAPTR.

> NAPTRs are not restricted to a particular level, are they?.
> 
> Number portability can be an issue for every number regardless of
> the origin of the "call."  A receiving service provider may need
> to determine where to deliver the call based on porting information.
> But if the NAPTRs associated with a number in ENUM always relate
> to the current end-user assignee, then as far as ENUM is concerned,
> porting is not a technical issue.  It is taken care of in the
> registration process.
[Richard>] 
Again yes and no: In user ENUM you are correct, because the 
user is selecting (porting) the application service provider.
(but if he changes registrar and NS Provider, this also may
be considered as "porting" = domain transfer)

With carrier ENUM this is different. Porting would imply that
The ENUM entry changes and since the carrier is also the domain
name holder changes, this would also imply a domain transfer.

There are ideas not to force NP on VoIP number ranges, but this sure
will come sooner or later (why not?). So if you start with block
delegations and wildcards, you run into problems as soon as the
first number ports out (the above described functionality may
be a solution to this problem). Onward routing and anchor providers
are not a good idea to be introduced on IP.
> A VoIP service may be considered non-PATS in some places,
> but aren't most of those using proprietary (non-E.164) naming
> schemes?  
[Richard>] No, most of them are using spezial number ranges
defined for VoIP. The ones you are talking about (e.g. FWD)
are not even considered non-PATS (non-non-PATS?)

>I would be surprised if many countries would allow
> assignment of E.164 numbers for VoIP in a non-portable manner
> in the long term.  
[Richard>] agree, see above
>I guess this is what Richard is implying.
> (I would also guess that most countries will insist that VoIP
> services using E.164 numbers should be dialable from the PSTN,
> without the originating or intermediate carriers needing to do
> an ENUM query, but that isn't a discussion for this list.)
[Richard>] just for completeness: there are two types of number ranges
currently deployed for VoIP:
1. block assignment and routed to the PoI of the assignee
(if portable, you need an IN LNP query on the PSTN). This
numbers do not need to be in ENUM.
2. ENUM enabled numbers: the whole number range needs only to be
routed on the PSTN to the "nearest" so-called generic gateway
The gateway queries ENUM and routes the call further. Any
GW can be used. In Austria such a number range has been assigned
already (+43 780). The advantage here is that if you have
such a gateway in your originating network, you may route
ALL such number ranges via this gateway.

Regards
Richard
> We are in agreement here.
> 
> Jim
> 
> 
>

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 17 Jun 2004 09:37:38 -0400

Jim Reid(!) writes:
> 
> >>>>> "Richard" == Stastny Richard <Richard.Stastny at oefeg.at> writes:
> 
>     Richard> Considering the latest discussions and also looking at
>     Richard> what ENUM currently is used for, the original idea of
>     Richard> having all communications via one number does not seem to
>     Richard> hold anymore.
> 
>     Richard> 1. ENUM is mainly used for voice calls or telephony
>     Richard> related services (e.g. SMS/MMS)
> 
> This may be true today, but I feel it misses the bigger picture. The
> real power of ENUM comes from the flexibility of NAPTR records and
> what they can represent. ENUM is just a way of transforming someone's
> phone number into a bunch of NAPTRs that can do just about anything.
> So a phone number effectively becomes an access mechanism for anything
> that can be expressed as an URI: ie pretty much anything.
> 
> IMO it's unwise to get into a mindset that ENUM is just about voice or
> VoIP or telephony services. ENUM shouldn't be constrained to only these
> things. [Just like how IP datagrams weren't restricted to only getting
> carried over the ARPAnet or even ethernets.] The real innovation in
> ENUM will be when people come up with new services and applications
> that use NAPTRs in ways we've not yet imagined.
> 

[Richard>] I fully agree, but you know I always was open for both
approaches. This is also why I oppose the idea to merge iENUM and
user ENUM in one tree, because then the operators will take over and
the user may not be able to add own NAPTRs.

I also do not see a privacy problem if a hotel or company is putting
a NAPTR in pointing to their webpage or the geoloc of their place.

IETF always insisted on the end-to-end principle and for a good reason,
although there had been many attempts to break this. The Internet would
not be what it is today. BTW, some people say if we would today start
the Internet, it would never happen.

Privacy and security should be provided, but also the user has
some responsibility. 

Richard

---

From: "Peter Williams" <[email-masked]>
Date: Thu, 17 Jun 2004 14:05:10 -0400

In the X.500 secure directory experiments, we had a 'phone number to fully 
distributed directory reference(s)" service. It was a side-effect of using a 
fully-inverted structure for the data set - where every attribute was an 
local index. The entire lookup algorithm was generalized - take an 
attribute, and find out the (always local) set of references to entries, 
some of which may be mastered elsewhere, and some of which may be cached 
locally. NAPTRS, DSEs, whatever.

In one fun experiment, as you wandered through the campus buildings, a 
sensor would track your location, and have the PABX forward your incoming 
call to the nearest extension. The X.500 directory was the underlying 
technique for representing this entirely local set of knowledge - linking 
one reference system to another. The phone/PABX company/administrator was 
not involved in any way - other than as the provider of unique, stable 
numeric identifiers, linked to a (possiby changing) physical location of the 
phone terminal. The phone switch/router was a client of the external end-end 
directory, not a registration database. I.e. the directory layered ontop of 
the registrations.

Now, as we know managing end-end public and large hub-spoke directories is 
hard - the accuracy problem being the hardest issue of all. And we all know 
the outcome of the IETF's X.500 adventure, and we all know that the only 
corporate critical, managed directories that are scaling AND getting adopted 
are based on LAN-discovery technology for saccess point knowledge 
distribution and trusted relationship setup (for secure services), rather 
than centrallised registration and administration. (Thanks Microsoft - you 
did it right, where many others did it wrong!)

But, its in the convergence of directory practies where ENUM has its place 
and opportunity in the internet, I feel. While academically, its a cute 
theory about SIP/T.323 references (secure and insecure) and their discovery 
(trustworthy and not), its also about merging two cultures - the highly 
accurate PSTN directories and managed registration world, and the Internet's 
ability to enable third-parties to develop and deploy wide-area innovations 
ON TOP of that infrastructure without hindrance.

What we have to contend with in IETF is that the registration business 
companies appear to wish to control ENUM deployment models through 
standards, WG scopes, etc - and they have fixed notions (and ongoing 
commercial wars) about the way those future management processes should work 
(given profit - a legitimate goal). While they properly represent the 
carrier community,  (much to my chagrin) even VeriSign ignores its roots in 
end-end auto-managed PKI and focuses on centralized (and covert escrowed) 
mandatory registrations. I.E. the very property (end-end, auto-managing 
systems - like unregistered SSL certs) which is necessary for the next 
internet service adoption phenomenon to occur, is the one that is being 
downplayed or even ignored.

We have to see evidence of strong end-end ENUM adoption for ENUM to proceed 
up the standards track. The easiest way of generating this would be for the 
carrier/registration lobby to show it supports this pattern - perhaps even 
that it actively fosters its deployment and adoption.

Richard