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

From: "Peter Williams" <[email-masked]>
Date: Tue, 15 Jun 2004 12:34:39 -0400

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
_______________________________________________
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: Mike Hammer <[email-masked]>
Date: Tue, 15 Jun 2004 14:48:12 -0400

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.

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.

On 15 June 2004 pm 21:35, Yu, James wrote:
> Access control is a way to limited access to the service info. in carrier
> Also retrieving the service info. for a TN from Carrier ENUM does not mean
of cos. but *that is* outside the scope of ENUM  if we crawl higher and look
at other interoperability issues.
james
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum