Subject: Re: [Ecrit] Proposed requirement: split responsibility

From: Andrew Newton <[email-masked]>
Date: Tue, 24 May 2005 10:48:02 -0400

On May 24, 2005, at 9:36 AM, Brian Rosen wrote:

> Yes, I thing we are agreeing that at the street level, which includes 
> street
> name, pre and post directionals, and suffix, there is no hierarchy.
>
> Similarly, there is no hierarchy for House Number and the House Number
> Suffix, the Landmark Name, etc.

We have progress!  :)

> The only point in a hierarchy above that is to create some feasible
> mechanism to distribute the database.  There are reasons to want to do 
> that,
> and hierarchy makes sense at the city/county/state/country level.

As far as state and country, I agree.  We have ISO 3166 to hang our hat 
on for this.  I'm not sure city and county are concepts that easily 
adapt to the rest of the world.  And I believe PIDF-LO has further 
categories such as city division (A4) and neighborhood (A5).  While 
other standards bodies have struggled with defining categories for civc 
addresses and failed, we have simply defined what we know and moved on. 
  And that seems fine as long as we can come back and modify it later 
when we find out we've goofed (such as our ability to later define 
PIDF_LO v2 and add a theoretical A4_5 element).  However, the 
imposition of a hierarchy would seem to prolong any mistakes.

I am also not sure this is relevant.  As you have suggested, the same 
mechanism providing location information could also provide country 
information.  I have suggested taking that one step further; the same 
mechanism providing location information could also provide a pointer 
(URI) to the mapping service (or perhaps a URI directly to the PSAP in 
simple cases, though I suspect that isn't as easy as it sounds).  Since 
a URI can point anywhere, there is no need for hierarchy.

On May 24, 2005, at 8:48 AM, [email-masked] wrote:
> In my 15+ years in 9-1-1 I have never seen a community change its
> borders (or rename streets) without seriously considering the impact on
> 9-1-1 and correctly addressing it. The primary concern is dispatch
> response in most cases. Dispatch response scenarios can get rather 
> fuzzy
> in some border areas and new roads can create dispatch confusion. It 
> has
> never been a problem for PSAP call answering and I challenge you to
> provide specific proof of where this is occurring. So, it is not a
> matter of "which PSAP answers the phone" it is a matter of correctly
> identifying emergency responders (police, fire and EMS). To state that
> elected officials make road name changes without first considering
> emergency response scenarios (and call handling responsibilities) is a
> gross misrepresentation of the actual process.

I did not mean to suggest that politics are always oblivious to the 
needs of 911 service.  In the case I mentioned, it was conveyed to me 
that street name changes are communicated to the PSAP so that proper 
changes to the database may take place.  But it was not conveyed as an 
approval process (I will seek clarification).  I'm sure processes are 
different from country to country and, in the US, from state to state.

> Also, ENHANCED 9-1-1 PSAP boundaries do not primarily align with telco
> rate centers (as was suggested in an earlier e-mail). The notion of
> E9-1-1 is to break the connection between telco rate center and
> political boundary. They mostly align with town and/or community
> boundaries. If a town plans to move a boundary or change a response
> scenario to a particular area, both police and fire officials are
> included in the planning process (same with road name changes). This
> naturally extends to the 9-1-1 call routing process as well and is
> carefully orchestrated with the 9-1-1 system service provider who,
> manages the changes in the MSAG.

I think both Brian and I were simply suggesting that historical 
boundaries are due to telco network layout, and not that present day 
boundaries are given these restrictions (or that they SHOULD).

You have said that PSAP boundaries are "mostly" aligned with town or 
community boundaries.  The imposition of a hierarchy means that "ALL" 
must be aligned on some boundary.

-andy

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

---

From: Tom Taylor <[email-masked]>
Date: Tue, 24 May 2005 11:42:58 -0400

How a given country sets up its database is up to that country.  It 
could be centralized, distributed according to a hierarchy, or 
distributed but redundant.  The key requirement is that PIDF-LO and the 
query protocol be able to capture the elements of information any 
specific database system needs to function properly.  And of course, the 
database design will to a large extent be determined by what we provide 
in the way of query language.

I have a question about WG scope.  Is discovery of the appropriate 
mapping server a problem we are supposed to tackle?

Andrew Newton wrote:

>> mechanism to distribute the database.  There are reasons to want to 
>> do that,
> As far as state and country, I agree.  We have ISO 3166 to hang our 
> hat on for this.  I'm not sure city and county are concepts that 
> easily adapt to the rest of the world.  And I believe PIDF-LO has 
> further categories such as city division (A4) and neighborhood (A5).  
> While other standards bodies have struggled with defining categories 
> for civc addresses and failed, we have simply defined what we know and 
> moved on.  And that seems fine as long as we can come back and modify 
> it later when we find out we've goofed (such as our ability to later 
> define PIDF_LO v2 and add a theoretical A4_5 element).  However, the 
> simple cases, though I suspect that isn't as easy as it sounds).  
> Since a URI can point anywhere, there is no need for hierarchy.
>
>
>
...

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 24 May 2005 11:55:49 -0400

Tom

We have to specify how routing elements behave.  It can't be country
specific.  The entity doing the mapping has to have a well defined procedure
to determine the mapping, which includes how it starts, what it does if its
first query fails, etc, which works regardless of where it is deployed.

Similarly, we have to specify how it is possible for the database to be
distributed that is implementable in a practical sense.  North America is a
hard case, because the boundaries are messy, and the existing databases
match those messy boundaries.  

I agree each country will decide how to organize their database, but we have
to supply the mechanisms that make it work for all the conceivable cases.
Some countries are real simple; one URI for the entire country.  Others,
like in North America, are particularly complicated.  Japan appears to be in
between.

I do hope this is in scope; it would be useless if it wasn't.
I think scope starts with "you have a location" and ends with "you have a
uri (or set of uri's) where signaling should be sent".

Brian

> -----Original Message-----
> From: Tom Taylor [mailto:[email-masked]]
> Sent: Tuesday, May 24, 2005 11:43 AM
> To: Andrew Newton
> Cc: Brian Rosen; [email-masked]
> Subject: Re: [Ecrit] Proposed requirement: split responsibility
>

---

From: "Marc Linsner" <[email-masked]>
Date: Tue, 24 May 2005 13:20:41 -0400

Tom,

My opinion (subject to overrule) of your scope question is:

Yes, discovery of the appropriate mapping server is within scope of ECRIT.
I base this on:

'The group will show how the availability of location data and call
routing information at different steps in session setup would enable
communication between a user and a relevant emergency response
center.'

Coupling that with:

'any solution presented must be useful
regardless of jurisdiction, and it must be possible to use without a
single, central authority.'

Matching location data with routing data without a central authority, imo,
implies our requirement to explain/define the process of discovery of the
appropriate mapping server.

-Marc-

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Tom Taylor
> Cc: [email-masked]
> How a given country sets up its database is up to that 
> country.  It could be centralized, distributed according to a 
> hierarchy, or distributed but redundant.  The key requirement 
> is that PIDF-LO and the query protocol be able to capture the 
> elements of information any specific database system needs to 
> function properly.  And of course, the database design will 
> to a large extent be determined by what we provide in the way 
> of query language.
> 
> I have a question about WG scope.  Is discovery of the 
> appropriate mapping server a problem we are supposed to tackle?
> 
> Andrew Newton wrote:
> 
> >
> >> street name, pre and post directionals, and suffix, there is no 
> >> hierarchy.
> >>
> >> Similarly, there is no hierarchy for House Number and the House 
> >> Number Suffix, the Landmark Name, etc.
> >
> >
> > We have progress!  :)
> >
> >> do that, and hierarchy makes sense at the 
> city/county/state/country 
> >> level.
> >
> >

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 25 May 2005 08:38:20 -0400

I'm certainly not suggesting that there is a single hierarchy of PIDF-LO 
elements or that all levels of that hierarchy are populated in all 
cases. I am suggesting that there is a general hierarchy, with different 
tree depths in different countries, but that this is not a simple 
hierarchy with a fixed referral mechanism. As Brian indicated, in some 
civic address cases, the next resolution step may under some 
circumstances not be determinable by simply looking at the address. 
Again, let me repeat my example: Imagine the city of Smalltown, NJ that 
is divided by a river, where parts of the city are covered by mapping 
server A and other parts by mapping server B. (Mapping server A and B 
may each contain references to any number of ESZs or PSAPs.)

For example, streets east of the river are covered by mapping server A, 
streets west by mapping server B, but the precise division makes no 
difference.

Smalltown, NJ is part of Jefferson County. Jefferson County maintains a 
mapping server that has an entry for Smalltown, NJ, but it needs to send 
a query to either server A or server B (or both), since it does not keep 
track of whether Oak Avenue is east or west of the river (or whether Oak 
Avenue exists at all). The county mapping server could provide two 
mapping server URLs to the querier, but that's just one of several 
possible solutions. The protocol machinery has to support this case 
unless we explicitly rule it out.

The equivalent problem is not likely to exist in geo coordinates. For 
the geo mapping, the county server would simply have two polygons, one 
covering the service area east of the river, the other the one west of 
the river. As long as the river stays in place, this is unlikely to 
change. In any event, once you support this functionality for civic, the 
same mechanism is likely to work for geo coordinates.

> PIDF_LO v2 and add a theoretical A4_5 element).  However, the imposition 
> of a hierarchy would seem to prolong any mistakes.
> 

There is no need for a single hierarchy, but there will be a 
hierarchical graph, unless you assume that every server in the world 
stores every street address.

---

From: Andrew Newton <[email-masked]>
Date: Wed, 25 May 2005 11:59:44 -0400

[ Responses to Marc and Henning to avoid clogging the list... ]

Not that I disagree with your conclusion, but I take away different 
meanings from what you have quoted.  Comments in-line:

> communication between a user and a relevant emergency response

Going back through what has been said in the BoF and WG sessions, I 
thought this was speaking to the ability of making an emergency call 
before location information is available.  As in, determination of 
which PSAP to contact should not have to wait on the 30 seconds it 
takes to get a GPS lock.

> single, central authority.'

All I get out of this is that the system shouldn't require a 
centralized database for any jurisdiction that wishes to break up the 
data into multiple mapping services.

> appropriate mapping server.

Again, I'm not disagreeing with your conclusion (just a little puzzled 
about how you arrived at it).  But this does bring up a process 
question: does putting discovery in scope mean that we are to write 
requirements regarding the discovery mechanism in other protocols, 
write requirements regarding the interaction between the discovery 
mechanism and the mapping service, and/or simply write about the 
discovery mechanism in the OBTW document (we really need a name for 
that)?  I see the last two items as being unproblematic from the "plays 
well with others" standpoint.  However, the first item touches back on 
the issue of ECRIT going around and telling others what to do based on 
our requirements (which in some areas is about as welcome as a poke in 
the eye).

In the spirit of writing requirements regarding the interaction between 
the discovery mechanism and the mapping service (number 2 from above), 
I propose the following: The mechanism for discovery of a mapping 
service MUST NOT impose upon the query interface of the mapping 
service, and the two SHOULD be separable.

On May 25, 2005, at 8:38 AM, Henning Schulzrinne wrote:

> I'm certainly not suggesting that there is a single hierarchy of 
> PIDF-LO elements or that all levels of that hierarchy are populated in 
> all cases. I am suggesting that there is a general hierarchy, with 
> different tree depths in different countries, but that this is not a 
> simple hierarchy with a fixed referral mechanism.

Perhaps I'm missing the point, but such genericism seems to obviate the 
imposition of this hierarchy.

>  As Brian indicated, in some civic address cases, the next resolution 
> step may under some circumstances not be determinable by simply 
> looking at the address. Again, let me repeat my example: Imagine the 
> city of Smalltown, NJ that is divided by a river, where parts of the 
> city are covered by mapping server A and other parts by mapping server 
> B. (Mapping server A and B may each contain references to any number 
> of ESZs or PSAPs.)
>
> For example, streets east of the river are covered by mapping server 
> A, streets west by mapping server B, but the precise division makes no 
> difference.
>
> Smalltown, NJ is part of Jefferson County. Jefferson County maintains 
> a mapping server that has an entry for Smalltown, NJ, but it needs to 
> send a query to either server A or server B (or both), since it does 
> not keep track of whether Oak Avenue is east or west of the river (or 
> whether Oak Avenue exists at all). The county mapping server could 
> provide two mapping server URLs to the querier, but that's just one of 
> several possible solutions. The protocol machinery has to support this 
> case unless we explicitly rule it out.

If I'm reading this right, you are suggesting the following scenario 
may be necessary:
   a) client queries mapping server A
   b) mapping server A says "I don't know, go query both server B and 
server C because one of them MAY have the answer"
   c) client queries both mapping server B and mapping server C

If so, that's interesting.  I wouldn't say this needs to be ruled out, 
but it certainly sounds less than ideal.

> change. In any event, once you support this functionality for civic, 
> the same mechanism is likely to work for geo coordinates.

And I'm still asking myself why you need to care about imposing a 
hierarchy to do this.  What in the referral mechanism is dependent on 
that?

Perhaps the requirement would better be changed to: The mapping 
protocol MUST NOT inhibit the ability of a mapping provider to 
distribute mapping service across multiple, distinctly named mapping 
servers.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 25 May 2005 20:22:04 -0400

> before location information is available.  As in, determination of which 
> PSAP to contact should not have to wait on the 30 seconds it takes to 
> get a GPS lock.

Sure. In many cases, you might be able to get a rough location fix, 
e.g., by having DHCP provide you with the (WiMax/WiFi) tower location on 
  boot/movement into range. This would be available before the 
emergency, without delay. But I don't see how this affects ECRIT.

> All I get out of this is that the system shouldn't require a centralized 
> database for any jurisdiction that wishes to break up the data into 
> multiple mapping services.

Which, given alternative proposals elsewhere, may seem obvious to you 
and me, but may not be.

> requirements regarding the discovery mechanism in other protocols, write 
> requirements regarding the interaction between the discovery mechanism 
> and the mapping service, and/or simply write about the discovery 
> mechanism in the OBTW document (we really need a name for that)?  I see 

However this is done, we need to be able to tell a complete story and 
can't just say "and then magic happens". For example, we defined the 
appropriate discovery mechanism (inter alia, a DHCP option) for SIP, for 
example.

While there might be several mechanism, not offering a reasonable set of 
viable choices means that we don't get a useful mapping protocol.

> imposition of this hierarchy.

It simply means that the referral relationship of mapping servers has to 
be a tree, not a general graph. Otherwise, you'd get referral loops, for 
example. Again, this is probably pretty obvious to most of the 
participants, but not necessarily to the world at large.

> If I'm reading this right, you are suggesting the following scenario may 
> be necessary:

Server A may not even know that there's B (as opposed to C, D, through 
Z). In this example, Jefferson County has to know. Thus, it may provide 
this informatin.

> but it certainly sounds less than ideal.

I wouldn't build a system like that, but we're defining requirements for 
the mapping protocol, not designing server graphs. If we rule out this 
condition, all of the end-of-interim discussion about lame delegations 
becomes moot, for example.

> hierarchy to do this.  What in the referral mechanism is dependent on that?

The ability to return more than one next-step URL, for example.

> 
> Perhaps the requirement would better be changed to: The mapping protocol 
> MUST NOT inhibit the ability of a mapping provider to distribute mapping 
> service across multiple, distinctly named mapping servers.

Again, the real problem only occurs if the 'parent' server can't know 
which server is responsible for the next layer down. Thus, while your 
generic requirement isn't wrong, it obscures the difficult case.

---

From: Andrew Newton <[email-masked]>
Date: Wed, 25 May 2005 21:39:54 -0400

On May 25, 2005, at 8:22 PM, Henning Schulzrinne wrote:
> e.g., by having DHCP provide you with the (WiMax/WiFi) tower location 
> on  boot/movement into range. This would be available before the 

Given that this part of the thread is about what is and is not part of 
the charter for ECRIT, it would seem directly relevant to how it 
affects ECRIT.  I don't really care about this, so I'm gonna drop it.

>> Perhaps I'm missing the point, but such genericism seems to obviate 
>> the imposition of this hierarchy.
>
> It simply means that the referral relationship of mapping servers has 
> to be a tree, not a general graph. Otherwise, you'd get referral 
> loops, for example.

Tree structures that make references to the top of the tree need to 
guard against referral loops too.  And referral loop detection is not 
that hard in a general graph when the nodes are distinctly named.  
Besides, in the case you have stated with URLs being passed back to be 
acted upon again, the client SHOULD be doing referral loop detection if 
it knows what's good for itself.

> I wouldn't build a system like that, but we're defining requirements 
> for the mapping protocol, not designing server graphs. If we rule out 
> this condition, all of the end-of-interim discussion about lame 
> delegations becomes moot, for example.

Not in the geo case, which is actually where I started the discussion 
at the interim.

> generic requirement isn't wrong, it obscures the difficult case.

Ah!  Now we're getting somewhere.

But this still doesn't necessitate an ECRIT defined hierarchy.  There 
is nothing to say that Server A can't formulate a referral based on the 
given location information to Server B where all the servers in that 
jurisdiction have accepted a certain naming convention.  They can come 
to this agreement regarding their own jurisdictional based tree 
structure without causing the whole world to do the same.  Even better, 
they can decide to change that tree structure without having to 
reconfigure every client that may come into contact with their 
services.

Thanks for your patience.

-andy