Subject: RE: [Speermint] Basic Peering Requirements

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 19 Oct 2006 13:00:24 -0400

"The point is that for each route, what I want is the complete set of
VSPs that route can get me to."

So, you have entries for all VSPs on Earth?

When 1 Federation = N VSPs, where N can be many orders of magnitude
above 1, I would contend that:

"The point is that for each route, what I want is the complete set of
Federations that route can get me to."

would scale better.

Mike

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Thursday, October 19, 2006 12:29 PM
> To: Michael Hammer (mhammer); 'Stastny Richard'; 'Otmar 
> Lendl'; 'Daryl Malas'
> Cc: [email-masked]
> Subject: RE: [Speermint] Basic Peering Requirements
> 
> Which scaling limits are you working from, PSTN or the Internet?  
> 
> Reachability to thousands (or tens of thousands, or a couple hundred
> thousand) VSPs is what I want.
> 
> I want the "best" route to a VSP (which I may only know by a 
> TN in a registry). A federation is one potential route.
> 
> Scaling to tens or hundreds of thousands of routes is usually 
> considered to be quite reasonable, and even millions is quite 
> reasonable for L5 routing since we don't need to keep the 
> routes in memory.  Certainly a federation returning VSP 
> reachability to that many VSPs is easy.
> 
> If all I have is one transit peer, and no federations, then I 
> can launch my call and if it doesn't work, all I can do is 
> send it via the PSTN.  Same if I am only a member of one federation.
> 
> As soon as I have two routes, I need to know where to send it 
> for the next hop.  I have the destination VSP, I choose a 
> route: VSP in, route out.  I check my routes for 
> reachability.  If there is only one route, I send out the 
> call that way.  If I have more than one route, then I need a 
> cost metric, and we don't have to go there right now.  The 
> point is that for each route, what I want is the complete set 
> of VSPs that route can get me to.
> 
> Seems like getting that information directly is the simplest 
> way to go.
> 
> Brian
> 
> > -----Original Message-----
> > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > Sent: Thursday, October 19, 2006 10:46 AM
> > To: Brian Rosen; Stastny Richard; Otmar Lendl; Daryl Malas
> > Cc: [email-masked]
> > Subject: RE: [Speermint] Basic Peering Requirements
> > 
> > Brian,
> > 
> > Which would you rather maintain and advertise:
> > 
> > reachability to a hundred federations, or reachability to 
> millions of 
> > VSPs?
> > 
> > What you suggest doesn't scale.
> > 
> > The idea here was that once you know that a VSP belongs to a 
> > federation (via ENUM and DNS), you are now looking for information 
> > that your Transit VSP supports that federation and to which 
> signaling 
> > address of the Transit VSP to send the next signaling message.
> > 
> > Isn't that simpler?  Don't know why you want to make it harder.
> > 
> > There can be an address from which a federation membership can be 
> > fetched, but I would rather be pointed to the answer, than scanning 
> > through lengthy membership lists to discover relationships. 
>  I think 
> > the main value is in having a federation point to the Transit 
> > providers serving a federation only.  That should be a much smaller 
> > list.  But, that step would not be needed by the 
> originating VSP if it 
> > already knows what federations its own Transit VSP serves and the 
> > terminating federation is on that list.
> > 
> > In summary, routing towards federations as an aggregation mechanism 
> > rather than individual VSPs scales better.
> > 
> > Mike
> > 
> > 
> > > -----Original Message-----
> > > From: Brian Rosen [mailto:[email-masked]]
> > > Sent: Wednesday, October 18, 2006 1:55 PM
> > > To: Michael Hammer (mhammer); 'Stastny Richard'; 'Otmar Lendl'; 
> > > 'Daryl Malas'
> > > Cc: [email-masked]
> > > Subject: RE: [Speermint] Basic Peering Requirements
> > >
> > > To me, this is off the deep end.
> > >
> > > I think we don't care what federations a destination 
> network belongs 
> > > to.
> > > Sorry Otmar.
> > >
> > > I think a federation may advertise what peers it can get 
> you access 
> > > to.
> > > That may include transit peers, and those transit peers 
> may get you 
> > > to other peers through other federations.  The federation 
> advertises 
> > > the aggregate of what networks it can reach, direct or indirect.
> > >
> > > I don't want a peer to have to keep relationships (how it gets to 
> > > Fed X) straight, I want it to be able to ask the federations or 
> > > transit networks it deals with if they have a route to the 
> > > destination network.
> > >
> > > If you take this view, then you always get what you want to know, 
> > > regardless of how convoluted the routes are, by simple queries to 
> > > each federation/transit network.  If you try to trace routes in 
> > > advance (let's see, I want to get to network A, he is 
> part of Fed 1 
> > > and Fed 2, I'm not in fed 1 or 2, hmmm, peer Z is part of 
> fed 2 and 
> > > he is also part of Fed 3, and I'm in fed 3, so I can send it to Z 
> > > via fed 3, and he can send to fed 2 to get to A).
> > >
> > > Much better if Fed 3 advertises it can reach A.
> > >
> > > This is how route advertisements work, and I think we 
> should assume 
> > > that's the best way until proven otherwise.
> > >
> > > So let's not talk about Federations a network belongs to, and 
> > > specifically, don't talk about routes TO A FEDERATION, but rather 
> > > routes to a destination network FROM a federation.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Michael Hammer (mhammer) [mailto:[email-masked]]
> > > > Sent: Wednesday, October 18, 2006 1:01 PM
> > > > To: Stastny Richard; Otmar Lendl; Daryl Malas
> > > > Cc: [email-masked]
> > > > Subject: RE: [Speermint] Basic Peering Requirements
> > > >
> > > > I had taken this to mean that the Transit VSP would be
> > > advertising to
> > > > originating VSPs reachability to various federations of 
> the form:
> > > >
> > > > (to get to)      (contact)
> > > > Federation X --> [email-masked]  (Fed-X etc. could be an 
> arbitrary
> > > > string)
> > > > Federation Y --> [email-masked]
> > > > Federation Z --> [email-masked]
> > > >
> > > > or:
> > > >
> > > > Federation X --> [email-masked]
> > > > Federation Y --> [email-masked]
> > > > Federation Z --> [email-masked]
> > > >
> > > > If not, count me as misunderstanding too.
> > > >
> > > > Mike
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Stastny Richard [mailto:[email-masked]]
> > > > > Sent: Wednesday, October 18, 2006 10:05 AM
> > > > > To: Otmar Lendl; Daryl Malas
> > > > > Cc: [email-masked]
> > > > > Subject: Re: [Speermint] Basic Peering Requirements
> > > > >
> > > > > >> If a peer is providing connectivity to multiple
> > > federations, it
> > > > > >> should disclose AoRs providing indirect peering
> > > relationships to
> > > > > >> servicing peers or federations.
> > > > >
> > > > > >Sorry, I don't understand that sentence.
> > > > >
> > > > > >Do you mean that when a VSP adds an AoR to a federations 
> > > > > >routing database, then it needs to discluse whether 
> that is a 
> > > > > >direct
> > > > > customer
> > > > > >or just a transit offer?
> > > > >
> > > > > Sorry, but I do not understand the whole issue:
> > > > >
> > > > > An AoR is a a special type of SIP URI (a Public User
> > > > > Identity) defining the destination network (administrative 
> > > > > domain)
> > > > >
> > > > > How can it be disclosed or not, especially for a 
> transit network?
> > > > > It is always public.
> > > > >
> > > > > Richard
> > > > >
> > > > >
> > > > > ________________________________
> > > > >
> > > > > Von: Otmar Lendl [mailto:[email-masked]]
> > > > > Gesendet: Mi 18.10.2006 15:54
> > > > > An: Daryl Malas
> > > > > Cc: [email-masked]
> > > > > Betreff: Re: [Speermint] Basic Peering Requirements
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Daryl,
> > > > >
> > > > > > peering requirements from one operators perspective.  I can
> > > > > post these
> > > > > > to the list if you would like.  Here is a list of peering
> > > > > requirements
> > > > > > (this is certainly not exhaustive, but is a platform):
> > > > >
> > > > > Here are my comments to that list:
> > > > >
> > > > > General: this seems to be a list providing details on what 
> > > > > federations have to do (or agree on).
> > > > >
> > > > > > Transport (Layer 1  3):
> > > > > >
> > > > > > Peering must utilize IP as the primary mechanism 
> for peering.
> > > > > >
> > > > > > A federation must agree upon a common mechanism for IP
> > > transport
> > > > > > either private (e.g. IPVPN, IPSEC, etc.) or public.
> > > > >
> > > > > Fine.
> > > > >
> > > > > > Billing:
> > > > >
> > > > > Good.
> > > > >
> > > > > > Policy:
> > > > > >
> > > > >
> > > > > Could you be a bit more specific on what you mean by "policy"
> > > > > in this context?
> > > > >
> > > > > > Policies may be implemented locally to the peer or via a
> > > > > centralized
> > > > > > mechanism within the federation.
> > > > > >
> > > > > > Local policies should be disclosed when creating direct 
> > > > > > peering relationships with the applicable direct peer.
> > > > > >
> > > > > > Local policies may supersede centralized federation 
> policies.
> > > > > >
> > > > > > (Net of this...some peering relationships will be 1:1,
> > > so policies
> > > > > > will likely be local only.  Some peering relationships will
> > > > > be 1:N, so
> > > > > > policies will likely be implemented within DNS or some
> > > centralized
> > > > > > mechanism.)
> > > > >
> > > > > Could you provide some examples of such policies?
> > > > >
> > > > > > Membership:
> > > > > >
> > > > > > A peer may be a member of multiple federations
> > > > > >
> > > > > > A peer must maintain compliancy for policies as defined by 
> > > > > > each federation the peer is a member of.
> > > > > >
> > > > > > If a peer is providing connectivity to multiple
> > > > > federations, it should
> > > > > > disclose AoRs providing indirect peering relationships to 
> > > > > > servicing peers or federations.
> > > > >
> > > > > Sorry, I don't understand that sentence.
> > > > >
> > > > > Do you mean that when a VSP adds an AoR to a 
> federations routing 
> > > > > database, then it needs to discluse whether that is a direct 
> > > > > customer or just a transit offer?
> > > > >
> > > > > > Peers providing indirect peering must enforce federation
> > > > > policies on
> > > > > > behalf of the destination federation.
> > > > > >
> > > > > > A peer providing indirect peering may enforce undisclosed
> > > > > policies for
> > > > > > processing session requests between federations.
> > > > > >
> > > > > > (Net of this...some peers will only desire to be part
> > > of a single
> > > > > > federation, where wholesale carriers will likely be 
> members of 
> > > > > > multiple
> > > > > > federations.)
> > > > >
> > > > > ok.
> > > > >
> > > > > > Media:
> > > > >
> > > > > ok.
> > > > >
> > > > > > Routing:
> > > > > >
> > > > > > A peer must utilize the centralized federation routing
> > > > > mechanism if it
> > > > > > is available.
> > > > >
> > > > > ok.
> > > > >
> > > > > > A peer allowing another peer within a federation to provide
> > > > > indirect
> > > > > > peering on their behalf must select only one indirect
> > > peer to host
> > > > > > their AoRs.
> > > > >
> > > > > Do you mean indirect peering *within* a federation? Let
> > > me name the
> > > > > parties here:
> > > > >
> > > > > > A peer (X) allowing another peer (Y) within a
> > > federation (F1) to
> > > > > > provide indirect peering on their behalf must select only
> > > > > one indirect
> > > > > > peer to host their AoRs.
> > > > >
> > > > > Is the idea here that all members of F1 who want to place
> > > calls to X
> > > > > need to route the calls via Y? In that case, I would not
> > > consider X
> > > > > to be a member of F1. Instead, Y is providing transit
> > > services for
> > > > > X.
> > > > >
> > > > > Or you want to restrict X to be able to only select one
> > > other VSP to
> > > > > host it's AoRs in total?
> > > > >
> > > > > > A peer must not copy routing information from or make
> > > > > assumed routing
> > > > > > choices on behalf of the centralized routing mechanism for
> > > > > use locally
> > > > > > unless it takes place through standard caching methods.
> > > > > >
> > > > > > A common API must be utilized and available for subscriber
> > > > > and route
> > > > > > provisioning on any centralized federation location 
> function.
> > > > > >
> > > > > > Subscriber and routing information must be dynamically
> > > > > updated as soon
> > > > > > as applicable for accurate routing within the federation.
> > > > >
> > > > > ok
> > > > >
> > > > > > Performance:
> > > > > >
> > > > > > Performance metrics must be shared between peers as 
> they apply 
> > > > > > directly to peering signaling and media on a consistent
> > > > > basis within
> > > > > > the federation.
> > > > >
> > > > > ok
> > > > >
> > > > > /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
> > > > >
> > > >
> > > > _______________________________________________
> > > > 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: "Brian Rosen" <[email-masked]>
Date: Thu, 19 Oct 2006 14:26:45 -0400

I'm not advocating a particular solution, but, in general, I do want the
ability to determine if a particular route (=federation or transit network I
directly peer to) can get my call terminated correctly.  It's quite
acceptable, and maybe optimal to just give me the info (which might be list
of VSPs, but see below).  It may be acceptable to just let me query for that
(can I reach this VSP from you?).

What I don't need is the set of federations a VSP belongs to.  I don't care
a whit what federations they belong to.  I only want to know which of my
routes can get me to them.

The number of VSPs is a small number in today's technology.

It's entirely feasible to have a single database with every TN in the world.
That is a big database, but not beyond current single database technology.
The number of VSPs is small in database terms.  This is a database problem. 

Let's open this up a little more.

If some kind of public enum tree is built, whether it's user enum or
infrastructure enum in the public DNS, then we can do real two step lookups
of TN to VSP and then do some kind VSP to something lookup.  Right now, I
don't see that happening much.

What will happen is private databases (ENUM or otherwise).  We can argue if
the federation runs the database.  I think it will, one way or another.  We
have some problems.

One is how indirect peering TNs are handled.  Either they are imported into
the database, or the query is proxied to another database.  Either way, you
launch a query and you get back either a URI within the federation or you
get an error (not found).  If you are a member of more than one federation,
you may launch more than one such query, and you can get back zero, one or
more than one URIs (from each query and the aggregate of all the queries).

This means you end up doing TN to URI in one step.  We then have to decide
if you get the ingress point directly, or there is another query for that; I
suspect you get the ingress point in one step.

If you have one answer, that's where you send the call.  If you have zero
answers, PSTN gateway gets the caLL.  If you have more than one answer, you
are into some kind of cost metric.

The point is that you get an answer that is the route TO the VSP, not the
federation the VSP belongs to, OR EVEN THE IDENTITY OF THE VSP.  You query
by TN. You may not even be given the identity of the destination VSP.  Your
query by TN only yields next hop.

The only scenario where you know the VSP before you know the route is where
there is a registry independent of the federation.  That just isn't really
happening except in a very few isolated places.  I suppose we need to give
them some kind of solution, but I don't care much about it, because I think
it's not going to be common.

Brian

> Sent: Thursday, October 19, 2006 1:00 PM

---

From: Klaus Darilion <[email-masked]>
Date: Fri, 20 Oct 2006 13:49:15 +0200

> That is a big database, but not beyond current single database technology.

And every VSP is dependent on the provider of this database...real nice.

> The number of VSPs is small in database terms.  This is a database problem. 

Every enterprise with an IP PBX will be its own VSPs. Thus, you may not 
only count TDM carriers or big VSPs.

> suspect you get the ingress point in one step.

Why do you propose a solution which makes VSP dependent on provider of 
this big routing databases? IMO an IETF solution should not force VSPs 
to private ENUM trees and peering providers.

regards
klaus

-- 
Klaus Darilion
nic.at

---

From: "Pfautz, Penn L, GBLAM" <[email-masked]>
Date: Fri, 20 Oct 2006 08:05:30 -0400

Klaus:
The VSPs (and the Internet) are already dependent on big databases. It's
just DNS. I share your concern about a being captive to the owner
Of such a database. That's why some of us are working to implement user
ENUM and infrastructure ENUM in a way similar TLD registries so that
it's no one entity's private property but is managed cooperatively. 

Penn Pfautz

-----Original Message-----
From: Klaus Darilion [mailto:[email-masked]] 
Sent: Friday, October 20, 2006 7:49 AM
To: Brian Rosen
Cc: 'Stastny Richard'; [email-masked]; 'Otmar Lendl'
Subject: Re: [Speermint] Basic Peering Requirements

regards
klaus

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 20 Oct 2006 08:41:04 -0400

> And every VSP is dependent on the provider of this database...real nice.
Well, actually, it works, but I wasn't imaging that there would really be
one huge database that one entity administered.  Now, if we can all get
together and do it, why I'm sure I know a firm who would bid on the job.

> only count TDM carriers or big VSPs.
I really don't think federations will be used for huge numbers of Enterprise
VSPs.  I think that will be done on the Internet.  It is carriers that are
paranoid about the Internet, and insist on private peering arrangements.  

Another viable, and reasonable scenario is that, like the Internet,
Enterprise purchases transit from a transit carrier.  The transit carrier
is, as Mike points out, a federation of 2 to each peer, or it can look like
a federation itself if it permits arbitrary call termination to all of the
entities it provides transit for.  Regardless, it aggregates routing data
among all of its customers.  The transit network then peers at one or more
federations.  To a direct peer of one of those federations, the enterprise
TNs appear to be terminated by the federation (at the transit network peer
connection).  This is just another route aggregation, and it scales very
well.

...snip...
> to private ENUM trees and peering providers.
If anyone wants to put information in the public (user) enum tree, they are
free do so.  They can then peer on the Internet, surely the best IETF
solution.  If a carrier puts numbers in a public enum tree (anywhere in
.arpa), it can advertise in that tree how it may be contacted.  I don't
think the notion that your number is in a public tree, but your ingress
points at whatever federations you peer at are secret makes any sense and I
don't see the point in 2 or 3 level lookup in this case; just put the
ingress points in the federations in the main enum response and let a peer
pick one of them that it likes based on its memberships and your
order/preference.  If you have no common federations then you need to
identify a route.  I've never understood how you proposed to do that.

I'm dealing with reality.  Reality is that the numbers ARE NOT in a public
database, the peering points, or even federation membership ARE NOT in a
public database, but all-IP connections and RFCs are used between consenting
peers.  I'm trying to get a system that allows us to build interoperable
implementations that gracefully scale, and work in the real world.

It would be great if there was one database in the sky (say, the DNS).  It's
not happening yet, except in a very few isolated instances.

I also think that the notion that the originating network figures out the
entire path to the terminating network by tracing paths from the terminating
networks federation memberships back towards it is a bad idea.  I think
route availability is fed towards the originating network by the terminating
network, so that the originating network need only discover its next hop.
That's a route mechanism we know works really well, and when we need to
automate it (BGP), we can.  We don't need to automate that now.  I'm not
proposing that we do automate that now.  I'm proposing we use that model to
advertise routes.  

Of course, I'm also advocating that the route query is a TN and not a VSP,
because I don't believe there is a way to get the VSP without also getting
next hop in one lookup.

Brian

---

From: Klaus Darilion <[email-masked]>
Date: Fri, 20 Oct 2006 15:21:35 +0200

> free do so.  They can then peer on the Internet, surely the best IETF

Really? In USA every telco can immediately put its numbers in e164.arpa? 
  I suspect this is more an authoritative problem than a technical and 
probably lots of people will be happy if these problems are never solved.

> ingress points in the federations in the main enum response and let a peer

1. because there are SIP URIs - yes I want the SPEERMINT solution also 
to work with

> order/preference.  If you have no common federations then you need to
                                   ^^^^^^^^
exactly, only in the case of no common federation a transit peering is 
needed. If VSPs are in the same federation, they should be able to 
automatically find each other and peer without the need of a central 
routing database.

> identify a route.  I've never understood how you proposed to do that.

These are probably to steps: 1. find out if I can contact the peer 
directly, 2. find out a transit route if 1 does not.

If I understand you correctly you will do both steps in a single lookup. 
Thus, binding VSPs to the central routing table provider even if it is 
not needed (step 1).

I guess there are lots of companies which prefer doing an additional 
free DNS lookup before looking up the almighty, per lookup charged, 
routing database.

> I'm dealing with reality.  Reality is that the numbers ARE NOT in a public

Reality is also that there are forces which try to slow down user ENUM 
and infrastructure ENUM development.

And once again: SPEERMINT is not about numbers - it's about peering with 
  SIP.

> implementations that gracefully scale, and work in the real world.

Sorry, I did not knew that a central lookup database is a scaling solution.

regards
klaus

-- 
Klaus Darilion
nic.at

---

From: Klaus Darilion <[email-masked]>
Date: Fri, 20 Oct 2006 15:23:48 +0200

Pfautz, Penn L, GBLAM wrote:
> just DNS. 

Yes. But DNS is open and distributed.

 > I share your concern about a being captive to the owner

That's how it should be.

regards
klaus

-- 
Klaus Darilion
nic.at

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 20 Oct 2006 10:28:59 -0400

> probably lots of people will be happy if these problems are never solved.
That's the IETF solution.  User and infrastructure enum requires numbers be
put in the public DNS.  Some countries DO have problems with that, and there
are people working on solutions.  I'm not interested in workarounds other
than the solutions we have now (private databases).

> and I
If you have a SIP URI, then you have an SRV record in the domain that ALL
the SIP URIs that come to you should be using.  I think that is a sufficient
mechanism for all federations where public data is acceptable. 

> directly, 2. find out a transit route if 1 does not.
That is much too simplistic.  You are assuming that there is a transit
network that can reach EVERY TN that is not in your federation.  

You have to have a solution that allows a route through multiple
federations, using possibly multiple transit networks between each pair of
federations on the route.

My proposal does just that; it aggregates route data at every step,
providing reachability for direct peers of the federation as well as every
indirect peer, and, by aggregation, all of THEIR indirect peers, and all of
THEIR indirect peers....  You see, at the federation, ALL of the numbers you
can get to, and you get, in one query, your next hop (or, if there is more
than one route, your next hop choices).  When you choose your next hop, then
where ever you send it may (if they are a transit provider) have to do the
same thing at their federation to choose their next hop.  That repeats until
it gets to the termination network.

> Thus, binding VSPs to the central routing table provider even if it is
You always have at least one query to something.  I'm getting everything
done with one query TN to next hop.  I'm not assuming a central routing
table.  I'm assuming a per-federation routing table.  The query, however,
gets you aggregated data, either by importing indirect numbers, or (more
likely) referral, so you can ask your federation if it has a route to the
termination TN, and the federation can tell you if it does, even if there
are 4 indirect peers in the path.

> free DNS lookup before looking up the almighty, per lookup charged,
Well, if there is one query you pay for, then I'm giving you everything in
that one query.  Ignoring what the charging mechanism is, if the federation
has some kind of charging to terminate calls through it, then you pay the
query as part of that charging mechanism.  If the federation has no charge,
then your one lookup is "free".  You don't need any other free DNS lookups
unless everything is in the DNS.  That's one possible route.  I just don't
think we will see many TNs in the public DNS for a long time.

> and infrastructure ENUM development.
Yeah, true.  I personally think I should own my number and control the uses
to which I put it.  I personally LIKE user ENUM.  That doesn't mean I think
we will see many TNs in the public DNS tree.  It's not happening for a whole
lot of reasons.  The question is, do we ignore the reality (think NAT), or
deal with the reality?

> And once again: SPEERMINT is not about numbers - it's about peering with
Yeah, sure, but we don't need a lot of mechanism for SIP based peering,
especially if the URI is in a public DNS tree anywhere.

What I don't see much use for is a non-public URI resolution process.  I
know there are carriers who will do this (GSMA for example), but I don't see
needing any more mechanism like federation resolution of private URI name
spaces than we have now.  You can have SRVs in a private DNS.  I certainly
wouldn't want to encourage it.  

> Sorry, I did not knew that a central lookup database is a scaling
What scales is a linear tables with billions of records.  Route aggregation
COULD be done that way.  I suspect referral will be more palatable.
Referral + caching would work quite nicely.

Brian

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 20 Oct 2006 17:23:36 +0200

Things start to get clearer. This mail helps.

> (can I reach this VSP from you?).

So you just want to query for the next-hop information?

You write "can get my call terminated". What's the addresssing
information you have for that call? Is this a number? Is this a SIP AoR?

> routes can get me to them.

Ok. You only want that information if it helps you with your next-hop decision.
Otherwise, I agree, you don't care.

> The number of VSPs is small in database terms.  This is a database problem. 

Not all that is feasible is also desireable.

You probably can build routers which would cope with a billion /32 routes.
That doesn't make it a good idea to do away with route aggregation, though.

Regarding the number of VSPs: As I've been trying to argue: If we want
to build a system that can cope with URI-based addressing, then our
baseline is the number of domains in use for email. That is not a small
number. As you mention above: you sure can build database to store
that amount of information. Whether it is wise to do so is a different 
question. After all, there is already a database out there which
contains all these domains as primary keys, where the write access
rights are sorted out and which is open for querying.

So if our primary key is the domain name, why not use the DNS as the Database?

> query by TN only yields next hop.

Brian, you're talking about routing based on telephone numbers. I'm not
sure whether this is in scope for speermint. TN -> SIP translation is
handled by the ENUM WG. We're charted to provide SIP interconnection.

One could argue that you can do SIP calls based on tel: URIs, though
I rather doubt that our current charter, terminology and requirements
documents support that contention.

What's rather clear to me is that we need to support calls where
the caller entered a sip:user@domain URI as the target. So whatever
we do, we can't *assume* that our addressing is done with TNs.

I do think we need some more clarity on this basic question.

For all I know, we're not the only group which is going in circles
over that question. The same seems to be happening in the NGN and IMS
worlds.

> it's not going to be common.

Infrastructure ENUM is one aproach. To really be useful, I-ENUM needs
a speermint solution as to define how to handle and route based on
the URIs retrieved from I-ENUM. 

For I-ENUM to get market traction, speermint needs to deliver. 

And vice versa.

Anyway, that's how I see the problem space.

Once again, it boils down to the fact that we haven't really agreed on a
clearly defined set of requirements.

/ol

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 20 Oct 2006 12:38:21 -0400

> So you just want to query for the next-hop information?
Yes

> information you have for that call? Is this a number? Is this a SIP AoR?
Well, as you note, it's complex.

I think 99% of the problem is addressing with TNs, and less than 1% is sip
based.  Because I think that is the reality, I want an efficient solution
for TN based addressing, and then I'll back fit a SIP URI solution to it.
What I'd like is that the sip uri route resolve to straight DNS resolution,
but the possible existence of multiple paths because of complex peering
relationships makes a DNS based solution impossible.  DNS gets you ONE
authoritative answer, and we need more than one.

I think what I'm proposing for TNs works for SIP uris.  I really don't want
to go there, because it DOES duplicate DNS in some ways, but we have to.

So I'll give you the straight answer: it's the same.  You take the URI, you
ask the federation if it has a route to that URI, and it gives you a next
hop URI to use if it does.

But, as I said, that is less than 1% of the problem, so I look to make sure
it works with TNs

..snip...
> That doesn't make it a good idea to do away with route aggregation,
Right, but we have a different, and more unwieldy problem.  With number
portability, there is very little aggregation you can do on the actual
route.   So far, no two countries have permitted number portability across
country boundaries, but you can't aggregate routes by prefixes for TNs.

Fortunately, the routing we have to do has less dynamics.  It's NOT static,
but it doesn't change as often as the IP routing data does.

We also don't have the same performance requirements.  We don't have to keep
all the routes in memory, we can keep them in databases.

> rights are sorted out and which is open for querying.
Sure, if it's public.  But if you need federations, it isn't.

This is the problem we have with you guys.  Somehow you think that it's
acceptable for there to be some private data and some public data.  I don't
think it works that way.  The organizations who won't peer on the Internet
want ALL of their data private, not just some of it.

I do want the mechanisms to work with all public data.  I just don't see
them being used for a long time.  I'm not interested in solving problems
where some of it is public and some of it is private, I think there is never
any use for that.

> So if our primary key is the domain name, why not use the DNS as the
Primarily, as I said above, more than one route doesn't map to DNS
resolution.

> handled by the ENUM WG. We're charted to provide SIP interconnection.
Yeah, I understand my problem.  Sometimes dealing with reality is hard.
We may have to refer some work to ENUM, or change the charter.

> we do, we can't *assume* that our addressing is done with TNs.
As above, I agree, but don't think that is the real driver for addressing
solutions.  Note of course that addressing is but one part of peering.

> the URIs retrieved from I-ENUM.
Again, I-ENUM, because it's based on a public tree, is a non starter for the
vast majority of carriers today.  

I don't think that it makes any sense to force carriers to do TN to domain,
and then domain to next hop, when the actual databases could easily give you
TN to next hop.  Since we do have to route directly by domain, you could do
this, I just think we should combine them.  That's an optimization, but it's
a useful one.  The documents could describe it as two steps and then permit
the combination if someone wanted that.

Note that the direct query really could be (private) ENUM.  You query with
TN, you get a set of NAPTRs that resolve to your route choices, you then use
normal SIP DNS/SRV mechanisms to get to the IP address where you send the
call.  We could make an equivalent DDDS application for the domain based
route.  

> For I-ENUM to get market traction, speermint needs to deliver.
I don't think the problems of I-ENUM have anything to do with SPEERMINT,
they are only the issues of putting numbers in the public DNS.

> And vice versa.
That is definitely wrong.  Most of the federations use private enum or
equivalent.

> clearly defined set of requirements.
Agree

Brian

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 20 Oct 2006 19:04:58 +0200

>TN to next hop.  
 
So 3GPP, GSMA and ETSI TISPAN have to rewrite their specs
(e.g.  http://uk.sitestat.com/gsm/gsmworld/s?IR67_DNS_guidelines&ns_type=pdf&ns_url=[http://www.gsmworld.com/documents/ireg/ir67.pdf]

>Since we do have to route directly by domain, you could do

>call.  We could make an equivalent DDDS application for the domain based

And they basically use within their federation RFC3761 and RFC3263 for routing,
and the next hop is the destination, so no need for speermint at all.

But they now detect that they also have to interconnect to others and global
interconnection can only be in the long range in the global DNS. So sometimes
they have to come out of their private playgrounds

Richard

Agree

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 20 Oct 2006 14:00:23 -0400

> (e.g.
> http://uk.sitestat.com/gsm/gsmworld/s?IR67_DNS_guidelines&ns_type=pdf&ns_u
> rl=[http://www.gsmworld.com/documents/ireg/ir67.pdf]
Maybe.  As I said, it's an optimization, but a useful one.

> they have to come out of their private playgrounds
Nope, no routing will be in the global DNS.  The transit interconnects will
be private, and the reachability data will be private.

I don't LIKE that, but it's what is happening.  Carriers don't put ANY route
data in the public DNS.

It's pretty straightforward to describe the scheme so that it works on the
public DNS, I just don't think it will actually be deployed that way.  Also,
if you have more than one choice of path, you can't do that with a simple
lookup, and if you have to do a series of lookups, making one choice from a
list at every step, then you're playing my song.

The problem here is a multi step route determination.  We have a
constellation of federations, and set of transit carriers making connections
between them in non simple ways.  At any point in the graph, you may have
multiple choices.  The problem is to find a path.  It's not a simple one
stage lookup, it's a path discovery.  It's a ROUTING problem.  We know how
to solve routing problems.  In this case, we don't yet need a dynamic route
advertisement protocol, we can get away with simple query or query and
referral.

It's classical routing: you either start at the origin and look through all
paths at every branch until you get to the destination, or you feed forward
the aggregated route advertisements from the next hop to the leaf.  The
former is easy if the graph is not horribly complex.  It would be better to
feed forward aggregated routes.  However, the TN to domain mapping is highly
unlikely to work that way (not all registries will allow their data to be
aggregated).  If you need to support referral, then you might as well make
the whole mechanism query and referral.  You can cache, which helps with
domains, but doesn't help with TNs.

---

From: "Stastny Richard" <[email-masked]>
Date: Fri, 20 Oct 2006 21:26:48 +0200

>I don't LIKE that, but it's what is happening.  Carriers don't put ANY route

I do not like it either.
So the IETF is taken over by the carriers?

We dump 20-30 years of development and start rebuilding
the PSTN on IP?

I do not think that this is the charter of SPEERMINT, this may be
the task of 3GPP, ETSI TISPAN and ITU-T
 
I also agree with Mike here:
 
> I think that any middlemen that add no value will be
>disintermediated, sooner or later.

Richard

Von: Brian Rosen [mailto:[email-masked]]
Gesendet: Fr 20.10.2006 20:00
An: Stastny Richard; 'Otmar Lendl'
Cc: 'Michael Hammer (mhammer)'; [email-masked]
Betreff: RE: [Speermint] Basic Peering Requirements

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 20 Oct 2006 15:57:26 -0400

Then Richard, we are done.

User ENUM, DNS SRV, Internet Peering.  We need nothing else.

I do believe that eventually, carriers will be disintermediated, especially
at the enterprise level.

But we aren't there yet, and we have a lot of service providers who want to
do this, with the private stuff. 

It's not heresy.  The solutions WILL work on the Internet.  They will also
work on private IP networks.

But if a proposed solution ASSUMES a public database, then it won't work.

In this case, it also means if it assumes a single tree it won't be
acceptable.  Nothing that assumes a single tree where any carrier can see
the whole tree will be acceptable.

There isn't going to be ONE enum tree, there are going to be many
There isn't going to be ONE routing database, there are going to be many

Brian

> Sent: Friday, October 20, 2006 3:27 PM
> To: Brian Rosen; Otmar Lendl
> Cc: Michael Hammer (mhammer); [email-masked]

---

From: Klaus Darilion <[email-masked]>
Date: Mon, 23 Oct 2006 10:49:29 +0200

> mechanism for all federations where public data is acceptable. 

Exactly, this works only for VSPs which accept traffic from everybody. 
But if it would be the case that every VSP supports incoming SIP from 
everybody, then there would not be a SPEERMINT group at all.

regards
klaus

-- 
Klaus Darilion
nic.at

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 23 Oct 2006 15:28:08 +0200

[This thread is big enough as it is, I'll try to cut my reply down to
the crucial points.]

On 2006/10/20 14:10, Brian Rosen <[email-masked]> wrote:

> .arpa), it can advertise in that tree how it may be contacted.  

That's the user ENUM case. We've got real life experience with it. 

> I don't
> order/preference.  

The main misgivings we've heard from carriers we've been pitching
user-ENUM to was not the publication of the TN->URI mapping, but the
fact that these URIs are supposed to resolve to publically accessible
ingress points.

Their concerns are not secrecy, but control and security. They want
to control with whom (and how) they are going to exchange traffic with. 
Once we explained to them how they can achieve that (using the DP-DDDS
draft), they didn't care about the secrecy. 

> If you have no common federations then you need to

We do? Quoting draft-lendl-speermint-federations-03.txt:

----
4.4.  Routing Architecture

   For the direct intra-federation call, it is sufficient to match the
   federation memberships of the initiating and destination VSP.  This
   matching can be achieved through the domain policy DDDS application.
   While direct matching of federations enables direct peering, it does
   not solve the universal reachability problem.
[...]
   This document does not propose a routing protocol for that.  The
   following options are intended to stimulate discussions in the
   SPEERMINT working-group.
----

/ol

---

From: "Nieminen Klaus" <[email-masked]>
Date: Mon, 23 Oct 2006 16:30:19 +0300

Hi all,

I think that we would like to have at least a good portion of carriers
to support whatever mechanism we will choose.

I have seen that Brian has a clear opinion on what carriers will accept
and what they won't. However, I have not seen many carriers to comment
this discussion and anyway I'm more than sure that this isn't the only
truth.

> enable peering between two or more administrative domains over IP
networks

This is our goal and I was just wondering what are the main users for
our coming specifications? Are bigger mobile operators going to use them
anyway? Are enterprises and small VSPs more important communities? I
don't have answers :)

I was also trying to understand why e.g. publishing the federation
information is considered harmfull or something carriers won't do? This
may be the current policy, but are there some real reasons behind that
opinion or is it just that people say no because they don't understand
the concept. Please enlighten me.

I'm not in a position to hum for either of the approaches, but I would
like to understand the pros and cons better.

regards,

- Klaus

---

From: Klaus Darilion <[email-masked]>
Date: Mon, 23 Oct 2006 16:04:40 +0200

> the concept. Please enlighten me.

Hi Klaus!

Following my view, which is based on discussion with several carriers.

- Carriers do not have big research developments and in-depth knowledge 
of every protocol. They are used to buy what the equipment vendors are 
offering. If a big vendor tells them that it must be "this way", then 
the carrier will request a solution which does it "this way".

regarding public routing info:
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"

IMO this arguments are not valid, because this information can be 
retrieved easily also in the current TDM world - at least in Austria.

maybe others can tell us why carriers never will put there numbers into 
public infrastructure ENUM?

regards
klaus

-- 
Klaus Darilion
nic.at

---

From: "Stastny Richard" <[email-masked]>
Date: Mon, 23 Oct 2006 16:08:19 +0200

> public infrastructure ENUM?

e.g. because then they are forced to decide who will run it?

Richard

> Sent: Monday, October 23, 2006 4:05 PM
> To: Nieminen Klaus
> Cc: [email-masked]

---

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

Although this shouldn't be regarded as a commitment on anyone's part,
it's worth noting that the US carriers holding the lion's share of CC1
numbers in the US are working in the CC1 ENUM LLC to instantiate a
public infrastructure ENUM.
That doesn't represent a commitment to peer with all parties but it does
reflect a willingness to make at least certain data generally available.

Penn Pfautz

-----Original Message-----
From: Klaus Darilion [mailto:[email-masked]] 
Sent: Monday, October 23, 2006 10:05 AM
To: Nieminen Klaus
Cc: [email-masked]
Subject: Re: [Speermint] Basic Peering Requirements

Hi Klaus!

they have."

regards
klaus

-- 
Klaus Darilion
nic.at

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 23 Oct 2006 16:54:12 +0200

> to go there, because it DOES duplicate DNS in some ways, but we have to.

I've once asked a room full of ETSI people what kind of public SIP
identities they are planning to hand to their customers once the NGN
transistion is starting. That brought quite a few uneasy glances,
especially after telling them that using VSP owned domains 
will walk them into a big swamp regarding porting. That left them with
the choice of either

* replicate the public DNS inside their walled garden

or

* use the public DNS as part of their call setup procedure (at least
  for customer-owned domains).

Neither option made them happy.

..snip...

> want ALL of their data private, not just some of it.

Oh yes, they're not used to that from their PSTN business. On the other
hand, they don't seem to have a problem regarding such information at
the IP layer. E.g. from the RIPE db:

aut-num:        AS8447
as-name:        TELEKOM-AT
descr:          Telekom Austria AutonomousSystem
import:         from AS174 action pref=100; accept AS174:AS-COGENT
export:         to   AS174 announce AS-PTA
import:         from AS286 action pref=100; accept AS-KPN
export:         to   AS286 announce AS-PTA
import:         from AS553 action pref=100; accept AS-BELWUE
export:         to   AS553 announce AS-PTA
import:         from AS702 action pref=100; accept AS702:RS-AT AS702:RS-AT-CUSTOMER
export:         to   AS702 announce AS-PTA
import:         from AS1200 action pref=100; accept AS1200
export:         to   AS1200 announce AS-PTA
import:         from AS1120 action pref=100; accept AS-ACOSERV
export:         to   AS1120 announce AS-PTA
import:         from AS1239 action pref=100; accept ANY
export:         to   AS1239 announce AS-PTA
[...]

It's public information there that Telekom Austria uses AS1239, AS3356,
and AS6762 as upstream providers and peers with [...].

So why is it so _unthinkable_ to have similar information public
for SIP peering?

> We may have to refer some work to ENUM, or change the charter.

I think we need an agenda point for that in San Diego.

> vast majority of carriers today.  

We really should make a poll at in San Diego. As mentioned before:
I don't think the problem is with the ENUM information, it's only
about running open SIP proxies.

> a useful one.  

That optimization is IMHO a layering violation. 

These always look very efficient at first sight but are guaranteed to
lead to architectural straight-jackets in the long term.

> call.  We could make an equivalent DDDS application for the domain based

Oh yes, private ENUM might play a role in all this. I'm not ruling that out.
(although I prefer a public I-ENUM). 

The DP-DDDS with its federation scheme can just as well direct the
routing to a federation internal nexthop lookup scheme. 

/ol

---

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

IN LINE ..

> carrier-of-record of an enterprise and to poach this customer"

Both of these arguments as you mention are completely specious.. In many
countries is extremely easy to calculate how many customers a carrier has
and who is the underlying service provider for a particular TN. Certainly
that is the situation in the US as in Austria as you point out.

There is no empirical evidence that this data creates customer poaching. 

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

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. 

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.

---

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

> So the IETF is taken over by the carriers?

Hummm.. I thought that this was the Internet Telephony Engineering Task
Force ..

---

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

> 
> >Note that the direct query really could be (private) ENUM.  You query
> with TN, you get a set of NAPTRs that resolve to your route choices, you
then use normal SIP DNS/SRV mechanisms to get to the IP address where you
send the
> And they basically use within their federation RFC3761 and RFC3263 for
> routing, and the next hop is the destination, so no need for speermint at
all.
> 
> But they now detect that they also have to interconnect to others and
> global interconnection can only be in the long range in the global DNS. So
> sometimes they have to come out of their private playgrounds

Not necessarily ..Not if they have access to a sufficient number of TN 2 URI
mapping databases or gateways to those databases. Those databases may or may
not be in the DNS public or private.

You ASSUME there MUST be a global delegation model ... I don't think the
carriers are completely ready to hold hands and declare peace on earth and
good will to their customers.

Lets not forget the boundaries set for SPEERMINT ... SPEERMINT is about
everything that happens AFTER you have done a number translation to a URI.

---

From: Otmar Lendl <[email-masked]>
Date: Mon, 23 Oct 2006 17:40:06 +0200

On 2006/10/23 17:10, Richard Shockey <[email-masked]> wrote:
> 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.

> edge or otherwise into a public DNS infrastructure. The potential for DDoS

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.

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

> selves that attempt to control the organization and distribution of such

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

---

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

> > 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.
> to the question of whether that should be a NRA-approved one under

I'd much prefer to look at the whole problem statements  as query vs cache
using trusted registries.  Trees imply distributed databases. I'm not sure
that is how this all might play out.

I only become clairvoyant after the 2nd beer.

I suggest we may have internal cached databases that are fed via out of band
mechanisms by trusted registries.

If there is a public tree under ie164.arpa you can guarantee it will be NRA
approved and regulated as is e164.arpa.

Of course a mutually agreed private tree or domain would not have that
problem.

Here I'm taking a very US Canadian centric view but I do wonder if TN to URI
mappings are essentially no different from the classic PSTN merger of
trusted registries we have in the US.  TN routing = NPAC + LERG  cached into
SCP's. What then would be the difference between TN routing = NPAC + LERG +
TN2URI cached into IP-SCP's ( aka big fat cached DNS servers). There are
products on the market that do this stuff I'm told.

> apex. (As the forest of trees out there shows.)

True ..public or private. Which BTW argues for multiple trees or databases
being the likely short term outcome for TN 2 URI translations.

> > necessary to insure interoperability but I suspect it will be carriers
> them> > selves that attempt to control the organization and distribution
of such data.
> tree or a public one, is an independent question.

We're in violent agreement Remember .. once you have accepted that a trusted
registry ( IMHO probably nationally based ) that is the key component then
how the data is distributed is a secondary. 

Hence the heretical statement,  "Is ENUM Irrelevant?"

In that case simply deliver cached copies of the registries's database to
the carrier's internal "Service Control Database" and you are done.

Data for number ranges outside the scope of the cached database can be
handled by ancillary routing databases (Global Title Translation? Humm).

> describes who should have access to that private tree.

If there is a tree at all.
 
> It's just case of security by obscurity.

Better than no security at all I might add.

---

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

As I said many times before, I deal with reality.  The Internet grew up in
an open environment, where addressing data was public.  As it matures, the
commercial aspects, coupled with some legitimate security concerns, have
driven some address information less public.  I am not a believer in
security by obscurity, but I'm a realist that addressing data is
increasingly NOT public.

Addressing data in the phone networks have never been public.  There is
little incentive to make them completely public, but because there are a
larger number of "carriers" of different sorts springing up, it's less
private than it used to be, and merging Internet and PSTN technologies has
lead to more information being public.  However, the evidence I see says
that the carriers want addressing data private.

I think that means that what you are proposing is likely to be unacceptable.
It doesn't matter if I think it ought to be acceptable, I just don't think
it is.

There are a lot of ways to prevent access to an IP address, even if you know
that address.  Making an address public is not equivalent to providing
public access to that address.  You can put the actual data in a public
database, but restrict access to only those entities you want to have
access.  

What I see happening is both security by obscurity of (all of) the
addressing data, AND filtering, VPNs, and private address space that
prohibit access even if you gained access to the private data.

Brian

> From: Otmar Lendl [mailto:[email-masked]]
> Sent: Monday, October 23, 2006 11:40 AM
> To: Richard Shockey
> Cc: [email-masked]; 'Nieminen Klaus'
> national
> them