Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] tel URIsincommonpolicy

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 22 Aug 2005 13:23:00 -0400

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?

Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Peter Williams
> Sent: Monday, August 22, 2005 12:08 PM
> To: [email-masked]
> Subject: RE: [Enum] RE: [voipeer] Re: [Geopriv] Re: [Simple] 
> tel URIsincommonpolicy
> 
> 
> Concerning recharter,
> 
> We have to ensure that ENUM stays on an ENUM-specific 
> mission: while voice service issues are an important driver, 
> their impact on ENUM must be compartmentalized within the 
> supporting enumservices. Our mission (here) is
> high-level: "Internet convergence with the PSTN"; its not 
> "routing phone calls".
> 
> Let me put it another way - as a program manager, who 
> strategically vouched for carrier ENUM in the debate.
> 
> Because of the class of management requirement (mostly 
> security) that such as regulated voice services will bring, 
> we needed a _provider-based_ management model, in addition to 
> the user-based management model for data provisioning. The 
> adoption of carrier ENUM in the charter (if it happens) 
> convinces me that ENUM may have the architecture to succeed 
> in the intended operating environments.
> 
> Now that the religious phase of WG argument is over, we can 
> perhaps get back down to Internet engineering. If ENUM leads 
> DNS evolution in practice to
> (optionally) adopt just some of the most critical 
> provider-centric management practices learned other name 
> server infrastructure efforts, we will have made a big 
> contribution to the Internet's evolution. Small, incremental 
> infrastructure changes are what we are all about, after large 
> amounts of email.
> 
> ..showing that ENUM has all the necessary elements to support 
> regulated voice was an academic exam that ENUM had to pass: 
> but it's not actually the goal.
> 
> In our charter reformulation, we focus on the infrastructure 
> goals (now that we have the experience of discussion to 
> better formulate them), not the particular (but critical) 
> predictor of success.
> 
> Peter.
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
> 

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Peter Williams" <[email-masked]>
Date: Tue, 23 Aug 2005 00:53:13 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Michael Hammer (mhammer)
> Sent: Monday, August 22, 2005 10:23 AM

> 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.