Subject: RE: [Ecrit]EmergencyContextRoutingofInternetTechnologies-ArchitectureConsiderations

From: "Rodrig, Benny \(Benny\)" <[email-masked]>
Date: Sat, 10 Sep 2005 13:25:42 -0400

The enterprise can supply its nomadic members with IP devices capable of
automatically acquiring location e.g. via LLDP-MED or DHCP, but the
Internet Access Provider is still the only entity that can provide the
location information. If the Access Provider does not provide location,
the enterprise can not ensure that accurate location info is available,
can it? 

The VPN only makes the call route around, but with respect to
responsibility for determining caller location, is the enterprise
different from an ASP that is divorced from the Access Provider? 

Benny

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Abbott, Nadine B
Sent: Friday, September 09, 2005 10:22 AM
To: ECRIT
Subject: RE:
[Ecrit]EmergencyContextRoutingofInternetTechnologies-ArchitectureConside
rations

I admit I am a bit confused about exactly which requirement is being
debated/tailored...but if I'm not too far off...

It seems to me that the proposed requirement could be stated:
An emergency call should be able to be originated remotely via a VPN
through an enterprise network, and accurate location information for the
caller should be made available to route the call.

If the caller's IP device is capable of supporting a method for
acquiring its location (with or without the assistance of its local
access network), and is capable of storing and passing its location
information with call signaling in a PIDF-LO, then it is the
responsibility of the enterprise to pass that location information along
with the call. This makes it possible for an emergency call from an IP
device remotely connected to the enterprise VPN to still have its call
routed to the correct PSAP based on the caller's location.

The point of greatest difficulty is when either the IP device or its
local Internet access provider cannot support a method for the IP device
to acquire its location.  In this case, when the remote user originates
a call using a VPN to the enterprise, the enterprise must somehow
acquire location on-behalf-of the location-incapable/unaware device.
This is of concern in the real world because there are lots of existing
devices and networks that do not as yet support these capabilities. I
believe there are existing enterprise solutions that use provisioning to
support relatively static access via VPNs (e.g., the telecommuter with a
fixed home address). But the problem of the road warrior is much more
difficult. 

If we assume that it is the Internet access provider that is aware of
the remote IP device's location, then the road warrior problem requires
the enterprise to not only discover the IP device's Internet access
provider from among all possible Internet access providers, but also to
be able to exchange information necessary to determine the caller's
location with all such possible Internet access providers on-behalf-of
the IP device.  There is much discussion in North American forums about
what it might take to make this possible.
However, this IS a very complex problem, and the comments below seem to
be a pragmatic recognition that it may be a lot simpler for the
enterprise to supply its roaming members with IP devices that are
capable of automatically acquiring and passing location, than to support
the mechanisms necessary to acquire location information remotely on
their behalf. (Not to mention how much simpler it would also make life
for the Internet access providers.)

If the requirement is that emergency calls should be able to be
originated remotely via VPNs through an enterprise and that accurate
location information must be available to route the call, then there are
various solutions that can meet this requirement and these solutions
place varying degrees of responsibility on the enterprise and its IP
devices (with only a few possible examples sketched above).  It seems to
me that the enterprise that supports the VPN is the entity in the best
position to take ownership of the problem.  I think that maybe this is
not so much tailoring the requirement as it is an acknowledgment that
some solutions may be better than others in meeting the requirement? 

I might suggest a clarification to the requirement, e.g., If an
emergency call is originated remotely via a VPN through an enterprise
network, the enterprise shall ensure that accurate location information
for the caller is made available to route the call.

I do not think that this tailors the requirement to a particular
solution, but it does identify responsibility for the solution and makes
use of a VPN for this purpose conditional upon implementation of a
solution.

Nadine

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Marc Linsner
Sent: Friday, September 09, 2005 8:14 AM
To: 'Winterbottom, James'; 'Michael Hammer (mhammer)'; 'Stastny
Richard'; 'ECRIT'
Subject: RE:
[Ecrit]EmergencyContextRoutingofInternetTechnologies-ArchitectureConside
rations

I'm amused at the tayloring of requirements to meet solutions.

:^)

-Marc- 

> -----Original Message-----
> From: Winterbottom, James [mailto:[email-masked]]
> Sent: Thursday, September 08, 2005 8:36 PM
> To: Marc Linsner; Michael Hammer (mhammer); Stastny Richard; ECRIT
> Subject: RE: [Ecrit]
> EmergencyContextRoutingofInternetTechnologies-ArchitectureCons
iderations
> 
> It is also a way to eliminate draconian IS policies.. ;)
> 
> > -----Original Message-----
> > From: Marc Linsner [mailto:[email-masked]]
> > Sent: Friday, 9 September 2005 10:30 AM
> > To: Winterbottom, James; 'Michael Hammer (mhammer)'; 'Stastny
> Richard';
> > 'ECRIT'
> > Subject: RE: [Ecrit] EmergencyContextRoutingofInternetTechnologies-
> > ArchitectureConsiderations
> > 
> > 
> > >
> > > This issue has been discussed in NENA at quite some length. The 
> > > consensus that is growing there, and I know that
> there are some
> > > people that still disagree, is that if an enterprise is
> prepared to
> > > allow this to occur, that the onus is-Maqr on the enterprise to 
> > > ensure that it works.
> > > This makes the problem a little easier to deal with.
> > 
> > That's one way to eliminate difficult requirements.... :^)
> > 
> > -Marc-
> > 
> 
> --------------------------------------------------------------
> ----------------------------------
> This message is for the designated recipient only and may contain 
> privileged, proprietary, or otherwise private information.
> If you have received it in error, please notify the sender immediately

> and delete the original.  Any unauthorized use of this email is 
> prohibited.
> --------------------------------------------------------------
> ----------------------------------
> [mf2]

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

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

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