[Ecrit] Additional framework-03 and phonebcp-02 comments

["Stark, Barbara" <[e-mail]>]

Brian and I had a little chat at the Emergency Services Workshop, and I
agreed to provide some suggestions for additions to phonebcp, to bring
into it some more of the details that are currently in the DSL Forum
WT-164 text.

Here's a summary of what the comments in this email are about:
 - Address non-SIP intermediary devices (ie, routers) better. AN-12 is
awkward, since the home router isn't really a part of the access
network. Also address case where calling application is distinct from
OS, and cannot control the OS. Need to improve terminology section to
better describe these.
 - LIS and LoST server determination
 - DHCP INFORM usage
Not included in this email are the detailed flows. If others want them
added to phonebcp, we should discuss. I'm not sure how those would get
translated to an IETF document.

Terminology
Need to define ED, AN, SP abbreviations:
ED - the User Equipment (UE) of ecrit-requirements
AN - the Access Network of ecrit-framework
SP - the ASP (of which VSP is a subset) of ecrit-requirements

Add a new device type of "INT" for Intermediary Device
Need to define this uniquely within phonebcp, since it's not defined
elsewhere. Or else define in framework and describe its role in a
subsection of 6.2 Location Determination. It would probably need to be
defined as a device that is in close proximity to the ED (within a
"small area") and provides a NAPT function between the WAN and the LAN
that the ED is in. In general, it will also provide DHCP server
functionality, and may have DHCP client capability on its WAN side.
While it is possible for the emergency framework to work without
upgrading most legacy intermediary devices, the possibility of failure
is decreased when these devices are upgraded to support the
functionality identified in phonebcp.

The following phonebcp requirements would apply to an INT:
ED-12 through ED-27, AN-1 through AN-3, AN-5, AN-6, AN-11, AN-13, AN-16

After ED-21, there needs to be a requirement that defines the
recommended defaults for parameters in a HELD request. My previous email
gave suggestions for responseTime. It may also be useful (but may not be
necessary) to suggest that the default for all other parameters SHOULD
be null.

New: The device MUST support a random back-off period (between 30
seconds and 300 seconds) for re-trying the HELD query, when no response
is received.

New: ED-xx  If the device is configured to use DHCP for bootstrapping,
it MUST include both options for location acquisition (civic and
geodetic), the option for LIS discovery, and the option for LoST
discovery as required in [requirement references]. 

New: ED-xx  If the device sends a DHCP INFORM message, it MUST include
both options for location acquisition (civic and geodetic), the option
for LIS discovery, and the option for LoST discovery as required in
[requirement references].

Change AN-12 to an INT requirement.

In ED-24, I recommend changing "non-bypassable VPNs" to "VPNs that do
not allow split tunneling" to use more standard jargon.

--- new section --- Need a section on LIS and LoST Discovery
New: ED-xx  Endpoints MUST support one or more mechanisms that allow
them to determine their public IP address. Examples include ICE and HTTP
get.

New: ED-xx  Endpoints MUST support LIS discovery as described in
[LIS-DISCOVERY], and the LoST discovery as described in
[LOST-DISCOVERY]. [need to add these references, see below]

New: ED-xx  The device MUST have a configurable default LoST server
parameter. If the device is provided by or managed by an Application
Service Provider (ASP), such as a Voice Service Provider (VSP), it is
expected that the ASP will configure this option.
 ---- end new section---

After ED-27:
New: ED-xx  If a location refresh fails (that just attempts to use the
last successful method), the endpoint MUST attempt all location
configuration options. If the location can still not be determined, the
endpoint MUST continue to use its last known location.

--- new section --- Need a section for requirements for OSs, and for
applications running on OSs that provide location to apps. Also,
requirements for apps running on OSs that don't provide location, and
where the app can't control LLDP or DHCP.

??-xx  If the client that needs the location information is unable to
control Layer 2 and 3 protocols, then that client application MUST
attempt to get location, LIS, and/or LoST information from the OS,
before proceeding with location acquisition using HELD.

??-xx  In many cases, Operating Systems (OSs) will need to do location
configuration for applications that run on top of them. The following
requirements apply to such OSs: ED-12 through ED-18 and ED-21 through
ED-27. (ED-20 doesn't seem like it applies to an OS?)

??-xx OSs that do location configuration operations on behalf of
applications MUST provide a published interface for applications to get
their location information from the OS. 
 ---- end new section---

ED-48: add phrase at end of reqt "...whenever they get an initial or
updated location."

Additional References
[lost-discovery] Schulzrinne, H., J. Polk, and H. Tschofenig, "A Dynamic
Host Configuration Protocol (DHCP) based Location-to-Service Translation
Protocol (LoST) Discovery Procedure",
draft-ietf-ecrit-dhc-lost-discovery-02, July 2007

[lis-discovery] Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)"
draft-thomson-geopriv-lis-discovery-03 (work in progress), September
2007)

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