Subject: RE: How to handle Validation failures was RE: [Sipping-emergency]proposed charter, new wg on emergency

From: [email-masked]
Date: Tue, 28 Sep 2004 06:58:19 -0400

Validating location information is implicit for routing. Otherwise, all calls would be treated as "default" routed or worse, would rely on other mechanisms to provide routing instructions outside the control of the ECC (the ECC currently provides instructions and input on the construct of the MSAG to the extent possible, which is used for the validation process). Unvalidated location information could reduce or even prevent a timely emergency response to a particular location. As I implied before, the lack of validation should not prevent delivery of a call to a geographically appropriate ECC however, all efforts need to be made to ensure that end devices utilize validated location information. So, if the charter of this effort is to decide on how routing is accomplished than validation of the information used to make that routing decision should be considered in the process as well.

Nate 

-----Original Message-----
From: Peterson, Jon [mailto:[email-masked]]
Sent: Monday, September 27, 2004 7:42 PM
To: 'Brian Rosen'; 'Marc Linsner'; [email-masked]
Subject: RE: How to handle Validation failures was RE:
[Sipping-emergency]proposed charter, new wg on emergency

> I changed the subject, as we are off the subject of a new charter,
> as we agree validation should be in that charter.
> 

Brian,

I'm not sure that everyone on this distribution agrees that validation
should be in the scope of this proposed working group. In fact, until I read
your mail, I had gotten the sense that several voices (including James, Marc
and Nate) were questioning this idea.

I think validation as such is probably outside of the core expertise of the
IETF, whereas routing is more likely to be a place where we can do some
solid work. The expertise of the IETF does not lie in subjects like whether
Conrad St is in Butler County or Pine Township, nor in recommending how you
might figure something like that out. Moreover, this seems to be a back-end
application issue, not a protocol issue, as I think a number of people have
already pointed out.

I think that validation is a separable operation from routing, even if it is
a prerequisite in some operational models. An umbrella specification that
described everything you needed to do in order to provide emergency services
might include validation, but that doesn't mean that the routing protocol
should change in any way because validation was or was not performed. But I
don't think the IETF has the breadth to tackle that whole umbrella.

Jon Peterson
NeuStar, Inc. 

_______________________________________________
Sipping-emergency mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-emergency

_______________________________________________
Sipping-emergency mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-emergency

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 28 Sep 2004 08:29:26 -0400

This can be seen as a special case of testing. Thus, if you assume that 
there is a test mode that attempts to reach the PSAP, but does not 
actually ring, you'd have tested the full routing chain, including 
whether the civic address is indeed mappable.

A separate question is whether a separate address-only validation mode 
is appropriate. This probably depends on the overall architecture. As 
we've discussed before, I think there is general agreement that you'd 
want the ability for end-to-end non-interfering testing in any event.

[email-masked] wrote:
> Validating location information is implicit for routing. Otherwise,
> all calls would be treated as "default" routed or worse, would rely
> on other mechanisms to provide routing instructions outside the
> control of the ECC (the ECC currently provides instructions and input
> on the construct of the MSAG to the extent possible, which is used
> for the validation process). Unvalidated location information could
> reduce or even prevent a timely emergency response to a particular
> location. As I implied before, the lack of validation should not
> prevent delivery of a call to a geographically appropriate ECC
> however, all efforts need to be made to ensure that end devices
> utilize validated location information. So, if the charter of this
> effort is to decide on how routing is accomplished than validation of
> the information used to make that routing decision should be
> considered in the process as well.
> 
> Nate

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 28 Sep 2004 19:06:26 -0500

At 08:29 AM 9/28/2004 -0400, Henning Schulzrinne wrote:
>actually ring, you'd have tested the full routing chain, including whether 
>the civic address is indeed mappable.

how would a new user to a new area (say I just got off the plane in Chicago 
and didn't know I was actually 25 miles away from that city, and 
jurisdictionally in another ERC's area) know they had the wrong ERC say 
their phone will indeed contact the right ERC when they do call 911?

Will a red flashing light go off on the phone with a warning screaming 
"danger danger will robinson"?

That the phone can do this test is huge for this effort, it is just a 
matter of telling which ERC responded positively, and either knowing that 
the phone can call 911 when the emergency arrives or the wrong ERC (when 
contacted) can transfer the call when it is placed.

>A separate question is whether a separate address-only validation mode is 
>appropriate. This probably depends on the overall architecture. As we've 
>discussed before, I think there is general agreement that you'd want the 
>ability for end-to-end non-interfering testing in any event.
>

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented