Location-to-Service Translation (LoST) Protocol Extensions
draft-forte-lost-extensions-08

[Ballot comment]
#1) Section 8: Isn't the framework in 5222 not 5582? 5582 is "Location-to-URL Mapping Architecture and Framework" and 5222 is the actual LoST protocol/architecture.

#2) Section 8: It's probably worth adding to the end of the 1st paragraph that these exchanges all normally happen over TLS (i.e., here's how it works and here's how it's protected).

#3) As noted in the secdir review, it might be worth nothing somewhere that though out-of-scope the information is likely more volatile in a commercial context since the issues probably does not arise (at least as frequently) in the RFC 5222 context.

#4) Also noted in the secdir review, it might be worth adding that a server can adjust a request in order to provide service would be helpful.  Does there need to be some means for the server to indicate to the client that there may be some additional related responses that can't be retrieved using the provided request?  If not, it seems like there may be some blind spots for some queries.

[Ballot comment]
Strictly editorial: Section 5 is generally too verbose with unnecessary verbiage and unnecessary examples. This is a protocol specification, not an academic paper. It should be shortened.

I was back and forth on DISCUSS for the following, but I trust you will take the following into account and adjust as is reasonable.

5.4 - "Limit" is the wrong semantic for this element. "Limit" implies only a limited number, but this has the secondary meaning of an *order* of returned elements (that is, by distance), something not required by LoST. But I could see extensions having a different ordering (by travel time; by current wait time at the location; by price of product; etc.) where you would still want a limit, but not want the order returned to be by distance. I can also see a use for ordering by distance, but not having a limited number. I suggest introducing a different element for ordering of results independent of limiting the number.

5.5 says:

  We introduce a new element, namely .  The
    element contains the location of a point of service
  and SHOULD be used for all non-emergency services.
 
I don't understand the SHOULD there. I can see emergency cases (hospitals) where location is a good thing; I can see plenty of non-emergency cases (delivery services) where location is uninteresting. I see nothing harmed in interoperability by not providing location. There doesn't need to be a 2119 directive here.

6 - I don't understand why the extension SHOULD NOT be used for emergency services. Does RFC 5222 allow a LoST server to fail in the face of extensions it does not know?!? If so, I would agree with the SHOULD NOT here, but would think an update to 5222 is required /tout de suite/!

[Ballot comment]
Here are suggestions regarding a few small points you might want to clarify or correct.

1. You might want to change "walk or drive" to "travel" (thus including bicycles, boats, horses, jetpacks, etc.).

2. You might want to note that neither "urn:service:food.pizza" nor "urn:service:local.pizza" has been registered with the IANA. (Also, is there a difference between those two services?)

3. Given that you are re-using the "xsd:boolean" datatype for the  element, you might want to add an implementation note about the fact that W3C XML Schema has two different lexical representations for boolean: "1" or "true" vs. "0" or "false".

[formerly a discuss topic, and I discussed it with the responsible AD...]

4. In Section 6, you might consider adding a few words to the effect that finding localized emergency services for purposes other than routing emergency sessions (e.g., fire station "safe sites") would need to use newly-defined service types other than "sos".

[Ballot comment]
Just an observation - I found the example in section 5.2 a little
confusing, because it appears to conflate "user location" with "within
distance" in Figure 3.  I would have thought the user location would
be just the "O" under "User" and the circular shape ("*" border) to
represent the "within distance" shape.  If the user location really is
represented by the circular shape because of uncertainty, wouldn't the
"within distance" shape then be a larger circular shape?

Later on, I see that the "within distance" is represented by setting
the uncertainty in the user's location.  Seems like an odd overloading
but it's workable now that I understand it.

[Ballot comment]
Here are suggestions regarding a few small points you might want to clarify or correct.

1. You might want to change "walk or drive" to "travel" (thus including bicycles, boats, horses, jetpacks, etc.).

2. You might want to note that neither "urn:service:food.pizza" nor "urn:service:local.pizza" has been registered with the IANA. (Also, is there a difference between those two services?)

3. Given that you are re-using the "xsd:boolean" datatype for the  element, you might want to add an implementation note about the fact that W3C XML Schema has two different lexical representations for boolean: "1" or "true" vs. "0" or "false".

[Ballot discuss]
Overall this is a fine document. There's one topic I'd like to chat about. Section 6 states:

  The LoST extensions defined in this document SHOULD NOT be used when
  routing emergency sessions as there may be LoST servers that do not
  support these extensions.

That's true, but it strikes me that a person might want to find localized emergency services for purposes other than routing emergency sessions (for example, in much of the USA fire department stations are used as "safe place sites" for children and young adults). Would that require definition of a new service type (e.g., "help.safesite"), or would it be appropriate to use the existing "sos.fire" service?

[Ballot comment]
I have no objection to the publication of this document, but I am surprised that there is no concept of reachability included in this work. Think bridges over rivers, borders without holding a passport, long and winding roads.

IANA understands that, upon approval of this document, there are two
IANA Actions which must be completed.

First, in the XML Schema registry located at:

http://www.iana.org/assignments/xml-registry/schema.html

a new schema is to be registered as follows:

ID: lost-ext
URI: urn:ietf:params:xml:schema:lost-ext
Filename: lost-ext
Reference: [ RFC-to-be ]

the contents of the filename will be provided in Section 6 of the
approved document.

Second, in the XML Namespaces registry located at:

http://www.iana.org/assignments/xml-registry/ns.html

a new namespace is to be registered as follows:

ID: lost-ext
URI: urn:ietf:params:xml:ns:lost-ext
Registration template: lost-ext (with the content in Section 9.2 of the
approved document)
Reference: [ RFC-to-be ]

IANA understands that these two actions are the only ones required upon
approval of the document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Location-to-Service Translation (LoST) Protocol Extensions) to Experimental RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Location-to-Service Translation (LoST) Protocol Extensions'
  as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-07-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  An important class of location-based services answer the question
  "What instances of this service are closest to me?"  Examples include
  finding restaurants, gas stations, stores, automated teller machines,
  wireless access points (hot spots) or parking spaces.  Currently, the
  Location-to-Service Translation (LoST) protocol only supports mapping
  locations to a single service based on service regions.  This
  document describes an extension that allows queries of the type "N
  nearest", "within distance X" and "served by".




The file can be obtained via
http://datatracker.ietf.org/doc/draft-forte-lost-extensions/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-forte-lost-extensions/


No IPR declarations have been submitted directly on this I-D.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the document
and, in particular, does he or she believe this version is ready
for forwarding to the IESG for publication?

The Document Shepherd is Richard Barnes. I have personally reviewed this version of the document and believe it is ready for publication.


(1.b) Has the document had adequate review both from key members of
the interested community and others? Does the Document Shepherd
have any concerns about the depth or breadth of the reviews that
have been performed?

The document has been reviewed by key members of the ECRIT group, including a detailed discussion of the possible impact of this service on a LoST service provided to support emergency services. I do not have any concern about the level of review.


(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective, e.g.,
security, operational complexity, someone familiar with AAA,
internationalization or XML?

The document makes extensive use of XML, but I believe that the level of review it has received is sufficient.


(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or
she is uncomfortable with certain parts of the document, or has
concerns whether there really is a need for it. In any event, if
the interested community has discussed those issues and has
indicated that it still wishes to advance the document, detail
those concerns here.

The major concern with regard to this document is its interaction with "traditional LoST", which supports emergency services. In particular, if queries from devices using this service overwhelm a LoST server, then the server will be unable to respond to emergency queries. There was consensus that this concern was a special case of the general denial-of-service risk for LoST servers, so LoST servers need to be appropriately scaled in any case.


(1.e) How solid is the consensus of the interested community behind
this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the interested
community as a whole understand and agree with it?

There is a small community of interested people. There was consensus in the broader ECRIT group to allow this document to proceed as an AD-sponsored document.


(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

I am not aware of any such conflict.


(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
enough; this check needs to be thorough. Has the document met all
formal review criteria it needs to, such as the MIB Doctor, media
type and URI type reviews?

The document's references are not divided into Normative and Informative references. However, I believe that all references are Normative, so a simple change of the section header should suffice.


(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that are
not ready for advancement or are otherwise in an unclear state?
If such normative references exist, what is the strategy for their
completion? Are there normative references that are downward
references, as described in [RFC3967]? If so, list these downward
references to support the Area Director in the Last Call procedure
for them [RFC3967].

See (1.g) above. There are no normative downward references.


(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of
the document? If the document specifies protocol extensions, are
reservations requested in appropriate IANA registries? Are the
IANA registries clearly identified? If the document creates a new
registry, does it define the proposed initial contents of the
registry and an allocation procedure for future registrations?
Does it suggested a reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If the document
describes an Expert Review process has Shepherd conferred with the
Responsible Area Director so that the IESG can appoint the needed
Expert during the IESG Evaluation?

The IANA Considerations sections registers an XML namespace and schema, consistent with the document's overall goal of defining the LoST XML syntax.


(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML code,
BNF rules, MIB definitions, etc., validate correctly in an
automated checker?

I have checked that all XML examples in the document are well-formed, using the W3C markup validation service:

One example had a tag missing a closing angle bracket; the authors have been notified.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

An important class of location-based services answer the question "What instances of this service are closest to me?" Examples include finding restaurants, gas stations, stores, automated teller machines, wireless access points (hot spots) or parking spaces. Currently, the Location-to-Service Translation (LoST) protocol only supports mapping locations to a single service based on service regions. This document describes an extension that allows queries of the type "N nearest", "within distance X" and "served by".


Working Group Summary

This document was considered by the ECRIT working group, which declined to work on this document in order to maintain a focus on emergency services (rather than other uses of the LoST protocol). The main discussion among those interested focused on the interaction with the emergency case, which was ultimately judged to be manageable (see the Security Considerations).


Document Quality

The document has received reviews from several active members of the ECRIT community. A review by Shida Schubert of an earlier version noted several potential issues (mainly related to interoperability with RFC 5222), which have been addressed in this version.