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

["Winterbottom, James" <[e-mail]>]

Brian,

HELD can use the HELD Identity extensions specification that support
providing that information.

Cheers
James


> -----Original Message-----
> From: Brian Rosen [mailto:[e-mail]]
> Sent: Monday, 19 November 2007 1:36 PM
> To: 'Stark, Barbara'; 'ECRIT'
> Subject: RE: [Ecrit] Additional framework-03 and phonebcp-02 comments
> 
> 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

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]


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