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

From: "Brian Rosen" <[email-masked]>
Date: Tue, 8 Nov 2005 21:49:35 -0500

Consider adding the following paragraph to the introductory text on mapping:

Ideally, the mapping protocol would yield a URI which would allow an
emergency call to be completed on the Internet.  However, not all PSAPs may
have IP based connectivity.  Thus the URI scheme cannot be fixed, and in
fact may end up being a tel uri to allow calls to be completed on the PSTN.

________________________________________
From: Roger Marshall [mailto:[email-masked]] 
Sent: Tuesday, October 18, 2005 4:50 PM
To: [email-masked]; [email-masked]
Subject: RE: [Ecrit] NENA Comments on draft-ietf-ecrit-requirements-00
-Alternate Routes

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

---

From: "Roger Marshall" <[email-masked]>
Date: Wed, 9 Nov 2005 10:20:53 -0800

I've added this to the issue tracker as #28.  http://www.ietf-ecrit.org:8080/ecrit-req/

Roger Marshall 

>-----Original Message-----
>From: Brian Rosen [mailto:[email-masked]] 
>Sent: Tuesday, November 08, 2005 6:50 PM
>To: Roger Marshall; [email-masked]
>Subject: RE: [Ecrit] NENA Comments on 
>draft-ietf-ecrit-requirements-00 -Alternate Routes
>
>Ideally, the mapping protocol would yield a URI which would 
>allow an emergency call to be completed on the Internet.  
>However, not all PSAPs may have IP based connectivity.  Thus 
>the URI scheme cannot be fixed, and in fact may end up being a 
>tel uri to allow calls to be completed on the PSTN.
>
>Subject: RE: [Ecrit] NENA Comments on 
>draft-ietf-ecrit-requirements-00 -Alternate Routes
>
>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
>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.
>
>
>