Subject: RE: [Speermint] Basic Peering Requirements

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 23 Oct 2006 12:01:06 -0400

Concerning de-regulation:

If a group were to try to keep the system closed and certain call
routing information private, whether intentionally or unintentionally to
raise barriers to competition; I think the regulators would feel
compelled to step in and make such call routing information publicly
available.

So, if you want to keep the regulators idle, design the system so that
any VSP that can reliably authenticate themselves can take the sequence
of steps that leads them to the ingress points and allows them to
deliver calls to another VSP.  The key is having secure controls versus
having static clubs.

Mike

> -----Original Message-----
> From: Otmar Lendl [mailto:[email-masked]] 
> Sent: Monday, October 23, 2006 11:40 AM
> To: Richard Shockey
> Cc: [email-masked]; 'Nieminen Klaus'
> Subject: Re: [Speermint] Basic Peering Requirements
> 
> On 2006/10/23 17:10, Richard Shockey <[email-masked]> wrote:
> > 
> > > There are several arguments why carriers will never put 
> there TNs in 
> > > public ENUM trees, e.g.:
> > > - "Carriers are afraid that others can query how many 
> > > numbers(customers) they have."
> > > - "Carriers are afraid that other carriers can find out 
> the current 
> > > carrier-of-record of an enterprise and to poach this customer"
> > 
> > Both of these arguments as you mention are completely specious.. 
> 
> We know. Klaus just quoted what we sometimes hear from carriers. 
> You know, they don't always make sense.
> 
> > > maybe others can tell us why carriers never will put 
> there numbers 
> > > into public infrastructure ENUM?
> > 
> > 
> > The real reason carriers will never put their numbers into 
> any form of 
> > public infrastructure ENUM is two fold.
> > 
> > A. Only a mad man would put the location of critical VoIP ingress 
> > elements edge or otherwise into a public DNS infrastructure. The 
> > potential for DDoS alone is massive.
> 
> Agreed. That's the reason we developed the domain policy DDDS 
> proposal which can used to really de-couple the URI from the 
> ingress elements. 
> E.g. if the only things you can learn from the public DNS is 
> that example.com is a member of federation X and Y, and uses 
> 
> fedx-ingress.example.com 	A	10.0.0.42
> 
> and
> 
> fedy-ingress.example.com 	A	172.27.10.10
> 
> as the ingress elements on the respective shared L3 
> infrastructure then I don't see the DDoS potential here.
> 
> > B. Infrastructure ENUM as it has been proposed almost guarantees 
> > national regulatory delegation and oversight and most 
> carriers are in 
> > favor of DE-Regulation of telecom not RE-Regulation.
> 
> Wait a second: you're now switching from the issue of a 
> public tree to the question of whether that should be a 
> NRA-approved one under ie164.arpa.
> 
> If the regulator proves to be a burden in all this, then 
> nothing stops an industry consortium to establish a tree 
> under a different apex. (As the forest of trees out there shows.)
> 
> > C. Some form of trusted registry of TN 2 URI mappings is absolutely 
> > necessary to insure interoperability but I suspect it will 
> be carriers 
> > them selves that attempt to control the organization and 
> distribution 
> > of such data.
> 
> Oh yes. Who argued against the carriers establishing a such a tree?
> 
> IMHO the best case is if the regulators *and* the carries 
> agree on someone who runs that trusted registry. Whether that 
> will then be a private tree or a public one, is an 
> independent question.
> 
> Given the fact that the number of "carriers" is bound to 
> increase and international resolution of TN->URI will be an 
> issue, I doubt that it will be easy to establish a sensible, 
> universal rule which describes who should have access to that 
> private tree.
> 
> Once the number of organizations which have access to a 
> private tree exceeds as certain number, the security benefits 
> you get from keeping it non-public are dwarfed by the 
> complexities of maintaining access control rules.
> 
> Or, as other events prove every now and then, the PSTN method 
> of maintaining security ("trust all other carriers") is 
> already breaking down right now. So why perpetuate that model?
> 
> It's just case of security by obscurity.
> 
> /ol
> --
> < Otmar Lendl ([email-masked]) | nic.at Systems Engineer >
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 

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

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 23 Oct 2006 12:19:11 -0400

> From: Michael Hammer (mhammer) [mailto:[email-masked]]
> Sent: Monday, October 23, 2006 12:01 PM
> To: Otmar Lendl; Richard Shockey
> Cc: [email-masked]; Nieminen Klaus
> Subject: RE: [Speermint] Basic Peering Requirements
> 

Now you are really waist deep in it ... what country are you living in :-) ?

Obviously you do not live in the proximity of US 495 aka the "Beltway".

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 23 Oct 2006 14:34:16 -0400

Well, here in the U.S., the stated reluctance of the regulator to permit TNs
in a public database is due to the fact that people's telephone numbers
would be in a public database.  They are concerned with the privacy aspects
of the problem.  So, they actually WANT private databases where people's
telephone numbers are concerned.  And this concern started in User ENUM, not
just infrastructure ENUM.  I understand there are other regulators who have
this concern.

I do think there is some validity to your concern about one carrier, or a
group of carriers, restricting access to their customers for termination
from other carriers, and I agree the regulators would probably not allow it.
Making routing data public has not yet been, and I don't think will be, the
remedy.  

Brian

> Cc: Nieminen Klaus; [email-masked]

---

From: "Pfautz, Penn L, GBLAM" <[email-masked]>
Date: Mon, 23 Oct 2006 14:50:58 -0400

We can continue to beat this topic to death (and I'm sure we will) but I
want to make one point.

We need to distinguish between peering for voluntary exchange of traffic
(not currently regulated at least in the US) and
Peering as a replacement for legally required interconnection in the
current PSTN. 
For the former carriers (and anyone else) can and will do what they
want. The latter is likely to eventually be subject to some rules. But
consider also that where interconnection is mandated it comes with rules
and is not open to all parties.
You want to interconnect with the PSTN in the US you need to be
certified; otherwise you buy end user services.

BTW If you put all allocated (including unassigned) numbers in the DNS
then you provide no more info than can be obtained by war dialing every
legitimate sequence.  

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, October 23, 2006 2:34 PM
To: 'Michael Hammer (mhammer)'; 'Otmar Lendl'; 'Richard Shockey'
Cc: 'Nieminen Klaus'; [email-masked]
Subject: RE: [Speermint] Basic Peering Requirements

Well, here in the U.S., the stated reluctance of the regulator to permit
TNs
in a public database is due to the fact that people's telephone numbers
would be in a public database.  They are concerned with the privacy
aspects
of the problem.  So, they actually WANT private databases where people's
telephone numbers are concerned.  And this concern started in User ENUM,
not
just infrastructure ENUM.  I understand there are other regulators who
have
this concern.

I do think there is some validity to your concern about one carrier, or
a
group of carriers, restricting access to their customers for termination
from other carriers, and I agree the regulators would probably not allow
it.
Making routing data public has not yet been, and I don't think will be,
the
remedy.  

Brian

---

From: "Reinaldo Penno" <[email-masked]>
Date: Mon, 23 Oct 2006 16:10:08 -0400

I must be missing something here. 
 
Telephone numbers are already public in the US (they have to be). To be de-listed you have to pay extra but law enforcement in the US are still notified of such unlisted phones. I can get a paper telephone directory and lookup any telephone number. I can go to Verizon's or ATT's (in the US) home page and perform a reverse lookup and find the telephone number associated with a name (and vice-versa).
 
So, it seems what we are talking here is not if they are public or not, but how easy is to get them. Putting them on a database like DNS would just make it easier (and more hackable) since they would be officially hook up in the Internet infrastructure. 
 
It seems people that do not want their telephone numbers on a paper directory, could opt out in a public database as well.
 
Since many of our speermint friends here are from Austria I tried the same thing and after one google search and three clicks I found this page
 
http://www.herold.at/, clicked at Telefonbuch (buch is book in english) and presto. 
 
regards,
 
Reinaldo 

________________________________

Sent: Mon 10/23/2006 11:34 AM

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 23 Oct 2006 16:09:55 -0400

> certified; otherwise you buy end user services.
In the U.S., and I suspect in other countries, if anyone, including a less
regulated (can't really say unregulated) carrier were to put its numbers in
a public database, I am quite certain there would be an uproar, and I'm
pretty sure the regulator would act.  That kind of thing is just too
sensitive these days.

Since there were some objections even to OPT-IN scenarios, I think the whole
area is fraught with difficulty.  YMMV. 

> then you provide no more info than can be obtained by war dialing every
And I repeat, I am firmly in the camp that believes security by obscurity is
not real security.  However, we deal with perceptions as well as truths and
since we're looking for practical answers to real world problems here, I
think we need solutions for all routing data not in public databases.

If the world ran the way I, personally, wanted, we'd peer on the Internet,
and we wouldn't need federations.  The reality is quite different.  I'd like
to not waste my time in this WG working on solutions that don't get
widespread adoption.  Been there, done that.

If you assume ANY public routing data, it's my opinion you have a solution
that will not be widely implemented.  If you have a solution that works with
all private databases, we have a chance.  That means the word "DNS", at
least a public DNS, can't appear in the answer.  I don't like that
situation.  I'd like to eventually change the perceptions that make that
situation arise, but in the mean time, I'd like to get VoIP to VoIP traffic
off the PSTN please.

---

From: "Pfautz, Penn L, GBLAM" <[email-masked]>
Date: Mon, 23 Oct 2006 16:25:22 -0400

Well, you can't opt out of carrier enum so it needs to be implemented in
a way that does not support data mining of unlisted numbers. I would
hope that the approach would be to put in everything allocated, but
maybe carriers will be required to keep access restricted. We'll see. 

I wouldn't count on routing data necessarily being public even if TNs
are.  

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: Monday, October 23, 2006 4:10 PM
To: Brian Rosen; Michael Hammer (mhammer); Otmar Lendl; Richard Shockey
Cc: Nieminen Klaus; [email-masked]
Subject: RE: [Speermint] Basic Peering Requirements

Telephone numbers are already public in the US (they have to be). To be
de-listed you have to pay extra but law enforcement in the US are still
notified of such unlisted phones. I can get a paper telephone directory
and lookup any telephone number. I can go to Verizon's or ATT's (in the
US) home page and perform a reverse lookup and find the telephone number
associated with a name (and vice-versa).
 
So, it seems what we are talking here is not if they are public or not,
but how easy is to get them. Putting them on a database like DNS would
just make it easier (and more hackable) since they would be officially
hook up in the Internet infrastructure. 
 
It seems people that do not want their telephone numbers on a paper
directory, could opt out in a public database as well.
 
Since many of our speermint friends here are from Austria I tried the
same thing and after one google search and three clicks I found this
page
 
http://www.herold.at/, clicked at Telefonbuch (buch is book in english)
and presto. 
 
regards,
 
Reinaldo 

Brian

---

From: "Reinaldo Penno" <[email-masked]>
Date: Mon, 23 Oct 2006 16:31:06 -0400

From: Pfautz, Penn L, GBLAM [mailto:[email-masked]]
Sent: Mon 10/23/2006 1:25 PM
To: Reinaldo Penno; Brian Rosen; Michael Hammer (mhammer); Otmar Lendl; Richard Shockey
Cc: Nieminen Klaus; [email-masked]
Subject: RE: [Speermint] Basic Peering Requirements

Well, you can't opt out of carrier enum so it needs to be implemented in
a way that does not support data mining of unlisted numbers. 

[Reinaldo]

Of course, since it would become easier, more safeguards would be needed. Possibly using user entered patterns or others.

I would

[Reinaldo]

Agree.

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked] <mailto:[email-masked]> ]
Sent: Monday, October 23, 2006 4:10 PM
To: Brian Rosen; Michael Hammer (mhammer); Otmar Lendl; Richard Shockey
Cc: Nieminen Klaus; [email-masked]
Subject: RE: [Speermint] Basic Peering Requirements

http://www.herold.at/ <http://www.herold.at/> , clicked at Telefonbuch (buch is book in english)
and presto.

regards,

Reinaldo

From: Brian Rosen [mailto:[email-masked] <mailto:[email-masked]> ]

Brian

> From: Michael Hammer (mhammer) [mailto:[email-masked] <mailto:[email-masked]> ]
> > From: Otmar Lendl [mailto:[email-masked] <mailto:[email-masked]> ]
> > https://www1.ietf.org/mailman/listinfo/speermint <https://www1.ietf.org/mailman/listinfo/speermint> 
> >
>
> https://www1.ietf.org/mailman/listinfo/speermint <https://www1.ietf.org/mailman/listinfo/speermint> 

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint <https://www1.ietf.org/mailman/listinfo/speermint> 

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint <https://www1.ietf.org/mailman/listinfo/speermint>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 23 Oct 2006 16:35:41 -0400

I know all of that.  There are web databases which, for any listed number,
will tell you the name (reverse lookup) from the number.  Of course, we need
solutions that work for unlisted numbers, one of the many problems public
databases have, war dialing every valid number notwithstanding.

However, the U.S. regulator, and the "Commerce Department", the branch of
executive government that deals with consumer affairs, have grave
reservations about ENUM in the public DNS.  Maybe Penn's folks can get them
over the problem, but right now it's not happening.  I understand there are
other countries whose governments are also worried.

In the mean time, we need solutions we CAN implement.  

I don't think this is one of those cases where the IETF holds up its nose
and states that the U.S. government, some carriers (and others) is just
wrong, or silly, or misinformed, and goes ahead and engineers solutions that
are ignored.  We've done that before, and we'll do it again.  I'd prefer in
this case that we just hold our indignation in check and build something
that works.

Brian

> Since many of our speermint friends here are from Austria I tried the same
> thing and after one google search and three clicks I found this page
>

---

From: Jim Reid <[email-masked]>
Date: Mon, 23 Oct 2006 21:37:45 +0100

> I must be missing something here.

True. :-)

> Telephone numbers are already public in the US (they have to be).  
> To be de-listed you have to pay extra but law enforcement in the US  
> are still notified of such unlisted phones. I can get a paper  
> telephone directory and lookup any telephone number. I can go to  
> Verizon's or ATT's (in the US) home page and perform a reverse  
> lookup and find the telephone number associated with a name (and  
> vice-versa).

Although phone numbers are sort of public, other things related to  
telephony service are not. [Or at least not easily determined by the  
general public.] These include stuff like which company provides  
service for a given number, which number(s) in a company's  
"allocation block" have been ported or are not in use, where the  
telco's interconnect points are, what type of hardware they use, etc,  
etc. With SIP peering, the analogues of these things could become  
visible to everyone: eg the name and addresses of the company's SIP  
servers that act as their internet/PSTN gateways. Telcos tend to  
consider this kind of thing to be sensitive data.

---

From: "Reinaldo Penno" <[email-masked]>
Date: Mon, 23 Oct 2006 17:28:54 -0400

Okay, let's go by parts here. I responded to the "privacy issues"
related to users. You answered my statement by saying that there are
others things that a user cannot find out. Well, that's another set of
issues. So, I guess I'm not missing anything, we are just talking about
different things.

Now, your argument is that there are other stuff and it is not
accessible. Some are related to peering, some are related number
portability and others.

I'm sure you can a enum tree that mirrors what you have today in a
directory. 

Now, you said it is difficult to find out "which company provides
service for a given number"

Well, I go o Verizon's webpage (which is _not_ my provider and put my
telephone number), it tells me

"Phone Details
Line Type: Land Line
Provider: Pacific Bell"

I tried with my cell phone, it even told me that.

Can it be easier than that?

Thanks,

Reinaldo

> From: Jim Reid [mailto:[email-masked]] 
> Sent: Monday, October 23, 2006 1:38 PM
> To: Reinaldo Penno
> Cc: Brian Rosen; Michael Hammer ((mhammer)); Otmar Lendl; 
> Richard Shockey; Nieminen Klaus; [email-masked]
> > Verizon's or ATT's (in the US) home page and perform a 
> reverse lookup 
> > and find the telephone number associated with a name (and 
> vice-versa).
> 
> Although phone numbers are sort of public, other things 
> related to telephony service are not. [Or at least not easily 
> determined by the general public.] These include stuff like 
> which company provides service for a given number, which 
> number(s) in a company's "allocation block" have been ported 
> or are not in use, where the telco's interconnect points are, 
> what type of hardware they use, etc, etc. With SIP peering, 
> the analogues of these things could become visible to 
> everyone: eg the name and addresses of the company's SIP 
> servers that act as their internet/PSTN gateways. Telcos tend 
> to consider this kind of thing to be sensitive data.
>

---

From: Jim Reid <[email-masked]>
Date: Mon, 23 Oct 2006 22:40:53 +0100

> issues. So, I guess I'm not missing anything, we are just talking  

Quite probably.

Your example of how to find the provider of telephone service does  
not disprove the point I made. So a US web site can tell someone  
which telco provides service for a US telephone number. Big Deal.  
Perhaps you could tell me who provides telco service for say the BBC  
in London. [You even get to pick the number.] Or for bonus marks,  
tell me how and where Verizon and PacBell (say) interconnect with  
each other.

---

From: "Reinaldo Penno" <[email-masked]>
Date: Mon, 23 Oct 2006 17:49:01 -0400

> Sent: Monday, October 23, 2006 2:41 PM
> To: Reinaldo Penno
> Cc: Brian Rosen; Michael Hammer; Otmar Lendl; Richard 
> Shockey; Nieminen Klaus; [email-masked]
> > issues. So, I guess I'm not missing anything, we are just talking 
> > about different things.
> 
> Quite probably.
> 
> Your example of how to find the provider of telephone service 
> does not disprove the point I made. So a US web site can tell 
> someone which telco provides service for a US telephone 
> number. Big Deal.  

"Bid Deal" is what you thought it was. You used it in an argument to
prove it was difficult. Then I showed it wasn't a "Big Deal" and
actually quite easy.

> Perhaps you could tell me who provides telco service for say 
> the BBC in London. [You even get to pick the number.] Or for 
> bonus marks, tell me how and where Verizon and PacBell (say) 
> interconnect with each other.
>

---

From: "Nieminen Klaus" <[email-masked]>
Date: Tue, 24 Oct 2006 10:22:49 +0300

Brian, Jim and all,

I think we should distinguish privacy from discovering some "routing"
information (e.g. the operator providing services for a given
number/URI). I don't know what was the main problem in US, but I suspect
that publishing just the provider may not be the one that caused such
reservations. I'm I wrong?

Some people don't want to publish the connectivity between their number
and other personal information (e.g. name and address) and they have
legal right to prevent that.

However, we want to publish the operator providing services for a given
number and the reason behind this is charging. A caller should be able
(well in practise this is more likely just in theory) to know the cost
of making a call to a given number beforehand.

For example in Finland this has been implemented as a web-page
(http://www.siirretytnumerot.fi/) where you input the number and get the
operator as a response. I don't know in how many other countries this
information is easily publicly available, but I don't see publishing it
as a big problem... of course this could reveal, what numbers are used
and what are not if that makes difference.

In addition, one comment because of Richard's question:

> Hence the heretical statement, "Is ENUM Irrelevant?"

What kind of ENUM do you mean? What I have understood, the "routing DB"
may not be public, but what I have heard at least most use ENUM
technology. That's at least what we have been planning in Finland.

regards,

- Klaus

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: 23. lokakuuta 2006 23:36
To: 'Reinaldo Penno'; 'Michael Hammer (mhammer)'; 'Otmar Lendl';
'Richard Shockey'

I know all of that.  There are web databases which, for any listed
number, will tell you the name (reverse lookup) from the number.  Of
course, we need solutions that work for unlisted numbers, one of the
many problems public databases have, war dialing every valid number
notwithstanding.

However, the U.S. regulator, and the "Commerce Department", the branch
of executive government that deals with consumer affairs, have grave
reservations about ENUM in the public DNS.  Maybe Penn's folks can get
them over the problem, but right now it's not happening.  I understand
there are other countries whose governments are also worried.

I don't think this is one of those cases where the IETF holds up its
nose and states that the U.S. government, some carriers (and others) is
just wrong, or silly, or misinformed, and goes ahead and engineers
solutions that are ignored.  We've done that before, and we'll do it
again.  I'd prefer in this case that we just hold our indignation in
check and build something that works.

Brian

---

From: Klaus Darilion <[email-masked]>
Date: Tue, 24 Oct 2006 09:41:16 +0200

> of the problem.  So, they actually WANT private databases where people's

Then I suggest some education for your regulators instead of accepting 
their concerns.

Yes, publishing phone numbers in ENUM makes them public - but publishing 
in ENUM does not reveal privacy data.

> telephone numbers are concerned.  And this concern started in User ENUM, not

I do not understand why regulators have privacy concerns with user ENUM. 
The user decides if it wants to publish its number it it should not be 
overruled by a regulator.

regards
klaus

-- 
Klaus Darilion
nic.at

---

From: Klaus Darilion <[email-masked]>
Date: Tue, 24 Oct 2006 09:49:00 +0200

> pretty sure the regulator would act.  That kind of thing is just too

Just to prove that not every regulator shares your opinion: Here is the 
list of all assigned Austrian numbers/blocks, published by the REGULATOR 
itself.

http://www.rtr.at/WWW/RFNr.nsf/lookuid/9581010CA79E0631C125720D0044718F/$file/www_dienste_csv.zip

have fun
klaus

-- 
Klaus Darilion
nic.at

---

From: Klaus Darilion <[email-masked]>
Date: Tue, 24 Oct 2006 12:01:00 +0200

> I wouldn't count on routing data necessarily being public even if TNs

Publishing a phone number in ENUM does not imply that routing 
information/ingress point is public.

This is what Otmar's domainpolicy and federation drafts describes, and 
what is already implemented in the openser domainpolicy module:

A short description:

1. ENUM entry for +43 123
3.2.1.3.4 NAPTR 100 10 "u" "e2u+SiP" "!^.*$!sip:[email-masked]!" .

This reveals an identifier to mydom.foo.

2. Now, as defined in draft-lendl-domain-policy-ddds find out the 
peering policy of mydom.foo by looking up NAPTRs of mydom.foo.

mydom.foo. NAPTR 10 50 ("U" "D2P+SIP:fed"
       "!^.*$!http://xyconnect.foo/!" . )
mydom.foo. NAPTR 20 50 ("U" "D2P+SIP:fed"
       "!^.*$!http://crossconnect.foo/!" . )

In this example mydom can be contacted via the xyconnect.foo federation 
and the crossonnect.foo federation. The final step - how to come from 
the URI sip:[email-masked] to the ingress point (IP address, port, 
transport protocol) - is a matter of the federation policy. This may be 
public or private - a federation policy.

Thus, ENUM does not imply that routing data is public.

-- 
Klaus Darilion
nic.at

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 24 Oct 2006 08:32:31 -0400

> reservations. I'm I wrong?
Yes, you are wrong.  There is great reluctance to have a public database
which lists the carrier of record for a given TN.

> legal right to prevent that.
Yes, that is even more sensitive, but we are agreeing that is not the
subject here

> of making a call to a given number beforehand.
Determining charging is not dependent on a public database of TN to
providers

> and what are not if that makes difference.
This IS part of the problem: revealing which numbers are active numbers.

> technology. That's at least what we have been planning in Finland.
Yeah, that is happening (private ENUM).  It's not the only way, but it's a
standardized way.  You can also get a plain SIP redirect.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 24 Oct 2006 09:12:04 -0400

Klaus

No matter how wrong you think they are, that is the state of affairs here.

Let's take a small example, not at all the only problem: unlisted numbers.
If you have a public database of all active numbers and you have access to a
directory ("white pages"), then you can determine the set of unlisted
numbers by walking through the two databases.

The regulator currently WILL NOT ALLOW a public list of active telephone
numbers.  

I think in the time frame of version 1 of SPEERMINT, this will not change.
We can declare them to be stupid, engineer a solution that won't work in the
U.S., and be done, or we can just deal with it.

I suspect that in countries that allow local number portability, the same
concerns arise.  I suspect that where there are blocks of numbers assigned
to a carrier, and the specific numbers don't exist in a public database,
that they are more willing to make that public.  Here in the U.S., the
"Pooling Administrator" does publish the assignment of 1000s blocks.
That is insufficient, since we do support LNP.  The "NPAC", which is the
porting database is definitely NOT public.

Brian

> From: Klaus Darilion [mailto:[email-masked]]
> Sent: Tuesday, October 24, 2006 3:41 AM
> To: Brian Rosen
> Cc: 'Michael Hammer (mhammer)'; 'Otmar Lendl'; 'Richard Shockey';
> 'Nieminen Klaus'; [email-masked]

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 24 Oct 2006 10:37:03 -0400

> technology. 

Your observation about the use of "enum technology" is correct what I was
getting at was the policies and procedures surrounding e164.arpa

That's at least what we have been planning in Finland.

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 25 Oct 2006 08:06:09 -0700

Jim Reid wrote:

> Telcos tend to consider this kind of thing to be sensitive data.

This is correct and there is more to it.

Scenario: Telco1 prepares a holiday promotion with free calls on
Mother's Day (or for frequent flyers) but will not let its competitors
know this ahead of time.

The sudden free calls may need to be routed differently and also settled
differently.

Such a web of critical business arrangements between networks will IMHO
make peering just as difficult as implementing interdomain QoS, which
has not happened for similar reasons: _Competing networks don't share
critical policies_.

The need to interdomain QoS was mitigated by the advent of broadband.
Best effort prevails.

The need for peering will be mitigated by the advent of free VoIP, IM
and video. VoIP prevails as an application with no other usage charge
besides the cost of broadband.

Thanks, Henry

-----Original Message-----
From: Jim Reid [mailto:[email-masked]] 
Sent: Monday, October 23, 2006 3:38 PM
To: Reinaldo Penno
Cc: Otmar Lendl; Nieminen Klaus; [email-masked]
Subject: Re: [Speermint] Basic Peering Requirements

True. :-)