Subject: [Ecrit] Re: LUMP Admiistration

From: "Stastny Richard" <[email-masked]>
Date: Fri, 24 Jun 2005 17:02:11 +0200

Henning,
 
thany for your detailed answer. My major problem is the mapping
of the different organizational structures of the agencies to LUMP.
 
You did not state it explicitly, but for the avoidance of doubt:
 
Is it possible e.g from a national parent server to have completly
different child architectures for say police, fire and ambulance,
according to their internal organizational structures and also
run by different entities?
 
So each agency is reponsible for seting up their own sub-clusters?
 
Richard

________________________________

Von: Henning Schulzrinne [mailto:[email-masked]]
Gesendet: Fr 24.06.2005 15:46
An: Stastny Richard
Cc: ECRIT WG
Betreff: Re: LUMP Admiistration

Stastny Richard wrote:
> Henning,

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

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.

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

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

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

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.

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

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

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.

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

Certainly. This is why advertisements are signed.

>
> Again keeping ENUM in mind, if I imagine all the legal
> papers and contract necessary to get this operational and
> 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.)

>
> 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 22:00:03 -0400

> run by different entities?

Yes, this is quite possible. You would have a top-level set of coverage 
entries that said something like

region=Austria (by civic or geo coordinates)
service=urn:sos:fire
next=lump:feuerwehr.gov.at

region=Vienna
service=urn:sos:police
next=lump:polizei.wien.gov.at

region=Austria
service=urn:sos:police
next=lump:polizei.at

(with the usual most-specific-one wins rule).

> So each agency is reponsible for seting up their own sub-clusters?

Indeed. They would either inject a top-level record like the one above 
into the resolvers or an Austria-wide LUMP server would receive and 
route requests to the fire and police hierarchies.

Essentially, mapping is taking the tuple (location, service) and mapping 
it to a (set of) URLs.

This all needs to be written up better in the draft.

Henning