Subject: [Ecrit] LUMP Admiistration

From: "Stastny Richard" <[email-masked]>
Date: Fri, 24 Jun 2005 12:37:01 +0200

Henning,

> > It will also need some basic administrative
> > oversight to link these finally together globally, also you
> > point out this can also be implemented bottom-up. Do you have
> > any ideas already what is required here?
> 
> The basic decision that each node administrator will have to make is
> whom to peer with (or not). I suspect that's where some amount of
> administration will be needed, but it's certainly easier than BGP
> peering. Peering really only requires trusting that the peer has
> reasonable first-level entries. Robust implementations will need to do
> some amount of verification to detect overlapping "claims", but the
> system data at that level is likely to be a lot more static than, say,
> BGP routing information, as it doesn't depend on dynamic network
behavior.

I do not think administration of LUMP will be simple. As we have seen
with ENUM, IETF is not involved in administrative issue and the
resulting discussion is still going on. Keeping in mind that with
ENUM there is at least the DNS model of delegation to stick to.

With LUMP the issue is much more complicated. Let's take the
Austrian example: In the numbering ordinance is only defined what
short codes have to be treated (technically) as emergency numbers.

It is somebody else problem what the entities are where these numbers
are routed to. In case of the US this is simple, because there is only
911 and the dispatch problem is hidden behind the scenes.

If you have explicit call takers, the problem is directly related
to the LUMP database. Who has the right to put an entry in LUMP?

For the police, this is quite simple, because they have a proper
hierarchy and are finally under the ministry of internal affairs.

With fire this starts to detoriate in the rural area with the
voluntary fire-fighters and gets completely out of hand with
the competing ambulance services. Basically every village chief
may decide on the ambulance service serving his area.

To solve this problem is of course not within the scope of
the IETF, but the administrative issues will need some time 
to be solved both on the international and on the national level

Finally the customer needs to be sure that the hierarchy and also
the peering is done between trusted entities.

Again keeping ENUM in mind, if I imagine all the legal
papers and contract necessary to get this operational and
propely administered ....

regards
Richard

Richard Stastny
OeFEG
tel:+43 664 420 4100
enum:+43 780 203 211
callto://fordprefect
http://voipandenum.blogspot.com

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 24 Jun 2005 09:46:00 -0400

> ENUM there is at least the DNS model of delegation to stick to.

I actually wanted to avoid any ENUM model, precisely because of the 
hierarchy issue. Having a hierarchy with a world-wide root means that 
you need to agree on who runs the root early on. Judging from ENUM 
history, that seems a difficult problem. In the LUMP architecture, 
entities can peer regionally first and then later worry about global 
peering, without the problem of having to update all the DNS entries 
from a local ENUM tree to a global one.

> 911 and the dispatch problem is hidden behind the scenes.

This is not fundamentally different. Even in the US, somebody has to 
agree as to who serves which geographic area. It is not uncommon that 
police and fire jurisdictions are different, leading to the somewhat 
peculiar E911 concept of ESNs and ESZs (essentially, a number/zone for 
all possible combinations of fire/police/ambulance that occur).

> to the LUMP database. Who has the right to put an entry in LUMP?

Unless you have police precinct captains battling over who patrols which 
section of Vienna, there seems to be a fairly natural division. This is 
not a LUMP problem - all proposals and discussion so far have assumed 
that there is some agreement, outside of contested international 
territory, as to who serves each area. LUMP can deal with overlap, but 
any unresolved overlap in any system is going to be confusing to users. 
We need to design systems that can handle overlap, but I don't think we 
are the right organization to deal with the administrative side. There 
are plenty of organizations, such as NENA, who are more operationally 
qualified. Again, this is not a LUMP issue as such.

> may decide on the ambulance service serving his area.

I assume that if you dial the ambulance 3-digit number in Austria today, 
you don't get three village mayors competing for your services ("mine is 
cheaper", "mine has cup holders", "mine is endorsed by Arnold").

> to be solved both on the international and on the national level

As far as I can tell, this is mainly a national issue. You could even 
imagine that only LUMP servers within a country peer and that there is 
some higher-level diplomatic exchange of pointer information beyond 
national boundaries, maybe by diplomatic cable or parchment paper.

> the peering is done between trusted entities.

Certainly. This is why advertisements are signed.

> propely administered ....

While there will always be some coordination, I don't think the ENUM 
analogy quite fits. Indeed, I've tried ao avoid some of the issues that 
make global ENUM difficult. (Quite frankly, this is why I moved away 
from the DNS hierarchy model in our original proposal - too difficult to 
bootstrap initially. I'd much rather rely on regional efforts that can 
be connected later, without impacting the clients.)