Subject: [Ecrit] Identifying the Appropriate PSAP section (<draft-schulzrinne-ecrit-requirements-01.txt>)

From: "Tschofenig, Hannes" <[email-masked]>
Date: Tue, 9 Aug 2005 11:24:17 +0200

hi all, 

please find my comments below (#). 

this section seems to require some editing. 

6.  Identifying the Appropriate PSAP

# this section outlines the requirements for the mapping protocol. 
# maybe we should just give it that name. 

# i also think that the next few paragraphs can be replaced by a short
paragraph describing the problem statement. 
# this is all about determining the mapping between location information
and one (or multiple) uris. 
# it is ok to mention that there are two approaches for triggering the
mapping protocol: 
  * caller-based 
  * mediated. 

   From the previous section, we take the requirement of a single (or
   small number of) emergency addresses which are independent of the
   caller's location.  However, since for reasons of robustness,
   jurisdiction and local knowledge, PSAPs only serve a limited
   geographic region, having the call reach the correct PSAP is crucial.
   While a PSAP may be able to transfer an errant call, any such
   transfer is likely to add tens of seconds to call setup latency and
   is prone to errors.
# the last sentence either needs more explanation or needs to be
removed. 

  (In the United States, there are about 6,100
   PSAPs.)
# what is the relationship to the rest of the paragraph? 

   There appears to be two basic architectures for translating an
   emergency identifier into the correct PSAP emergency address.  We
   refer to these as caller-based and mediated.  In caller-based
   resolution, the caller's user agent consults a directory and
   determines the correct PSAP based on its location. 

 We assume that
   the user agent can determine its own location, either by knowing it
   locally or asking some third party for it.  A UA could conceivably
   store a complete list of all PSAPs across the world, but that would
   require frequent synchronization with a master database as PSAPs
   merge or jurisdictional boundaries change.
# i would delete these few sentences. it is obvious that the entity that
triggered the mapping protocol needs to use location information  as
input to the protocol. 

   For mediated resolution, a call signaling server, such as a SIP
   (outbound) proxy or redirect server performs this function.  Note
   that the latter case includes the architecture where the call is
   effectively routed to a copy of the database, rather than having some
   non-SIP protocol query the database.

# what should the last sentence tell us? 
# is this a protocol proposal?

  Since servers may be used as
   outbound proxy servers by clients that are not in the same geographic
   area as the proxy server, any proxy server has to be able to
   translate any caller location to the appropriate PSAP.  (A traveler
   may, for example, accidentally or intentionally configure its home
   proxy server as its outbound proxy server, even while far away from
   home.)

   The resolution may take place well before the actual emergency call
   is placed, or at the time of the call.

# we could add this somewhere to the requirements? if the resolution
took place before the emergency call was triggered then no constraints
are imposed on the solution. in fact this statement is captured with
I42. 

   The problem
# Location-based (or context based) routing 
 is harder than for traditional web or email services.
   There, the originator knows which entity it wants to reach,
   identified by the email address or HTTP URL.

# i think that the comparison with http is not really appropriate. 

  However, the emergency
   caller only dialed an emergency identifier.  Depending on the
   location, any of several ten thousand PSAPs around the world could be
   valid.

# we use several different terms to denote a psap that is responsible
for a certain geographical region: valid, appropriate, correct

  In addition, the caller probably does not care which specific
   PSAP answers the call, but rather that it be an accredited PSAP, e.g.
   one run by the local government authorities.  (Many PSAPs are run by
   private entities.  For example, universities and corporations with
   large campuses often have their own emergency response centers.)
# i suggest to move these issues down to the requirements. the fact that
a psap might be run by a private entity is an operation  requirement and
might not even belong to this document. 

Schulzrinne & Marshall    Expires November 2, 2005             [Page 13]

Internet-Draft             ECRIT requirements                   May 2005

   I1.  Correct PSAP: Calls Must be routed to the PSAP responsible for
                            ^^^^
#                           MUST

      this particular geographic area.

      Motivation:  In particular, the location determination should not
      be fooled by the location of IP telephony gateways or dial-in
      lines into a corporate LAN (and dispatch emergency help to the
      gateway or campus, rather than the caller), multi-site LANs and
      similar arrangements.

# i don't see how the motivation relates to the requirement 

   I3.  Multi-stage resolution:
# multi-stage resolution is a confusing term here. we should use terms
we introduced in the terminology section. 

 A mapping server for a large geographic
      area SHOULD be able to refer clients to mapping servers
      responsible for subsets of the geographic area.

# this requirement should read :
"The mapping protocol MUST support redirection functionality." (if we
use the terms 'mapping protocol' and 'redirection')

      Motivation: In some cases, an initial mapping may provide a single
      URL for a large geographic area.  The ESRP identified by that URL
      then re-invokes the mapping protocol on a different database to
      obtain another URL for an ESRP or PSAP covering a smaller area.

   I4.  Return multiple PSAPs: The mapping protocol MUST be able to
      return multiple URLs for different PSAPs that cover the same area.

      The mapping protocol MUST provide additional information that
      allows the querying entity to determine relevant properties of the
      URL.

      Motivation: In some cases, the same geographic area is served by
      several PSAPs, for example, a corporate campus might be served by
      both a corporate security department and the municipal PSAP.  The
      mapping protocol should then return URLs for both, with
      information allowing the querying entity to choose one or the
      other.  The choice would typically be made by an ESRP based on
      local policy, not by a human user.

# the last sentence does not make sense if you also support caller-based
resolution. 

   I7.  Traceable resolution: The entity requesting mapping SHOULD be
      able to definitively and securely

# what does 'definitively and securely' mean? 

 determine the entity or entities
      who provided the emergency address resolution information.

# we should be a bit more specific about this requirement. what is the
impact of this requirement? 
is it sufficient to add an attribute to the returned object that the
mapping was provided by X or do we demand signing of the entity that
created the mapping? 

   I8.  Resilience against server failure: A client MUST be able to fail
      over to another replica of the mapping server, so that a failure
      of a server does not endanger the ability to perform the mapping.

   I10.  Incrementally deployable: The mapping function MUST be capable
      of being deployed incrementally. 

# here starts the motiviation. 

 It must not be necessary, for
      example, to have a global street level database before deploying
      the system.  It is acceptable to have some misrouting of calls
      when the database does not (yet) contain accurate boundary
      information.

Schulzrinne & Marshall    Expires November 2, 2005             [Page 14]

Internet-Draft             ECRIT requirements                   May 2005

   I13.  Existing infrastructure support: 

# this requirement needs to be split into a requirements part and a
motivation part. 

It SHOULD be possible for the
      mapping function to provide information that allows the requesting
      entity to determine if ecrit compatible emergency call support is
      available in the jurisdiction where the location is proferred for
      mapping.

# hmm. i am not sure what this means. 

  Where ecrit compatible emergency calling is NOT
      available, the mapping function MAY yield information which could
      be used to route emergency calls using existing, country specific
      methods.

# what is ecrit compatibility? 
in the working group we develop requirements and (hopefully soon) a
solution for a mapping protocol. 

  For example, a tel URI may be provided for a PSTN routed
      call, or a routing code which has meaning only within a country
      specific routing mechanism.

   I25.  Mapping can be requested from anywhere: The mapping protocol
      MUST be able to provide the mapping regardless of where the
      querier is located, either geographically or by network location.

      Motivation: The querier, such as the ESRP, may not necessarily be
      anywhere close to the caller or the appropriate PSAP, but must
      still be able to obtain a mapping.

   I31: In response to a mapping request, a server will normally provide
      a URI or set of URIs for contacting the appropriate PSAP.  The
      protocol must also be to return a URI or contact method explicitly
      marked as an alternate contact.  When this is used will be
      described in an operational document.

# rewrite this paragraph as a requirement: 

# I31: Multiple URIs: The mapping protocol MUST allow a response to
carry multiple URIs. 

# the alternative contact might be a separate requirement. 

   I39: It SHOULD be possible to have updates of location (which may
      occur when measuring devices provider early, but imprecise "first
      fix" location) which can change routing of calls.

# add I39: Location Update: 

   I40.  The mapping protocol MUST be extensible to allow for the
      inclusion of new location fields.

      Motivation: This is needed, for example, to accommodate future
      extensions to location information that might be included in the
      PIDF-LO.
# reference to pidf-lo missing. 

   I41.  Split responsibility: The mapping protocol MUST allow that
      within a single level of the civic address hierarchy, multiple
      mapping servers handle subsets of the data elements.

# why is this only related to civic location info? 

      Motivation: For example, two directories for the same city or
      county may handle different streets within that city or county.

   I42.  The mapping function MUST be able to be invoked at any time,
      including while an emergency call is in process.

ciao
hannes

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