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

[John Lange <john at johnlange.ca>]

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