Subject: [RAI] Review of draft-forte-lost-extensions-02

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 25 Jan 2011 10:56:43 +0800

Review of draft-forte-lost-extensions-02
Martin Thomson, 2011-01-25

  I don't think that I've had the opportunity to comment on this draft
  before.  There are several issues that I think prevent this draft from
  being the basis for interoperable implementations.

  The most significant concern I have arises from the underlying model that
  is used to define the extensions to the <findService> query.  Lack of
  clarity on how the draft defines the problem translates into what I think
  is a confused solution.

  The solution as described can be made to work, but it relies on
  assumptions that are not documented.  As documented, there are likely to
  be interoperability issues.

Terminology
  Section 3 of this document refines the concept of a service region.
  Three concepts are extracted from the basic ideas in RFC 5222:

    1. services without the concept of a service region (point-based
       services that are identified purely by proximity)

    2. services that serve a geographic area where the geographic area for
       different services of the same basic type overlap significantly (for
       example, the overlapping serving area of competing home delivery
       services)

    3. services that serve strictly non-overlapping geographic areas for a
       particular service (that is, PSAPs)

  The latter two cases are both referred to as "service region" without
  qualification.  It appears that (2) is the concept intended in most
  cases.  Some clearer terminology might help.  Perhaps if you use "service
  boundary" - as RFC 5222 uses it - to refer to the fence that is crossed
  where answers might change; and "served region" or to refer to the
  geographic area that is served by the particular service instance.

  Thus you can observe that service boundaries might be of limited use
  where multiple services of the same type have overlapping served regions.
  And you can also observe that some services lack a served area; and for
  these services, a service boundary may for different reasons (it's only
  the area where the N service instances provided in the answer are closer
  than other instances).

Extension proposals
  RFC 5222 is dreadfully vague on the use of geographic areas in the
  <location> element.  Particularly when the area intersects with the areas
  of multiple services.  I have inferred that the idea is that the LoST
  server picks the single best choice, because that makes the most sense
  for emergency uses (no good comes from presenting a choice in these
  cases).

  What this draft proposes for "within X" relies on some sort of implicit
  processing that is inconsistent with RFC5222.  It relies on the fact that
  the LoST server knows that a particular service is somehow special.

  This doesn't make for very clear protocol semantics.  It's probably still
  viable, but the document needs to make this assumption clear.

  I'm not sure how this out-of-band information interacts with recursive
  resolution.  A LoST gateway that performs recursive lookups might not be
  able make the right choice without an explicit, in-band indication of
  intent.

  Attempting to overload the <location> element as described in Section 5.1
  does not make for clear protocol semantics.

  My reading of RFC5222 leads me to infer that there is an implicit
  <le:limit> parameter in the protocol that is set to 1.  There's always
  the possibility that a location with uncertainty overlaps the served area
  of multiple PSAPs - but LoST assumes that there is only one right answer.

  It seems like the right way to approach the proposed extensions is to
  lift the implied limit beyond 1.  Adding the <le:limit> element seems
  like the right thing to do, but the semantics that I associate with
  <le:region> element doesn't seem to fit.

  I'd encourage the authors to re-examine the basic model they are using to
  construct their proposed solution.

  Section 5.3 seems very confused for these reasons.  A simpler model would
  require less explanation.

On <le:limit>
  Section 5.4 states:

   When the <limit> element is not present in a <findService> query then
   all available points of interest for the requested type of service
   SHALL be returned by the LoST server.

  Which seems contrary to what is implicit in RFC5222.  See above.

On <le:serviceLocation>
  The admonition:

   [...] Only geodetic profiles SHOULD be used [...]

  ... and subsequent use of an unwrapped <ca:civicAddress> element in the
  <mapping> element is strange.  How is a civic address not the location of
  the service?  If there are multiple forms of location, it would be better
  to use similar guidance to what is in RFC5491:

    1. recommend multiple <le:serviceLocation> elements when there are
       multiple forms available

    2. recommend that a geodetic form is provided where possible

  The location profile can be used to identify which location you want to
  use if the content of the element is not sufficient.

  The reason given for these recommendations:

    [...] as the computation of the distance, route and other metrics
   would at some point require geocoding of the civic address in
   geodetic coordinates.  Because of this, the position specified in
   <serviceLocation> SHOULD be represented by using the <Point> element.

  ... is not necessary for interoperability.  This seems more for the
  convenience of LoST server implementations.  Wouldn't these reasons be
  better suited to a LoST server provisioning guide?

  A better reason might be that a recipient of the mapping information
  might need to use this information without the necessary context to
  understand the civic address.  However, the same reason doesn't support
  the recommendation for using a <gml:Point>.

Iterative Responses
  The use of iterative resolution in LoST is a weak point that the ability
  to provide multiple mappings does not help.  In the case where a server
  is able to provide only some answers, there is no facility for the server
  to indicate where the remainder of the answers are found (that is, the
  referral).

  Even if you can address that concern, there's also the concern that the
  referred LoST server is able to provide better (closer) answers than the
  ones provided.  The draft might offer guidance on how to resolve this
  issue.

Security
  The security section could use some expansion.  It's not sufficient to
  just refer to RFC5222.

  The denial of service concerns that Shida raised in his review are worth
  discussing.  A LoST server is discovered using the same means whether it
  be for emergency or commercial uses.  The possibility that commercial
  uses could interfere with public safety is a significant concern.  As
  Shida notes, scaling is probably trivial to address, but that's not the
  whole story.

  We've seen problems that overwhelm a system, despite calculations
  predicting ample capacity, simply due to high demand for a particular
  application that is poorly configured.  Specific mechanisms to protect
  public safety queries might be difficult to design, but the document
  should at a minimum acknowledge the problem.

Nits:
  Section 5.2 - typo: wether

  Most of the examples use http://www.thisisnotdoneyet.net/lostNe still.

  Using a namespace prefix of "gml" rather than "p2" would be more helpful
  to the reader.  Consistent use of namespace prefixes throughout would
  also help disambiguate the three or so namespaces used.

--Martin