Re: [Ecrit] Emergency Call Framework for Canada; Questions on draft-ietf-ecrit-framework-09

["Brian Rosen" <br at brianrosen.net>]

At the time of the call, the device either does have its location, or it
doesn't.

If it does, then the SIP proxy can use it, if it needs to, because it's on
the signaling.
There isn't any point in caching it at the proxy, and it's a privacy issue
if it does.

The reason you want to get fresh location is that it's pretty darn hard to
know if a device is mobile and thus location at boot time is not necessarily
correct at run time.  If the device is fixed location, and the location at
boot is the same as location at call time, then if the location
infrastructure fails, the cached location is all you have, but it's correct.
That implies that the infrastructure doesn't absolutely need to be 5 nines.

"On behalf of" is needed when the device DOESN'T get it's location from its
access network.  I think you have a point on the language of the on behalf
of language in -phonebcp, but your suggestion is not good enough.  The
problem to be solved is one way or another we have to get location.  The
current wording is aimed at proxies who think they ought to do it always,
and the language says, fine, as long as you CAN do it always.  

Your language says "do it if you can" but that let's the proxy off the hook;
it has to work always.

I suppose we could craft something that is more like, if the proxy knows
that the device will be used on some networks that supply location to the
device, and in every other network it can supply location OBO, then it's
okay.

Brian

> -----Original Message-----
> From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org] On Behalf
> Of John Lange
> Sent: Monday, June 01, 2009 3:25 PM
> To: ecrit
> Subject: [Ecrit] Emergency Call Framework for Canada; Questions on
> draft-ietf-ecrit-framework-09
> 
> On April 15 2009, the Canadian Radio and Telecommunications Commission
> (CRTC), which is the Canadian equivalent of the FCC, issued "Telecom
> Notice of Consultation CRTC 2009-194".
> 
> http://www.crtc.gc.ca/eng/archive/2009/2009-194.htm
> 
> Paragraph 17 asks; "Are there alternative solutions that would improve
> on the current nomadic VoIP 9-1-1 service."
> 
> The proposed architecture was developed by Bell Canada based very
> loosely on NENAi2 with extensive modifications. As it was developed by
> the ILECs in 2006/2007, it does not employ the IETF standards.
> 
> I am working on a submission to this proceeding which advocates the
> implementation of the standards developed by the IETF's ECRIT working
> group and it's members. (As a side note, if there are any participants
> on this list which are interested in helping with this effort, please
> do
> contact me.)
> 
> After examining draft-ietf-ecrit-framework-09 and it's related RFCs and
> RFC-drafts, I have some specific questions/concerns which I hope this
> list can answer.
> 
> The Emergency Call Framework (ECF) as proposed :
> 
> - Location is cached at end-point during boot/location discovery but
> there does not appear to be any mechanism whereby the end-point
> announces the success of this process to the SIP Registrar.
> 
> If the device is able to determine it's location it should relay the
> location information to the SIP registration server and the SIP
> registrar should cache this information.
> 
> This allows the SIP Registrar and SIP proxy the ability to act
> "on-behalf-of" end points that are not able to determine their location
> either because they are not location capable, or because they are not
> able to determine location from their access provider.
> 
> Furthermore, it removes the burden of "real-time" "on-behalf-of"
> functionality from the rest of the network.
> 
> The ability of the registrar to query and cache location data for
> endpoints as opposed to the requirement to perform location
> determination in real-time, has a dramatic impact on the technical
> requirements of the overall solution.
> 
> If location data must be queried in real-time during an actual
> emergency
> event, the network components must be engineered to a much higher
> standard. In some jurisdictions the mandated hardware and network
> requirements will be impacted significantly. No less than redundant
> five-nine hardware running on dedicated private networks will be
> required resulting in higher costs.
> 
> I submit that a query-and-cache methodology is more in line with the
> spirit of other IETF protocols, the DNS system being a prime example.
> 
> - Concerns with draft-ietf-geopriv-lis-discovery:
> 
> The focus of LIS discovery seems to be on local access network methods
> such as DHCP and LLDP.
> 
> DHCP & LLDP are not good choices for LIS discovery because they are not
> supported in the residential market. Residential firewall devices are
> not likely to have DHCP/LLDP functionality and the likelihood that
> these
> devices will be replaced or upgraded is small.
> 
> It would therefore seem that the emphasis should be on a LIS discovery
> mechanism that does not rely on the local network such as STUN + DNS.
> 
> 1) Device determines its IP address by querying the STUN server.
> 2) Device determines its domain name using reverse DNS.
> 3) Device does LIS discovery via DNS (SRV/NAPTR).
> 
> - draft-ietf-ecrit-phonebcp 6.3: "Proxies MAY provide location on
> behalf
> of devices if: The proxy has a relationship with all access networks
> the
> device could connect to".
> 
> This wording seems overly restrictive; in effect "all access networks
> the device could connect to" amounts to every network on earth which
> seems like an unreasonably high standard.
> 
> How about:
> 
> "Proxies MAY provide location on behalf of devices if: the device does
> not provide it's own location and the proxy is able to determine
> location on-behalf-of the device.
> 
> Any comments and/or questions would be welcome.
> 
> Regards,
> --
> John Lange
> http://www.johnlange.ca
> 
> _______________________________________________
> Ecrit mailing list
> Ecrit at ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit