Subject: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 Misc

From: "Brian Rosen" <[email-masked]>
Date: Tue, 18 Oct 2005 15:00:41 -0400

Final set of comments from NENA:

Requirement R7 may need some more text.  First of all, the word “modes” may
be confusing.  Consider “media types”.  Then, this requirement has non
obvious consequences, which may need to be included in the requirements. 
For example, when a relay is used, the location of the caller, not the
location of the relay must be used for routing.  Just saying it must be
possible to have a relay doesn’t imply routing on the location of the
caller, since it may be the relay that originates the call.  Also note the
subtlety that location may be automatically be supplied when emergency calls
are placed, but not when calls are placed to relays.  If the relay
“elevates” the call to be an emergency call, location has to be made
available.  This may interact with the ecrit charter item on identifying
calls as emergency calls (the call to the relay is not an emergency call
originally), but mostly points out yet again that there is no “big picture”
of how emergency calls work in the IETF. 

Requirement I7 was narrowed from our original requirement 3.1-1 to only
encompass the entities doing the mapping.  We understand that this was
necessary to meet the charter limitations of ecrit.  Again, this points out
the issue that there is no place to take the general requirement. 
Specifically, however, the real requirement is actually that the PSAP knows
who did the mapping (UA or proxy).  This is not covered; I7 says the entity
requesting mapping knows the source of the mapping data. 

We note that there is no actual requirement to support both geo or civic
based mapping.  It is implied, but not required.  Also note our requirement
3.6-3, where we wished to have a requirement that the mapping function not
require a conversion (albeit not prohibiting an implementation from using
conversion) to determine the mapping.  Conversion introduces error, and it
may be important to not have that error.  There are also some requirements
we had on control of conversion data (36-4 to 3,6-6) which may be needed
depending on how the final requirements come out. 

We note that while there was a great discussion on the list on what happens
if there is more than one location source, and we agree it is not the
mapping functions responsibility to decide which of several locations should
be used, we none-the-less must mention this issue somewhere, and
specifically state what happens if there is more than one presented to the
mapping function. 

In our requirement 3.5-3, we requested If it is determined that an address
is invalid, an error diagnosis should be supplied if appropriate, as well as
a contact URI for resolving errors in the database.  This is an important
requirement, and needs to be included in the ecrit mechanism. 

There is no equivalent of our Requirement 3.6-11: Routing databases using
9-1-1 Valid Addresses or lat/lon/altitude as keys must both be available to
all entities needing to route 9-1-1 calls.  It is particularly important
that entities be able to map where the entity is not near, and has no
relationships with, any entities within the area of the endpoint (unless it
is always the endpoint that does the mapping). 

There is a currently running discussion on when mapping is done.  Please
note our requirement 3.6-15: Routing as specified in Req ? may change on
short notice due to local conditions, traffic, failures, schedule, etc. 

We do not believe our requirement 3.6-14 has been included: It is desirable
for higher level civic authorities such as a county or state/province to be
able to make common routing decisions for all PSAPs within their
jurisdiction.  For example, a state may wish to have all emergency calls
placed within that state directed to a specific URI.  This does NOT imply a
single answering point; further routing may occur beyond the common URI is
adequately covered.  D7 isn’t it.  This is the notion of an ESRP, but there
do not appear to be any requirements that say this is possible.  One of the
considerations we may wish to consider is how the ESRP routes.  One
mechanism would be to allow the information returned to be dependent on the
entity querying.  There may be other mechanisms. 

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