Last Call Review of draft-forte-lost-extensions-
review-forte-lost-extensions-secdir-lc-wallace-2011-08-14-00

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments
just like any other last call comments.

This draft defines extensions to the LoST protocol defined in RFC 5222.
Where RFC 5222 focuses on emergency services.  This draft addresses usage
of the protocol for non-emergency services.  The draft adds three new
types of <findService> queries: N nearest, within distance X and servedBy.
 The security considerations section is very brief and primarily addresses
potential problems with a LOST server that provides emergency and
non-emergency service support being over loaded by non-emergency requests.
 A few additional concerns that may warrant mention in the document are
below.

Privacy is not mentioned in this draft at all.  RFC 5222 mentions using
HTTP over TLS.  Queries for some types of non-emergency services may raise
privacy concerns not associated with seeking emergency services.
Similarly, the draft does not mention integrity.  The lack of privacy or
integrity for responses residing in a cache may be worth mentioning as
well. 

The draft does not discuss error handling at all.  Some types of errors
associated with the extensions do not seem to fit into the errors
described in RFC 5222.  For example, could a server return an error when a
requested area was too large for a query?  Is the server allowed to place
its own limits less than a client requests?  These concerns may not arise
in 
the 5222 context, where non-overlapping service regions are a mitigation.

Given the commercial focus of the draft, the potential for stale
information to be returned by a server seems high and probably worth a
mention.  For example, a pizza service may have closed.

Services are identified by URN.  RFC 5222 uses URNs defined in RFC 5031,
which does not apply here.  Who manages the URNs for this draft?  It's
worth noting the examples within this draft use different URNs to
reference the important pizza service.

A few nits, on page 11 correct "consinstent".  Also the next to last
paragraph on page 11 is a little difficult to parse.