[Ecrit] comments on LoST

[Jonathan Rosenberg <[e-mail]>]

Here are my comments on the latest version of LoST from SVN 
(http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-lost-04.txt).


I have several high level comments.

Firstly, the specification is somewhat confused about whether it is 
specifying a data object (like a presence document), in which case the 
semantics of the fields are critical, or whether it is specifying a 
protocol, in which case state machines, transactions, timers, failures, 
element behaviors, and so on, are relevant. I believe LoST is the latter 
not the former, yet the spec is mostly written as if it was the former 
and not the latter.

Secondly, I think the binding to http and https is not well specified, 
and many important details (minimum baseline mandatory requirements, 
timer considerations, usage of security techniques, pipelining, etc.) 
are not discussed at all.

Thirdly, I have some concerns over the requirement for servers to 
support both geodesic-2d and civic for all queries. IN particular, I 
fear that it will be common for boundary objects to exist in only one 
form or the other, and I don't see how conversion can easily be done 
between the two.

More specific comments below:



> This document describes an XML-based protocol for mapping service
>    identifiers and geodetic or civic location information to service
>    contact URIs.  In particular, it can be used to determine the
>    location-appropriate PSAP for emergency services.

expand PSAP acronym

> This document describes a protocol for mapping a service identifier
>    [10] and location information compatible with PIDF-LO [7], namely
>    revised civic location information [11] and GML [13]) 

missing open paren


> While the initial focus is on providing mapping
>    functions for emergency services, it is likely that the protocol is
>    applicable to any service URN. 

the first sentence mentions service identifiers but doesn't actually say 
service URN. Suggest that you add in the first sentence:

"..for mapping a service identifier (in the form of a service URN [10]).."

> Example service URL schemes include sip [14], xmpp
>    [15], and tel [16]. 

I'm gonna be a nit-picker and point out that these are actually URI and 
not URL. That error occurs in many places in the document.

>  For example, in the United States,
>    the "2-1-1" and "3-1-1" service numbers follow a similar location-to-
>    service behavior as emergency services.

might be good to mention what these are


> This document names this protocol "LoST", for Location-to-Service
>    Translation.  LoST Satisfies the requirements [18] for mapping

satisfies

THe last paragraph in the introduction repeats most of which is said 
already above. I'll note it does so more clearly than the rest of the 
intro. I suggest moving it up towards the front of the introduction.

Also, the introduction is missing an important point that is obvious for 
us in this field but probably non-obvious for newbies. I'd suggesting 
adding the following text in the intro:

"Numerous techniques have been specified for the discovery of servers 
for a particular service, including NAPTR records, SVRLOC and similar 
protocols. However, there are an important class of services where the 
specific service instance that is to be connected to depends on the 
identity of the service and the location of the entity that needs to 
reach it. An example of this is emergency telecommunications services, 
where the service instance is a Public Safety Answering Point (PSAP) 
that has jurisdiction over the location of the user making the call. 
Here, the desired PSAP isn't necessarily the one that is topologically 
or even line-of-sight closest to the caller; rather, it is the one that 
serves the callers location based on geopolitical boundaries. For this 
reason, the selected service instance is a function of location and the 
desired service."



Section 3 isn't really an overview of operation at all. It mainly 
addresses the question of WHEN a user invokes LoST. I was expecting 
first an architecture picture that shows a client, a server, and some 
backend stuff (other servers). LosT is show as between client and 
server. The section would talk about clients issuing requests and 
servers answering them. It would mention HTTP and indicate what is 
contained in a request, whats in an answer. Mention caching and the use 
of regions as a technique to avoid repeated queries on the server. It 
would mention the primary primitives provided by lost.

> 4.  LoST servers and Their Resolution

LoST Servers and their Resolution


I wonder if there should be a separate port number for LoST. See RFC 3205.

> A receiver can replace a mapping with another one having
>    the same 'source' and 'sourceId' and a higher version number.

You have not used the term receiver before. Client you mean?

>  The 'version' attribute is a positive integer that is incremented for
>    each change in the mapping.  The XML data type does not specify an
>    upper bound for this attribute and thus, the value MUST NOT wrap
>    around.  Thus, a higher version number refers to a more recent
>    mapping.  A mapping maintains its sourceId value as long as it
>    remains logically the same, e.g., represents the same service
>    boundary or replaces an earlier service boundary.

Do these have to increase by 1 for each update, or just increase? SHould 
be clear.

> The contents of this attribute is a
>    timezoned XML type dateTime, in canonical representation.  See

contents are

>  The 'expires' attribute is REQUIRED to be included in the <mapping>
>    element.

Is there a way to use LoST without caching? To specify that this result 
is valid only for the purposes of satisfying this one query? Or to say 
that the results never expire?

> On occasion, a server may be forced to return an expired mapping if
>    it cannot reach the authoritative server or the server fails to
>    return a usable answer.  Clients and servers MAY cache the mapping so
>    that they have at least some information available.  Caching servers
>    that have such stale information SHOULD re-attempt the query each
>    time a client requests a mapping.

A meta-issue here, is whether the LoST protocol is meant to just be a 
client-server protocol, or whether we are specifying rules for the 
entire system. This SHOULD here is a rule for a server to follow when 
contacting other servers and thus would not be present in a 
client-server protocol spec.

As another issue, this section (section 5) is a mix of behaviors that 
define rules around construction of objects and for behaviors of 
servers. WHich is it?

>  Zero or more <displayName> elements describe the service with a
>    string that is suitable for display to human users, each annotated
>    with the 'xml:lang' attribute that contains a language tag to aid in
>    the rendering of text.

Presumably the presence of more than one is to allow responses to convey 
multiple languages. Might want to state that.

> The <service> element is optional but may also be required if the
>    mapping is to be digitally signed.

seems like a normative statement is needed here - The <service> element 
MUST be present if the mapping is to be digitally signed.

>  A response MAY indicate the region for which the service URL returned
>    would be the same as in the actual query, the so-called _service
>    region_. 

I don't understand this definition. I thought it would be something 
like: The service region is a set of locations, such that if a client 
generates a new query with the same service URN and a location within 
the set, the server would return the same service URI in its response.

> The service region is described by value
>    in one or more <serviceBoundary> elements, each formatted according
>    to a different location profile, identified by the 'profile' atribute
>    (see Section 11).

and:

>  A response MAY contain more than one <serviceBoundary> element with
>    profile 'civic'.

appear to contradict each other. Which is it?

> The identifier is a random token with at least 128 bits of entropy
>    and can be assumed to be globally unique.  It uniquely references a
>    particular boundary.  If the boundary changes, a new identifier MUST
>    be chosen.  Because of these properties, a client receiving a mapping
>    response can simply check if it already has a copy of the boundary
>    with that identifier.  If so, it can skip checking with the server
>    whether the boundary has been updated.  Since service boundaries are
>    likely to remain unchanged for extended periods of time, possibly
>    exceeding the normal lifetime of the service URL, this approach
>    avoids unnecessarily refreshing the boundary information just because
>    the the remainder of the mapping has become invalid.

Any guidelines about when a server is supposed to send a service 
boundary reference as opposed to the actual service boundary in a response?

> The Service Number Element
> 
>    The service number is returned in the optional <serviceNumber>
>    element.  It contains a string of digits, * and # that a user on a
>    device with a 12-key dial pad could use to reach that particular
> 
> 
> 
> Hardie, et al.           Expires August 13, 2007               [Page 11]
> 
> Internet-Draft                    LoST                     February 2007
> 
> 
>    service.

This is not true.

So if I'm in an enterprise which requires '9' for an outside line, 
wouldn't I have to dial 9 first before this sequence? I think these 
service numbers represent numbers that are part of the local *numbering 
plan*, and are accessed based on the *dial plan* configured into the device.

> 7.3.3.  Recursion
> 
>    LoST <findService> and <listServicesByLocation> queries can be
>    recursive, as indicated by the 'recursive' attribute.  A value of

You haven't mentioned the listServicesByLocation query yet.

> The example in Figure 6 demonstrates address
>    validation, omitting the standard response elements.

but figure 6 is a request, not a response. So how can it omit response 
elements? Maybe you mean figure 7?

> true.  Each element contains a list of tokens separated by white
>    space, enumerating the civic location lables used in child elements

labels

>  Note that the same address can yield different responses if parts of
>    the civic address contradict each other.  For example, if the postal
>    code does not match the city, local server policy determines whether
>    the postal code or the city is considered valid.  The mapping
>    naturally corresponds to the valid elements.

I think you need a bit more guidance on how to construct the validation 
responses. In particular, I think that you would want to indicate that 
the most specific address component that is in conflict is the one 
listed as in error. For example, if a street address is 65 Main St. and 
there is no number 65 on Main St., you would indicate that "65" is in 
error, not Main St.

>  <?xml version="1.0" encoding="UTF-8"?>
>    <listServices
>      xmlns="urn:ietf:params:xml:ns:lost1">
>      <service>urn:service:sos</service>
>    </listServices>
> 
>                 Figure 12: Example of <ListServices> query

The text in section 9 doesnt mention that the query can contain a 
service. Presumably this is a request for the server to indicate which 
services it supports beneath this root? And that, if absent, its a 
request for all services?

There is an assumption that the server knows all of the services it 
supports. What about a LoST server that front ends a large number of 
back-end servers, forwarding requests to a particular back-end server 
based on location? THis front end server doesn't really know what 
services it supports.

>  define the manner in which location information is transmitted.  It
>    possible to standardize other profiles in the future.  The two
>    baseline profiles are:

It is

>  4.  The declaration of whether geodetic-2d or civic is to be used as
>        the baseline profile.  It is necessary to explicitly declare the
>        baseline profile as future profiles may be combinations of
>        geodetic and civic location information.

This doesn't make sense to me; I thought this spec defined both 
geodetic-2d and civic as baseline mandatory-to-implement.

> Requests and responses containing <location> or <serviceBoundary>
>    elements MUST contain location information in exactly one of the two
>    baseline profiles, in addition to zero or more additional profiles.
>    The ordering of location information indicates a preference on the
>    part of the sender.

THis seems odd. Why can't you include location in both of the location 
profiles if you have it? It might allow the server to figure out which 
is more accurate and use that one.

>  1.  A client MUST be capable of understanding the response for the
>        baseline profiles it used in the request.

The word 'profiles' (plural) makes me think you can in fact have 
multiple baseline profiles in the request, though the words above forbid it.

>   4.  Servers MUST implement the geodetic-2d and civic profiles.

What does this mean? Does it mean that it must be able to process 
requests with <location> objects in either format? Does it mean it needs 
to be able to represent a boundary in either of the two formats? Thats 
actually a tall order; I would tend to think that boundaries in 
particular would typically exist in only one format and that conversion 
is not going to be easy or possible in many cases.

>  6.  If a server receives a request that only contains location
>        information using profiles it does not understand, the server
>        responds with a <locationProfileError> (Section 12.1).

based on your rules this should never happen.

>  7.  The <serviceBoundary> element MUST use the same location profile
>        that was used to retrieve the answer and indicates which profile
>        has been used with the 'profile' attribute.

'used to retrieve the answer' - what does that mean? What if the server 
converts the input format internally prior to looking up the answer in a 
backend store?

Also these rules do not place any requirements on clients. Do they need 
to support both geodesic-2d and civic? Should be clear either way.

>  These rules enable the use of location profiles not yet specified,
>    while ensuring baseline interoperability.  Take, for example, this
>    scenario.  Client X has had its firmware upgraded to support the
>    uber-complex-3D location profile.  Client X sends location

You are talking about figures 16 and 17 though you don't reference them.

>  Servers use this profile by placing a GML [13] <Polygon> element
>    within the <serviceBoundary> element.  This is defined by the
>    'polygon' pattern in the LoST schema (see Section 14).

Well, servers 'use this profile' by processing <location> requests and 
constructing serviceBoundary objects in responses. I think you mean to 
say that <location> objects are constructed using <position> and 
serviceBoundary elemenets by <Polygon> elements.

Same comment on 11.3.

> A LoST server can respond indicating that the querier should redirect
>    the query to another server, using the <redirect> element.  The
>    element includes a 'target' attribute indicating the LoST application
>    unique string (see Section 4) that the client SHOULD be contacting
>    next, as well as the 'source' attribute indicating the server that
>    generated the redirect response and a 'message' attribute explaining
>    the reason for the redirect response. 

Is there support for multiple languages at once here, as is the case 
with warnings and errors?

> 13.  LoST Transport

You might want to include some discussion on timers. LoST layers a 
transaction protocol ontop of HTTP. How long should a client wait for a 
response?

Do LoST servers need to support pipelining? Do they have to provide both 
http and https support? Do clients need to support both?

What about authentication? Can digest be used? What about mutual TLS?

I think this section is a bit underspecified.


> 16.5.  LoST Location Profile Registry
> 
>    This document seeks to create a registry of location profile names
>    for the LoST protocol.  Profile names are XML tokens.  This registry
>    will operate in accordance with RFC 2434 [2], Standards Action.

I'd suggest you actually include the table that IANA is supposed to 
create. I think you want it to look like this:


LoST Location Profiles

Profile Name             Specification
--------------------------------------
geodetic-2d              RFCXXXX
civic                    RFCXXXX


> Generally, authentication and authorization is not required for
>    mapping queries.  If it is, authentication mechanism of the
>    underlying transport mechanism, such as HTTP basic and digest
>    authentication, MAY be used.  (Basic authentication SHOULD only be
>    used in combination with TLS.)

I this this last SHOULD has to be a MUST.

> 17.  Security Considerations

Text in the body of the specification discusses body signatures, but 
there is no treatment on how this is done.

> In protocols that support
>    content type indication, LoST uses the media type application/
>    lost+xml.

What does this mean? That when used with HTTP, LoST objects use this 
content-type?



Thanks,
JOnathan R.




-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[e-mail]                              FAX:   [phone]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com

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