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

["Brian Rosen" <[e-mail]>]

Barbara

Thank you for these suggestions, and especially for proposing text.  I have
implemented all of them one way or another except the following two:

You suggested that devices need their own IP addresses.  I don't know what
that is for: HELD doesn't have a parameter for the identifier, it uses the
IP address in the request.

> 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.
I don't think that is right.  Trying HELD if you got DHCP to work will take
MANY seconds to time out.  I think you probably just use the cached
location.

Brian

> -----Original Message-----
> From: Stark, Barbara [mailto:[e-mail]]
> Sent: Tuesday, November 06, 2007 5:08 PM
> To: ECRIT
> Subject: [Ecrit] Additional framework-03 and phonebcp-02 comments
> 
> 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


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