Subject: RE: [Ecrit] Issue 10: Design of Non-Emergency Components

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 4 Jan 2006 10:05:06 -0500

Interesting.  I would have never got this out of the current wording.
Furthermore, I would support making this a clear statement.  Someone
needs to point out to the NENA community that specialized
software/hardware designed specifically for government use *** COSTS
MORE ***.  General purpose off the shelf (commonly called COTS) is known
to be more generally useful and less expensive because it is mass
produced by the competitive marketplace.  Perhaps you could add words to
that effect in the justification.

Mike

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Wednesday, January 04, 2006 9:35 AM
> To: 'Andrew Newton'; Michael Hammer (mhammer)
> Cc: [email-masked]
> Subject: RE: [Ecrit] Issue 10: Design of Non-Emergency Components
> 
> I am full agreement with this, and it's pretty important.  
> What is interesting is that it represents a change from what 
> is now done.
> In North America, and in some other areas, the form of 
> address used in the emergency system is DIFFERENT from the 
> form commonly used for other purposes.  There are mostly 
> historical reasons for much of the differences.
> We have had quite a bit of resistance within the NENA 
> community for the idea that if we are to have a really 
> effective system for all kinds of new services based on IP, 
> then the location information must be useful beyond just 
> emergency calls.  Location is commercially valuable, but only 
> if the information is not obscured in some way.  The current 
> systems do.
> 
> We've started making this transition in the NENA i2 standard. 
>  Location as used within the IP world is a new form that is 
> closer to common usage.  We have translation to the existing 
> form because we can't change out the current systems 
> wholesale (in fact i2 is designed to not require any changes 
> at the PSAP).
> 
> I do have to point out that you can't equate this with postal 
> addresses; the address for postal delivery is NOT always the 
> address for dispatch of emergency responders.  The database 
> SHOULD be able to store enough data so that translations are 
> possible, because when you ask someone for a location, they 
> often respond with a postal address.  Specifically, for North 
> America, we need to have the jurisdictional community name 
> (actual city/town/...), which may be different from the post 
> office name.  The database should store both.  The mapping 
> protocol only needs the jurisdictional community name.
> 
> Brian
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Andrew Newton
> Sent: Wednesday, January 04, 2006 9:12 AM
> To: Michael Hammer (mhammer)
> Cc: [email-masked]
> Subject: Re: [Ecrit] Issue 10: Design of Non-Emergency Components
> 
> 
> On Jan 3, 2006, at 11:35 AM, Michael Hammer ((mhammer)) wrote:
> 
> > This statement is rather cryptic and should be rewritten.
> >
> > I could take this to mean that, while call routing has been 
> designed 
> > to give priority to emergency calls in call processing, there is no 
> > priority given to processing of location lookups of 
> emergency versus 
> > Starbucks.
> >
> > Or is it just saying, if the functional element is not labeled 
> > "emergency", it is not guaranteed to work?
> 
> I wasn't trying to say that at all.
> 
> Essentially, there are databases of civic addresses within 
> location information servers.  These databases may be used 
> for multiple purposes and multiple applications.  The mapping 
> protocol should not require that data within these databases 
> be transformed or modified in any unusual or unreasonable way 
> just so the mapping protocol may use the data.
> 
> -andy
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
> 

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

---

From: "Roger Marshall" <[email-masked]>
Date: Fri, 13 Jan 2006 21:31:54 -0800

Issue 10 (ref. http://www.ietf-ecrit.org:8080/ecrit-req/issue10)

In reference to the thread below, how then should the proposed text be
worded?  Consider the following attempt at capturing what Andy is
suggesting:

"Rxx.  No Modification of Location Databases:  Databases containing
civic location data MAY be used for multiple purposes  multiple
applications, in addition to the purpose of routing E9-1-1 calls.

Motivation:  The mapping protocol should not require that data within
these databases be transformed or modified in any unusual or
unreasonable way in order for the mapping protocol to use the data."

Comments welcomed, of course.

Roger.

>On Behalf Of Michael Hammer (mhammer)
>Sent: Wednesday, January 04, 2006 7:05 AM
>To: [email-masked]; Andrew Newton
>Cc: [email-masked]
>Furthermore, I would support making this a clear statement.  
>Someone needs to point out to the NENA community that 
>specialized software/hardware designed specifically for 
>government use *** COSTS MORE ***.  General purpose off the 
>shelf (commonly called COTS) is known to be more generally 
>useful and less expensive because it is mass produced by the 
>competitive marketplace.  Perhaps you could add words to that 
>effect in the justification.
>
>Mike
>
>
>> What is interesting is that it represents a change from what is now 
>> done.
>address used in 
>> the emergency system is DIFFERENT from the form commonly used for 
>> other purposes.  There are mostly historical reasons for much of the 
>> differences.
>> We have had quite a bit of resistance within the NENA community for 
>> the idea that if we are to have a really effective system for all 
>> kinds of new services based on IP, then the location 
>information must 
>> be useful beyond just emergency calls.  Location is commercially 
>> valuable, but only if the information is not obscured in some way.  
>> The current systems do.
>> 
>closer to 
>> common usage.  We have translation to the existing form because we 
>> can't change out the current systems wholesale (in fact i2 
>is designed 
>> to not require any changes at the PSAP).
>> 
>> addresses; the address for postal delivery is NOT always the address 
>> for dispatch of emergency responders.  The database SHOULD 
>be able to 
>> store enough data so that translations are possible, because 
>when you 
>> ask someone for a location, they often respond with a postal 
>address.  
>> Specifically, for North America, we need to have the jurisdictional 
>> community name (actual city/town/...), which may be 
>different from the 
>> post office name.  The database should store both.  The mapping 
>> Essentially, there are databases of civic addresses within location 
>> information servers.  These databases may be used for multiple 
>> purposes and multiple applications.  The mapping protocol should not 
>> require that data within these databases be transformed or 
>modified in 
>> any unusual or unreasonable way just so the mapping protocol may use 
>> the data.
>> 
>> -andy
>>