[Ecrit] Document Action: 'LoST Service List Boundary Extension' to Experimental RFC (draft-ietf-ecrit-lost-servicelistboundary-05.txt)

[The IESG <[e-mail]>]

The IESG has approved the following document:
- 'LoST Service List Boundary Extension'
  (draft-ietf-ecrit-lost-servicelistboundary-05.txt) as an Experimental
RFC

This document is the product of the Emergency Context Resolution with
Internet Technologies Working Group.

The IESG contact persons are Robert Sparks and Gonzalo Camarillo.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-servicelistboundary/



Technical Summary

LoST maps service identifiers and location information to service
contact URIs. If a LoST client wants to discover available services
for a particular location, it will perform a <listservicesbylocation>
query to the LoST server. However, the LoST server, in its response,
does not provide context information, that is, it does not provide any
additional information about the geographical region for which the
returned list of services is considered valid within. Therefore, this
document proposes a Service List Boundary that returns a local context
along with the list of services returned, in order to assist the
client to not miss a change in available services when moving.


Working Group Summary

There is consensus in the working group that this document adds useful
functionality to the LoST protocol.


Document Quality

The document has been reviewed by key participants from the ECRIT
working group and from the APP area XML-DIR. 

Personnel

Richard Barnes is the document shepherd. Robert Sparks is the responsible AD.

RFC Editor Note 
(Applies to -05)

1.      In the abstract the document starts with LoST,  Please expand to Location-to-Service Translation
2.      At the end of section 3.2 - 
         Replace the first instance of getServiceListBoundary with getServiceBoundary as follows:
         OLD:
             Note: since LoST does not define an attribute to indicate which
             location profile the clients understands in a
             <getServiceListBoundary> request, this document also does not define
            one for the <getServiceListBoundary> request.
         NEW:
             Note: since LoST does not define an attribute to indicate which
             location profile the clients understands in a
             <getServiceBoundary> request, this document also does not define
            one for the <getServiceListBoundary> request.
3.    In the second to last paragraph of section 3.2 -
        OLD:
           Therefore the 'serviceListKey' is a random token with at
           least 128 bits of entropy and can be assumed globally unique.
        NEW:
           Therefore the 'serviceListKey' is a random token with at
           least 128 bits of entropy [RFC4086] and can be assumed globally unique.
4. Add as a normative reference:

     [RFC4086]   Eastlake, D., 3rd, Schiller, J., and S. Crocker,  "Randomness Requirements for Security", BCP 106, 
     RFC 4086, June 2005.