RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] telURIsincommonpolicy

["Peter Williams" <home_pw at msn.com>]

> -----Original Message-----
> From: enum-bounces at ietf.org [mailto:enum-bounces at ietf.org] On Behalf Of
> Michael Hammer (mhammer)
> Sent: Monday, August 22, 2005 10:23 AM

> 
> Peter,
> 
> I find the statement that "it is not for routing phone calls"
> misleading.  Nodes that do an ENUM lookup for SIP voice setup requests,
> will in fact result in targeting one SIP endpoint versus another.  I
> call that voice routing, in addition to data packet targeting once the
> SIP address is converting to IP address.
> 
> Could you please elaborate?

View my comment in the context of program management - re-defining charters,
etc.

We rationalized Carrier ENUM based in part on the argument that regulated
voice services required the management practices that the PSTN's current
culture brings to the party. This addresses a bunch of legacy interchange
and security domain practices. Before we (the internet users, not IETF) kill
off that self-indulgent model - as we killed the ludicrous EDI interchange
model and its bogus security assurances - first, we embrace it.

So I making the simple point that I don't want the clear rationale for
Carrier ENUM to carry forward more than it should, to the charter revision.
We now have the necessary extra element (ADMDs and PRMDs based switching, in
Carrier ENUM form) in the armory suited for the war on regulated voip, buts
that all it is: another element.

Just because regulated voice motivated us to incorporate a particular set of
required ENUM capabilities in the overall architecture, does not mean that
all ENUM services will require that operational model. It doesn't even mean
that Carrier ENUM deployment model will prevail...

There is no notion that ENUM (and the NG DNS that ENUM really represents)
has been "skewed" a particular way, by this decision - or that the internet
architecture itself has taken a particular path. It hasn't. The convergence
will go in phases, that's all. The first phase is embrace. The next is
extend ($1 to MS, please).

For example. as members of an H.323 (over IP multicast, not PSTN) conference
join the group core in its virtual connect land, we might rather more
practically dynamically post the joining (aka connecting) user's E.164
address into a dynamically created tree, beneath a conferencing node -
purely to be helpful to the conference members. This could allow folks to
create PSTN-based H.323 sessions, in parallel to the multicast session.  
This has nothing to do whatsoever with getting the "connects" resolved, over
multicast group management! The simplistic hierarchical posting of entries
(beneath per-conference nodes) will definitely not serve H.323 over PSTN
switching needs! "ENUM is not about voice/conference switching/routing, per
se!" Its back to the venture pitch someone at Neustar made to me, 5 years
ago: do you know we have 2 billion people completely familiar with the
really effective name management system known as the 'phone number'....

So, with the general point and the somewhat contorted support example, I'm
merely attempting to debunk any notion that Carrier ENUM was ever really
about Internet religion. ENUM is bigger than voip - or the resolution of sip
URLs, or mapping SIP URI onto optional transport paths over IP or PSTN. Its
about PSTN convergence. Sure, we were missing a critical management model
element (told you so, ha!). But, now we have realize that, in the charter we
don't really need to do that much! If anything, Carrier ENUM just adds
clarity to the ENUM vision.

Peter.


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