Subject: RE: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00 -Alternate Routes

From: "Roger Marshall" <[email-masked]>
Date: Tue, 18 Oct 2005 13:49:35 -0700

Brian:
Please send proposed requirements text which addresses NENA's concerns.
It may also be helpful to provide examples of the different levels of
"default routing" and how this might be represented within the messaging
(after the mapping result is returned to the mapping client).
 
Roger Marshall.

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brian Rosen
	Sent: Tuesday, October 18, 2005 11:58 AM
	To: [email-masked]
	Subject: [Ecrit] NENA Comments on
draft-ietf-ecrit-requirements-00 -Alternate Routes

	More comments from NENA:

	In our requirement 3.4-4, we said, Mechanisms must be provided
to route emergency calls in areas not served by E9-1-1 to an appropriate
PSTN telephone number.  I31 is related to this, but doesn't cover it
adequately we feel.  One way to improve it would be to use a tel uri
with an e.164 as an example. 

	The issue of "default routing" must be covered in the
requirements.  This occurs when less than complete information or
inconsistent information is provided (for example, good community name,
but bad street name).  In these cases, some entity must determine a
route.  In general, there is a "default" route for levels of the address
hierarchy when data below that level is missing or inaccurate.
Generally, this is a "longest prefix match" problem.  The mapping
function could do this itself, or it could accept a less than complete
query (no data below city name for example), and return a mapping,
pushing the error resolution process back to the entity requesting
mapping.  We would prefer that the mapping function return a valid
default mapping if partial data is provided or data is inconsistent.
There are similar mechanisms needed for geo routing.  As a separate
requirement, it is important that somehow, the destination know that
default routing was used.  This implies that the mapping result includes
some kind of flag that default routing was used, and that flag can be
propagated downstream.

	Requirement I31b: The mapping protocol MUST be able to return a
URI or contact method explicitly marked as an alternate contact does not
adequately address our requirement 3.6-19: Multiple types of failures
may have different contingency routes.

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