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

["Stark, Barbara" <bs7652 at att.com>]

Going back to respond to John's original email...

John,
2. I agree with your LIS discovery issues regarding legacy home routers
with NAT. However, solving this does not require new protocols;
therefore, I've decided to not object to the current lis-discovery
document proceeding as it is. The DHCP options for LIS discovery are
needed for the long-term. Getting end VoIP devices to use STUN and do
reverse DNS can be handled separately, either with the IETF (e.g.,
Martin's res-gw-lis-discovery document) or external to the IETF.

3. As for recommended proxy on-behalf-of behavior, the current wording
doesn't bother me, although your alternate wording is also fine. It
doesn't bother me, because it doesn't change the requirements on the end
devices, access nodes, or access networks. Those are the things that
have to be very predictable in their behavior, if this architecture is
to ultimately succeed. If I were to feel that a proxy under my control
should try to get locations, and if such behavior were consistent with
the regulatory environment my proxy operated in, then I would have it do
just that, no matter how phonebcp is worded.

1. Your suggestion that the device tell its location to its SIP
registrar causes me some difficulty. In this case, the device already
has its location, so it should also have its PSAP route info. If the
device has location and emergency routing info, then the SIP registrar
and VSP should just be able to dumbly route. Even if they don't
recognize it as an emergency call, they should still be able to route.
If the device can't update its location, it will use its locally cached
information -- so having the VSP cache this exact same location info
would be redundant. Having VSPs that operate inside a country do certain
things to ease the transition, like querying location on behalf of
location-less devices, is fine, if that's what's desired. Building
dependencies on VSP behavior is bad. You don't know where in the world
the VSP will be. You don't even know if the "VSP" is nothing more than
an Asterix PBX in someone's basement. And there's no need for the
emergency call to fail, just because the VSP is foreign. That's part of
the beauty of the current architecture -- it's independent of VSP
nationality. The device, the access network, and the desired PSAP are
usually (not always, in border scenarios) inside the same country. The
VSP (registrar) is anywhere.
Barbara

> -----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

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623