Subject: RE: [Enum] Opt-in principle for calling users and communications providers

From: Richard Shockey <[email-masked]>
Date: Mon, 02 Sep 2002 11:08:24 -0400

I'm here but I still think we are talking across each other

> >
> > > I do not agree. If there has to be always a termination on the
> > > conventional network, and if the service provider may do as
> > he likes,
> > > than there must be a way for the calling user to FORCE the phone
> > > system not to use ENUM.
> > >
> > > Otherwise it would make no sense to state:
> > > "All E.164 numbers must have a Public Switched Telephone Network
> > > (PSTN) point of interface."
> >
> > No. It only means for me that if you dial on PSTN that
> > number, you will get the phone connected to something. It
> > might imply you hit a gateway to VoIP which in turn gateway
> > the call to SIP, and you will get the call terminated.
> >
> > I.e. for me the sentence state that it must be possible to
> > make a voice call using the E.164 number in question. Not
> > that the termination point _for_the_voice_call_ must be on
> > PSTN. Only that the point of interface is on PSTN, and that
> > might be a gateway.
> >
> > This is already the case for many many E.164 numbers today
> > which is IP based.
>
>Now we are at the point, why we need BOTH "user ENUM" and "infrastructure 
>ENUM" independently.
>
>Of course you may have a termination on the PSTN which is really on VoIP, 
>because the phone system is technology independant. And it is up to the 
>service provider, how to find his users, and of course he may do this also 
>with ENUM. This may be an internal DNS application or one in the "public" 
>DNS under whatever tree.

I certainly see how a service provider may want to use DNS technology 
internally in his network for a "infrastructure ENUM".  If a service 
provider begins to decompose his internal TDM network with IP based 
Inter-Machine Trunking or places significant numbers of Media Gateways 
withing their network then it makes more sense to use DNS for things like 
inter LATA routing than SS7.

The more you use IP in a service provider network the more useless SS7 
becomes, since service creation is at the edge and data routing is a 
function of BGP etc.

These are private implementations that, I'm presuming, are not globally 
visible to the average user of the internet. The management of the 
e164.arpa namespace is specifically about what is globally visible.

What is interesting to me in this converged architecture is how can a Class 
5 switch determine IF the call can be terminated on a IP endpoint.  At 
point of call ingress it is assumed that the switch has several databases 
available to it in order to make a call routing determination of which both 
a public globally visible ENUM AND a privately provisioned IP endpoint/GW 
database is available as well. However the choice of internal endpoint 
database may or may not be DNS .. it makes no difference since it is not 
globally viable.

>BUT, this ENUM cannot be the e164.arpa, because there the entries are 
>controlled by the end-user and not by the service provider. I cannot 
>imagine a service provider having a "routing" database which can be 
>manipulated by the user, who may potentially break the service.

Of course ... but where we seem to be crossing paths here is the difference 
is that one DNS tree is globally visible and the other is not.

>Of course I do see your example that "you hit a gateway to VoIP which in 
>turn gateway the call to SIP, and you will get the call terminated", but 
>this is a two stage process:
>
>First the provider queries his ENUM to terminate the call e.g. on the 
>provider supplied personal user agent (PUA). The subcriber may now have a 
>normal SIP or H323 service and is currently attached to the Internet or 
>not. If not, the call is terminating on an announcement or forwarded 
>somewhere else.

No problem here ..you are doing a internal network look up , a basic 
IF/THEN problem ..if there is no entry in the _internal_ endpoint database 
THEN query the golbal enum db.

>The provider may also offer the subscriber in parallel an sip or h323 ID, 
>which may be used by the end-user independently on his own "user ENUM" 
>entry in e164.arpa to terminate the call from the Internet on the same PUA 
>(as envisaged with +87810)

Or actually on his PSTN endpoint as well, this could work either way +87810 
would not be necessary.  This is a excellent point ..I do believe service 
providers will offer to their customers sip addresses mapped to their PSTN 
endpoints. There is a business case and service logic for doing this. The 
sip address simply maps to a GW which then rings the PSTN phone...this is 
then a called party pays or a personal freephone like service.

>Alternatively the user may have an agreement with the service provider, 
>that any call incoming from the PSTN via the gateway is first hitting the 
>PUA (by querying "infrastructure ENUM", which in turn queries "User ENUM" 
>and then forwards the call another SIP or H323 termination.

Exactly

>This would BTW be a nice way to port a number from PSTN first to an IP 
>based provider and then out on the Internet;-)
>
>Richard

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza   Bldg 10    Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto:[email-masked]> or <mailto:[email-masked]>
<http://shockey.us > ; <http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 2 Sep 2002 18:08:38 +0200

> database may or may not be DNS .. it makes no difference 

I a converged architecture a originating class 5 switch could do this only if he is querying a globally available database, e.g. ENUM. Finally this will be an ACQ, but in the beginning there could be a pretranslation similar to NP (e.g. IP enabled CC NDC). In this database you either have an entry for every number or a wildcard for a numbering block, either pointing to a gateway directly or pointing to another database (e.g with an ldap URI). This is, I assume your _privately provisioned IP endpoint/GW database_.

You could use e164.arpa ENUM for this, but the problem starts, if you have, as you mentioned, a _public/globally visible AND a privately provisioned IP endpoint/GW database_.

As I already stated, both cannot be in the same ENUM database, first, because the user decides on the tier 2 registry and second and even more important, if the provider decides to have a wildcard in ENUM for all numbers in the block to point to a certain GW/database, and one user out of this block decides to go into ENUM on his own, the whole thing breaks apart.

So I still have the opinion, that we need two ENUMs and the originating switch has to query them one after the other. My proposal is, that normally the class 5 switch is querying the infrastructure tree first and then maybe, to keep some people out there happy, the user ENUM. 

Only if the calling user subscribes an _ENUM Preselection_ or does a call-by-call _selection_, user ENUM is queried first. The reason: at least at the startup of ENUM you will get in most cases a _404_. 

Regards
Richard Stastny

Richard STASTNY
OeFEG/Telekom Austria
Box 147, A-1103 Vienna, Austria
tel:+43 664 420 4100
fax:+43 1 797 80 13
mailto:[email-masked] 
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Richard Shockey <[email-masked]>
Date: Mon, 02 Sep 2002 16:37:46 -0400

At 06:08 PM 9/2/2002 +0200, Stastny Richard wrote:
>I a converged architecture a originating class 5 switch could do this only 
>if he is querying a globally available database, e.g. ENUM. Finally this 
>will be an ACQ, but in the beginning there could be a pretranslation 
>similar to NP (e.g. IP enabled CC NDC). In this database you either have 
>an entry for every number or a wildcard for a numbering block, either 
>pointing to a gateway directly or pointing to another database (e.g with 
>an ldap URI). This is, I assume your _privately provisioned IP endpoint/GW 
>database_.

Correct .. but this could start out as a private database exchange between 
cooperating service providers.  The problem statement you describe does not 
have to be a "end world hunger" solution in the beginning.  You are correct 
that this has some similarities to the LNP problem. Cooperating service 
providers could exchange end point/GW data privately to provision local and 
non globally visable DNS servers using either end point URI's or as you 
suggest LDAP look up's etc. The exchange of data could occur by any number 
of means ..or as the N(2) problem occurs some arrangement could be made to 
aggrate the data and then redistribute it to service providers in a 
mutually acceptable manner which then updates the local non-visable DNS 
servers (aka the new new SCP's).

If TRIP were introduced internally to a SP network then the global 
advertisement for endpoint resolution could be single hostname. TRIP then 
could hide the actual location of GW within the service providers domain 
boundry.

>You could use e164.arpa ENUM for this, but the problem starts, if you 
>have, as you mentioned, a _public/globally visible AND a privately 
>provisioned IP endpoint/GW database_.

Using e164.arpa for this is IMHO not a good idea since I ( as a service 
provider) would not want to expose business relationships between service 
providers in global DNS tree, should such data be exchanged.  This goes now 
to the heart of the convergence problem ... the Internet operates on a 
transit/peering model (aka bill and keep) while global TDM telephony relies 
on reciprocal compensation. The optimal transaction/business model in IP 
Telephony keeps OSS billing costs to a minimum.

>As I already stated, both cannot be in the same ENUM database, first, 
>because the user decides on the tier 2 registry and second and even more 
>important, if the provider decides to have a wildcard in ENUM for all 
>numbers in the block to point to a certain GW/database, and one user out 
>of this block decides to go into ENUM on his own, the whole thing breaks apart.

Of course which always argues for the full resolution of the E.164 number 
before determining the NS of authority global or non-globally visable.

>So I still have the opinion, that we need two ENUMs and the originating 
>switch has to query them one after the other. My proposal is, that 
>normally the class 5 switch is querying the infrastructure tree first and 
>then maybe, to keep some people out there happy, the user ENUM.

Yes  IMHO you are correct...a dual query model will need to be supported 
since it is clear that IP PBX's, for instance, will query e164.apra on 
their own and only require transit from their SP . Now the SP resolution 
model does not have to use DNS, LDAP might work ... its just useful since 
its there.  I have heard discussions that some SP's might look for a 
trigger in SS7 first to then dump the call into a MG where the ENUM query 
would be done.

I think you agree that there is much fruitful work to be done in this area. 
It is not clear to me at all how C5 elements will eventually discover that 
some endpoints can be reached over IP.

We could certainly whiteboard out a dozen or more ways to do this for both 
the C5 elements and the exchange of GW endpoint data between SP's for 
hosted or network oriented services.

That's why standards are wonderful ...there are so many of them! :-)

>Only if the calling user subscribes an _ENUM Preselection_ or does a 
>call-by-call _selection_, user ENUM is queried first.

Actually I think this is a _called party Preselection_ If I register my 
number in ENUM I have essentially stated that it is MY preference to have 
the call terminated to me on IP where I can establish more effective 
control..what the calling party want is irrelevant.

This again goes back to the core issue we were dealing with in Yokohama 
...where does call control reside.  I have taken the view that for privacy 
reasons and various others it is the called party that actually is in 
control of the call session ..not the calling party. I choose not to expose 
any data in the global DNS except the absolute minimum necessary to 
establish a session between who is calling me and my endpoints. I delegate 
to my SIP proxy or other SRS/Presence server the control of how/when and by 
what manner I choose to be contacted.

The opposite view ..is of course that the calling party wants control and 
want the maximum flexibility in selecting how and by what means the called 
party is contacted. This argues for what you and Ranali/Walter have 
proposed.  Both are legitimate technival views but I submit it is up to the 
end user to decide.

>The reason: at least at the startup of ENUM you will get in most cases a 
>_404_.

Yes its chicken and egg but I have noticed the hen's hard at work.

Best wishes.

---

From: "Stastny Richard" <[email-masked]>
Date: Tue, 3 Sep 2002 12:07:43 +0200

Hi Rich,

As we discussed this issue already, I think we both agree that this problem is very complex and in general I think we do not even know completely, what the problem is. And I see also from these discussions, that there are many different views and standpoints out there. So maybe we should take a step back and define the problem first and then discuss about solutions.

Anyway, one thing is obvious, if we want to upgrade/migrate/replace the global public phone system, we have to provide at least onother global and public phone system and not a mess of private databases. This was BTW one of the reasons, that IN was never really available for global services. All IN systems where only available _privately_ in operators networks or in some cases nationally, but never globally.

Rest of the comments inline
Richard

PS: I am still waiting for your input related to SG2 on service codes.

Richard STASTNY
OeFEG/Telekom Austria

> -----Original Message-----
> From: Richard Shockey [mailto:[email-masked]] 
> Sent: Monday, September 02, 2002 10:38 PM
> To: Stastny Richard; Patrik Fältström; Clive D.W. Feather
> Cc: Lawrence Conroy; [email-masked]
> Subject: RE: [Enum] Opt-in principle for calling users and 
> communications providers
> 
> 
> 

I even would not go into so much detail at the beginning, the first question is to give the originator a hint (pointer) where to find the destination (network or GW or whatever) for a given number. Thats what ENUM is for. The rest could then be done in your way (or in another).

> Telephony keeps OSS billing costs to a minimum.
The current model in TDM (for normal calls) is cascading, where the origination network bills the subscriber and cascades the money to the following networks, up to the destination network.
Maybe this model has to change anyway: e.g. every user is paying for what he is reponsible for.
We have this discussion currently with MNP, because we have no air-time and different charges to different mobile networks.

So the origination subscriber pays to reach the destination network, but not the destination network itself. If he his paying nothing to reach the destination network (or only the access) fine. It is then up to the called user to pay to be reached where he wants to be reached.
  
> That's why standards are wonderful ...there are so many of them! :-)
 
Ok fine, where and when?
 
> control..what the calling party want is irrelevant.

This is exactly what I said above: calling and called user should control and eventually pay for what they are responsible and what they can control.

If you look at the TIPHON model (see Pauls presentation at the NGN-Summit in Brugge), you have an originating user attached to an originating serving (access) network) who is calling via his home network (signalling) hosting the PUA the home network (PUA) of the called user. The called user may also be attached to a serving destination network. Between each of the four networks there may be additional transit networks, the media could finally go directly from the orig serving network to the dest serving network. What is payed IMHO in the future is mainly the access on both sides (fixed, ADSL, cable, GPRS, WLAN, etc.) and the hosting of the Personal User Agents (PUA) on both sides.

> what manner I choose to be contacted.

The privacy issues are handled by the PUAs, and you should consider that the calling party also have a PUA. In the UCI approach finally the PUAs will negotiate.

> proposed.  Both are legitimate technival views but I submit 

I think both sides have their share, as stated above.

Regards
Richard

---

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Tue, 3 Sep 2002 13:22:11 -0500

You missed my point on the third item.  Access control of records is not a natural DNS thing.  If using a separate root, I can use split-horizon techniques or filtering or custom server code or whatever... to limit outside access to particular records.  This is much harder to do with DNS technology with a single entry that covers entries subject to different privacy policies.

Again, as I said earlier, I am somewhat neutral as to which approach is taken.  My list was in response to your solicitation of negative aspects of the single-root approach.

Greg V.

>> 3) It is tough to have separate access policies and privacy 
>> constraints for records in the same entry, i.e., Opt-in for end-user 
>> services, mandatory but privacy protected for infrastructure entries. 
>> It is easier to have diverging policies and control under different 
>> roots.
>
>All of those requirements have to do with how the record gets in the zone
>which DNS has _zero_ to do with. If you have policies and privacy issues
>with how records get into the zone then it sounds like you want some of the
>more interesting features of EPP to maintain how/when records get inserted.

---

From: "Yu, James" <[email-masked]>
Date: Tue, 3 Sep 2002 17:47:52 -0400

Mike,

One problem is that number portability will impact ENUM even if the ENUM end
user does not change the Tier 2 Nameserver Provider (one that provider NAPTR
RR hosting service).  Those NAPTR RRs associated with the old telephony SP
must be removed and be replaced with those from the new telephony SP if it
has use of ENUM.  It would be a nightmare to do it over the ENUM
provisioning process.  Also another problem is who, the telephony SP or the
ENUM end user, decides which Tier 2 Nameserver Provider to use for hosting
the NAPTR RRs.  Telephony SP would not want to have their critical NAPTR RRs
on ENUM end user's nameservers (if may be just one nameserver if the ENUM
end user chooses) located in the basement.

James

> From: Michael Mealling [mailto:[email-masked]]
> Sent: Tuesday, September 03, 2002 11:17 AM
> To: Vaudreuil, Greg M (Greg)
> Cc: Richard Shockey; Stastny Richard; Patrik Fältström; Clive D.W.
> Feather; Lawrence Conroy; Rich; [email-masked]
> Subject: Re: [Enum] Opt-in principle for calling users and
> communications providers
> 
> 
> On Tue, Sep 03, 2002 at 10:10:15AM -0500, Vaudreuil, Greg M 
> (Greg) wrote:
> > I don't have a view as to whether these services 
> > require a separate root from the end-user services.  
> However, I thought 
> > we beat the separate root per service (or class of 
> services) down in 
> > favor of the NAPTR multi-service approach.
> 
> I thought we had too. In fact, I'd like someone to explain why simply
> designating "infrastructure" enum-services as opposed to 
> "user-designated"
> enum-services isn't sufficient? When the user signs up with a service
> they explicitly delegate the ability for their infrastructure provider
> to insert "infrastructure" class NAPTR records in there for them but
> that "user-designated" enum-services are still at the users 
> discretion....
> 
> What's wrong with that model?
> 
> -MM
> 
> -- 
> --------------------------------------------------------------
> ------------------
> Michael Mealling	|      Vote Libertarian!       | urn:pin:1
> [email-masked]      |                              | 
http://www.neonym.net
----------------------------------------------------------------------------
----
!! The Trailblazer spacecraft is going to the Moon! And for just $2500 a
gram !!
!! you can send something along with it! Business cards, momentos, cremains,
!!|| anything! See http://www.transorbital.net for details!
!!

---

From: Kevin McCandless <[email-masked]>
Date: Wed, 4 Sep 2002 06:19:24 -0700

James,

I fail to see how NP impacts ENUM.  If my number stays the same and that is
the url people use to resolve to obtain my URIs, then what has changed?  

Kevin...............

> From: Yu, James [mailto:[email-masked]]
> Sent: Tuesday, September 03, 2002 4:48 PM
> To: 'Michael Mealling'
> Cc: [email-masked]
> --------------

---

From: Kevin McCandless <[email-masked]>
Date: Wed, 4 Sep 2002 07:13:59 -0700

Well, the problem could be your assumption that the TSP would provide the
end user with infrastructure records, such as a SIP gateway address.  Maybe
the TSP would actual be smarter then this and provide only a pointer to the
registrant.  This pointer would be entered into their Tier II providers
database.  This pointer directs queries to the TSPs infrastructure database
the contains records for their gateway addresses.

Its all vapor ware right now ;-)

Kevin................

> From: Stastny Richard [mailto:[email-masked]]
> Sent: Wednesday, September 04, 2002 9:03 AM
> To: Michael Mealling
> Cc: [email-masked]
> MM wrote:
> > But why does it matter that they're different entities? My 
> > ISP and I are two different entities and we manage pretty 
> > well. It might have a few hickups in the beginning but it'll 
> > work itself out...
> 
> I see e.g. two problems:
> 
> If for example a TSP decides to use ENUM for pointing to his 
> SIP Gateway
> for his subscribers,
> e.g. to point to fixed line phones in his network.
> He may nicely fill up ENUM domains for these numbers (he may 
> even use a
> wildcard) in any Tier 2
> Nameserver (preferably his own), entering one NAPTR for each 
> number (or
> a one for a block) pointing to his gateway with a SIP URL to 
> be used by
> other operators.
> 
> He may also decide to query the ENUM database directly
> from his TDM network via an IN-mediation device to get some routing
> information (e.g. the CIC for ported numbers). In this case he would
> enter Tel URIs (eventually in addition to the 
> previously entered SIP URIs). 
> 
> Since he entering this information without asking the subscribers
> (especially in the second
> case, because this information is useless for a normal user querying
> ENUM).
> 
> Now the end-user, who has the number assigned, decides to 
> opt-in to ENUM
> and selects another
> Tier 2 Nameserver provider. Now the NAPTRs have to be 
> transferred to the
> new Tier 2 Nameserver
> Provider, taking the operators NAPTRs over. Fine, can be done, but the
> TSP now has to keep
> track of all transferred NAPTRs and the Tier 2 Nameservers. 
> If he wants
> to change now the
> gateway for a block of numbers, he has to change it in n Tier 2
> Nameserver providers one by one
> 
> Furthermore, users querying ENUM see different SIP, h323 and Tel
> records, some of them not 
> useable by them. So we would also need new ENUM services, e.g.
> E2U+foroperatoruseonly.
> 
> regards
> 
> Richard STASTNY
> OeFEG/Telekom Austria

---

From: "Pfautz, Penn L, ALVAP" <[email-masked]>
Date: Wed, 4 Sep 2002 10:16:43 -0400

Kevin:
I think that James was making the point that IF TSPs get special record in enum THEN NP complicates things, like chaging those records when the user changes TSPs. I agree there should be nmo impact on the subscriber records.

Penn

-----Original Message-----
From: Kevin McCandless [mailto:[email-masked]]
Sent: Wednesday, September 04, 2002 9:19 AM
To: 'Yu, James'
Cc: [email-masked]; 'Michael Mealling'
Subject: RE: [Enum] Opt-in principle for calling users and
communications providers

James,

Kevin...............

---

From: "Stastny Richard" <[email-masked]>
Date: Wed, 4 Sep 2002 16:27:13 +0200

> Sent: Wednesday, September 04, 2002 4:14 PM
> To: Stastny Richard
> Cc: [email-masked]; Michael Mealling
> Well, the problem could be your assumption that the TSP would 
> provide the end user with infrastructure records, such as a 
> SIP gateway address.  Maybe the TSP would actual be smarter 
> then this and provide only a pointer to the registrant.  This 
> pointer would be entered into their Tier II providers 
> database.  This pointer directs queries to the TSPs 
> infrastructure database the contains records for their 
> gateway addresses.

One possibility, of course, but this does not solve the problem of two
enties with different interests in the same domain. I as an operator
want to use ENUM for my purposes (whatever they are) and the End-User
(Registrant) wants to use ENUM for his purposes. The operator does not
want the user to fiddle around with his recors and vice versa. And there
is still the question who decides the tier 2 selection.

> > enter Tel URIs (eventually in addition to the previously 
> entered SIP 
> > URIs).
> > 
> > (especially in the second case, because this information is useless 
> > for a normal user querying ENUM).
> > 
> > records, some of them not useable by them. So we would also 
> need new 
> > ENUM services, e.g.
> > E2U+foroperatoruseonly.
> > 
> > regards
> > 
> > Richard STASTNY
> > OeFEG/Telekom Austria

---

From: "Pfautz, Penn L, ALVAP" <[email-masked]>
Date: Wed, 4 Sep 2002 10:25:58 -0400

Mike:
Indeed, the model you describe was one James and I considered, and I believe it may have been in the back of some minds in the initial thinking about ENUM. It certainly is simpler. But number portability and local service competition, at least on the US, seem likely to preclude it's implementation.

-----Original Message-----
From: Michael Mealling [mailto:[email-masked]]
Sent: Wednesday, September 04, 2002 10:08 AM
To: Pfautz, Penn L, ALVAP
Cc: Michael Mealling; Stastny Richard; [email-masked]
Subject: Re: [Enum] Opt-in principle for calling users and
communications providers

On Wed, Sep 04, 2002 at 09:53:07AM -0400, Pfautz, Penn L, ALVAP wrote:
> Mike:
> The subscriber vs infrastructure issue gets rapped around the 
> competition axle. 

I figured that was part of the problem...

> We need to allow the subscriber to choose their Tier 2. 

Divorced from the number they have? I.e. I get a number from Verizon
but I get Sprint to handle my DNS? Or are we talking about TSP's who
are completely third party? I.e. neither the end-user or the number
asigner.

> But the TSP may not like the subscriber's choice of Dingbat's DNS 
> and not want to rely on their service  for infrastructure needs.

I was suggesting the opposite way: the TSP who assigned the number
chooses the DNS provider and the customer and that TSP cooperate
in provisioning the zone...

> In some of the early I-Ds we tried to work out how the TSP could have 
> special records but in the e164.arpa tree at the the number assignee 
> selected Tier 2. It *was* ugly and, since no one seemed anxious at the 
> time to pursue the TSP record idea we dropped it.

(I'm starting to fall all over the acronyms)...

The logical method from my point of view is I call up Bellsouth and say
I want a number and I want the co-provision option for that numbers DNS
entries. Bellsouth gives me a web page and an ID and I create DNS entries
for it. If Bellsouth is nice enough or if I buy the option they might even
give me the ability to handle the nameserver. Anyway, if I want some third
party service that needs to administer an particular NAPTR record in there
I give them a special userid and password for doing that...

I'm probably missing something important about telephony though. But that
would work for me....

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net
--------------------------------------------------------------------------------
!! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !!
!! you can send something along with it! Business cards, momentos, cremains,  !!|| anything! See http://www.transorbital.net for details!                     !!

---

From: Kevin McCandless <[email-masked]>
Date: Wed, 4 Sep 2002 07:24:17 -0700

Penn:

Glad you chimed into the thread.  If TSPs are going to populate registrant
records with authoritative database information, LNP for example, then there
is a major risk that this information will no longer be authority if it
becomes under the control of the registrant.  Since the registrant can use
any Tier II provider they want why would a TSP take this risk?  My only
suggestion is that the most a TSP would be willing to risk is a pointer in
the registrants NAPTRs that would redirect the query to the TSPs
authoritative database.  This would allow the TSPs database to remain
authoritative and remain COMPLETELY within their control.

K.............

> From: Pfautz, Penn L, ALVAP [mailto:[email-masked]]
> Sent: Wednesday, September 04, 2002 9:17 AM
> To: Kevin McCandless; Yu, James
> I think that James was making the point that IF TSPs get 
> special record in enum THEN NP complicates things, like 
> chaging those records when the user changes TSPs. I agree 
> there should be nmo impact on the subscriber records.
> 
> Penn
>

---

From: "Yu, James" <[email-masked]>
Date: Wed, 4 Sep 2002 11:42:13 -0400

Kevin,

On a second thought, one way to use the pointer is to use the "replacement"
field to point to the TSP's server(s).  This would require that the ENUM
client to know that it wants to retrieve TSP's NAPTR RRs and will use the
domain name in the replacement field to get to that place.  There must be a
clear indication in the ENUM service field that a particular NAPTR RR is a
TSP's NAPTR RR so that the ENUM client can ignore the non-TSP's NAPTR RRs
and try to go the next step to retrieve the TSP's NAPTR RRs (this point was
raised in an early e-mail by Richard S.?).

The order and preference values of the end user's and the TSP's NAPTR RRs
further complicate the problem.  Either one may want to set its NAPTR RRs to
have a higher order/preference value.  Need a rule to regulate how the end
user and TSP sets those values for their NAPTR RRs and Tier 2 Nameserver
Provider is the one to enforce the rule.  Also if I remember it right, the
processing of the NAPTR RRs starts with the order value.  Unless the order
value is the same for all the NAPTR RRs, some of the NAPTR RRs (TSP's or end
user's) may never be used.

James

> From: Yu, James 
> Sent: Wednesday, September 04, 2002 11:05 AM
> To: 'Kevin McCandless'
> Cc: [email-masked]
> Kevin,
> Using DNS to request for NAPTR RRs, there is no way to 
> indicate that it is the TSP's or end user's NAPTR RRs that 
> are to be retrieved.  So you cannot have a pointer to point 
> to the TSP's nameserver(s) for TSP's NAPTR RRs.  The 
> requestor will get all the NAPTR RRs for that particular phone number.
> 
> James
> 
> > Sent: Wednesday, September 04, 2002 10:14 AM
> > To: 'Stastny Richard'
> > provide the
> > infrastructure database

---

From: "Yu, James" <[email-masked]>
Date: Wed, 4 Sep 2002 11:57:32 -0400

Kevin,

I want to emphasize one critical point about the impact of number
portability on ENUM provisioning if both TSP's and ENUM end user's NAPTR RRs
are collocated.

Assume that the ENUM end user changes the telephony service from TSP-A to
TSP-B.  Things do not happen in one night.  The loop to the end user's house
must be reconnected to the TSP-B's switch and when that happens TSP-B
informs the Number Portability Administration Center (NPAC).  The NPAC then
updates in real-time the SCP operators who operate the NP databases with the
new network routing data (location routing number in the U.S.) via the LSMS
interface. 

If the TSP's and end user's NAPTR RRs are all on the same Tier 2
nameservers, the Tier 2 Nameserver Provider must do the zone file update
(with the TSP-B's NAPTR RRs replacing the TSP-A's NAPTR RRs) that is
synchronized with the real-time update from the NPAC.  Certainly not all the
TSP's NAPTR RRs need to be handled that way (various degrees of impacts on
the TSP's services).  But at least the NP data must be updated at the same
time.

James

> Sent: Wednesday, September 04, 2002 10:17 AM

---

From: Richard Shockey <[email-masked]>
Date: Wed, 04 Sep 2002 21:44:10 -0400

A

>And in all the discussions here I mainly got negative feedback (does not
>work, I do not like this, no, naah, this is not what is for, ...). I do
>not mind, if somebody tells me I am wrong, but then he should tell what
>is right or how it should be done.
>
>IMHO there is now way forward at the moment in ENUM.

Now Richard I dont think you are being very charitable here ... all of us 
would like to see a revised enum service document combining the ideas from 
Ranali/Walter yours and Rudi Brandner fine work here.

I have it on some good authority that a revised enumservice document for 
SIP will be available in due course.

We had consensus that the generic ABNF syntax for the enumservice field 
would look like

service_field = "E2U" 1*("+" enumservice)
enumservice   = token *[":" token ":" token]   etc
token           = 1*32(ALPHA / DIGIT)

the Fax WG is working on their document and I believe that the VPIM folks 
are advancing along.... Greg?

BTW anyone that wants to work on H323 enumservice field ... now is the time!

There is nothing stopping trials from moving forward with all deliberate speed.

Richard Shockey, Senior Manager, Strategic Technicial Initiatives
NeuStar Inc.

---

From: "Stastny Richard" <[email-masked]>
Date: Thu, 5 Sep 2002 14:39:12 +0200

MM wrote:

> > Don`t you think that you are a bit _praepotent_ (sorry, did 
> not find 
> > the English word in the dictionary).
> 
> I think its from the Latin meaning originally to "be powerful 
> over". I think the current conotation would be "bullying". If 
> so then I'm sorry to come across like that but what I'm 
> trying to get at is that this isn't a DNS problem but a 
> database problem. 

I think what we have is a basic idea (ENUM) and different people
have different views what can or may be done with this idea.

I also think that the ENUM RFC should be generic and allow
most of the view to be implemented, but the we need to discuss
the different requirements first.

And it is a DNS problem, because DNS is the database used and
IMHO DNS is a special kind of database.

>If there are current ways of doing things 
> that make it really, really hard to even solve it on a 
> database side then maybe its time to revisit those "ways of 
> doing things" in light of new knowledge and systems....
>

Thats excactly what I am trying to do: I try to revisit how
the things are done in the conv. telephony system "in light
of new knowledge and systems" and try to merge/migrate/replace
certain functions by moving to IP, having an eye also on legal 
and regulatory requirements, because there is a difference 
between greenfields and incumbents (espescially with Significant
Market Power - what the term in Europe is). And there is a 
Differnce what you can do and what you are allowed to to -
and there is no use to discuss this here.

Regards
Richard

PS: I finally found the translation of praepotent/präpotent.
The problem was, it is not German German, it is Austrian German,
therefor was not in the normal dicitonary, and is has the meaning of
arrogant and presumptuous ;-)
_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: "Vaudreuil, Greg M (Greg)" <[email-masked]>
Date: Thu, 5 Sep 2002 08:07:57 -0500

Greg here....

I have been waiting for the revised ENUM document with the revised ABNF syntax in something more stable than a view-graph.  As soon as the new ENUM doc is posted, I will submit the VPIM routing draft.

Greg V.

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]]
Sent: Wednesday, September 04, 2002 8:44 PM
To: Stastny Richard; Michael Mealling
Cc: [email-masked]
Subject: RE: [Enum] Opt-in principle for calling users and
communications providers

A