Subject: RE: [Ecrit] [Fwd: I-D ACTION:draft-schulzrinne-ecrit-lump-00.txt]

From: "Stastny Richard" <[email-masked]>
Date: Thu, 23 Jun 2005 10:57:10 +0200

Henning,

here my first take on your nice draft on LUMP. I have
not come to a final conclusion yet, but I have some 
questions and remarks (in an unordered list):

Resolver architecture and synchronisation:

You are basically proposing an architecture different
from DNS, but using some of the concepts, as you state 
on page 5. This will
need a great deal on additional protocol and development
work to implement behind the scenes. 
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?

VSP?

What is a VSP (Voice service Provider?) I thought
access to emergency services is more general?

Introductory example

In your introductory example you are mixing
access by end-user, ESRP and VSP proxy, which is
very confusing.

On one hand the end-user gets the LUMP servers
announced by DHCP (I though this is done by
the access provider), but he then uses the
VSP proxy as "ESRP" t query the resolver.

I understand he may query the LUMP server
to get the dialstring.emergency, but why is
he then not using the LUMP directly?

I would also like to see more potential scenarios

LUMP system architecture

As mentioned above, the LUMP system architecture
need to be defined and implemented in a separate
RFC, because it should be able to interwork globally

Is there any work done already or a prototype implementation?

Protocol Operations

Query input: services

First: the input values possible here need to be standardized

Currrently I see dialstring and emergency defined (sos is gone?)

Next question: is there a wildcard possible e.g. emergency.*

And should the next labels be defined, some of them or none?
There should also be a defined name for "general" emergency
number (unified?), because a country may have both options.

e.g. emergency.fire, emergency.police, etc. is commonly known
but others are not. Since it is a national matter to define
which short code is treated as access to an emergency service
some countries overdid it (e.g. Austria). We have defined 9 (nine)
emergency numbers:

112 - unified - European emergency access -> done by police
122 - fire
133 - police
144 - ambulance
128 - gas emergency
140 - mountain
141 - doctor (Notarzt)
142 - psychologicial (Telefonseelsorge)
147 - kids
No, we do not have coast or marine ;-)

Since you do not know what they come up with tomorrow,
standardization is difficult

So IMHO an additional query is necessary:
emergency services available, where you do not get the URIs,
but the names:

e.g query services
and you get back the above list:

now you may query
emergency.kids
or
dialstring.emergency.kids

or you query 
dialstring.emergency:*

and get back the whole list

I think this is enough for a first take

Best regards
Richard

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Henning Schulzrinne
> Sent: Wednesday, June 22, 2005 2:25 AM
> To: ECRIT WG
> Subject: [Ecrit] [Fwd: I-D ACTION:draft-schulzrinne-ecrit-lump-00.txt]
> 
> I submitted a very drafty draft that tries to distill some of the
> discussion items from the recent interim meeting into a
location-to-URL
> mapping protocol.
> 
> Short summary: Describes an architecture of how to build a global
> resolution system that scales, is deployable and can be made reliable
> without "and then magic happens" and without waiting for a "root" to
be
> agreed upon. Uses SOAP since I didn't want to invent yet another
> RPC-like protocol.
> 
> I intentionally left out the WSDL details as those are relatively easy
> to add later. I suspect terminology and description need a fair amount
> of work, so I'd appreciate both comments on the approach and requests
> for clarification (or suggestions).
> 
> Henning

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 23 Jun 2005 23:01:05 -0400

Stastny Richard wrote:

Thanks for your comments and questions. Please see some initial answers 
below. To keep this response (and any response') from becoming a mile 
long, I'm splitting my response.

> work to implement behind the scenes. 

I'm hoping that this is not the case. I believe that the protocol 
primitives provided are sufficient to query and update the mapping 
entries, as well as to replicate the data. Clearly, the WSDL is missing, 
but if you find fundamental functionality missing, let me know.

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

> access to emergency services is more general?

Agreed; we may need to come up with a more generic term. Maybe CSP 
(communication service provider) will avoid voice bias.

Henning

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 23 Jun 2005 22:24:19 -0500

>(communication service provider) will avoid voice bias.

How about MSP (Multimedia Service Provider).

This gives a better hint at what the purpose is instead of the perhaps too 
general "communication" SP

>Henning

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 23 Jun 2005 23:28:10 -0400

> I would also like to see more potential scenarios

Yes, this clearly needs work; there are probably three+ scenarios being 
conflated into one.

> RFC, because it should be able to interwork globally

Can you explain a bit more what you mean by "architecture"? I do suspect 
that there are details of peering that would be handled nationally 
(e.g., by NENA), but the basic how-do-I-talk-to-my-neighbor should 
indeed be the same everywhere.

> Is there any work done already or a prototype implementation?

Just starting, based on the Apache-related server tools.

> Currrently I see dialstring and emergency defined (sos is gone?)

Indeed. I'm working on a related draft that describes a service URN, 
which would be the domain for this field, something like 
urn:service:sos.fire

> Next question: is there a wildcard possible e.g. emergency.*

My current thinking is that 'urn:service:sos' implies a wildcard for all 
services that are below 'sos', say. I'm reluctant to add explicit 
wildcards since that tempts strange things like 
service:dialstring.*.fire, which is not very sensible.

> number (unified?), because a country may have both options.

Indeed. In Europe, we'd have something like

service:sos  --> equivalent to "112"
service:sos.gas --> "128"

in the US, we'd have

service:sos --> "911" PSAP
service:sos.fire --> "911" PSAP
etc.

This will be part of the service URN draft.

> No, we do not have coast or marine ;-)

Given that most of the Austrian navy and coast guard probably consists 
of inflatable warships, this makes sense.

> standardization is difficult

I imagine a registry, not standardization. Adding new services is 
relatively harmless since the assumption is that an unknown service 
defaults to the "parent" service (i.e., if we were to define a fashion 
emergency for Italy, sos.fashion would default to sos elsewhere). One 
could argue for a client-based fallback ("first try sos.fashion, if that 
fails, try "sos" or instead consult your local department store").

> and get back the whole list

I can see how this would be useful for dial strings, so that you can 
populate a user interface with virtual buttons for all the locally 
available services.

> I think this is enough for a first take

Thanks for the comments.