Re: [Ecrit] Review of draft-ietf-ecrit-lost-03.txt

Hi Shida,

thanks for your review.

Shida Schubert wrote:
> Draft:  draft-ietf-ecrit-lost-03
> Reviewer: Shida Schubert
> Review Date: 31 Jan 07
>
> Summary:
> ----------------------------------------
>  Some clarifications are needed for it to progress further.
>  I know LoST is to be used for service other than SOS, but 
> the document leaves me with some concerns when I envision 
> its use with SOS. 
>
>   
I believe that good protocol also provides extensibility for future use.
Currently, the protocol description was written with a focus on
emergency services usage in mind but we tried to design it in such a way
that a usage in a more generic environment is possible and not prevented.

> Overall Concerns about the draft:
> ----------------------------------------
>
>  1. Which document do I expect to see normative texts on client and server behavior?
>    > Some normative behavior exists in the draft but some I believe 
>      is important is lacking.
>
>    > For example, what is client to do if it receives any of the 
>      errors in section 12.1? If we don't provide some sort of 
>      recommendation, things are likely to get messy and simply not work.

My opinion is that the Phone BCP has to provide these guidelines.

Ideally, there shouldn't be an error. However, it is easy to envision
that errors might happen. For the emergency services use case the LoST
server should try to return an answer even in the worst case.

There are, however, a really really bad error cases where the LoST cases
isn't able todo anything useful. For example, what do you do if a client
sends a totally garbled request?

>  
>
>  2. Errors shouldn't be sent on its own.
>    > I strongly believe that for some of the errors either it 
>      should be recommended to attach a default URI for the service 
>      requested(notFound,loop) or send the error with the 
>      potential redirect targets(serviceNotImplemented,
>      locationProfileUnrecognized,internalError,loop,notFound).
>
>   
For some of the error I believe that's what we do. Consider, for
example, the following error response:

<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/">
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="lost:authoritative.example"
sourceId="fb8ed888433343b7b27865aeb38f3a99" version="1" >
<displayName xml:lang="en">
New York City Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior>
<p2:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos>
<p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing>
</p2:exterior>
</p2:Polygon>
</serviceBoundary>
<uri>sip:nypd@example.com</uri>
</mapping>
<warnings source="lost:authoritative.example">
<serviceSubstitution
message="Unable to determine proper location, using default PSAP"
xml:lang="en"/>
</warnings>
<path>
<via source="lost:authoritative.example"/>
<via source="lost:resolver.example"/>
</path>
</findServiceResponse>

Here location did not lead to a PSAP and a default PSAP was returned.
Still, there is a response that can be used for emergency service purposes.

>  3. Do we really want to send an error at all? 
>    > I vaguely remember the talk about sending a default PSAP URIs 
>      rather than sending an error and stalling an emergency call.
>   
That's always an option for some error situation.
The Phone BCP document should probably give some more information about
the cases when this would be appropriate.
For some extreme error cases this is just not possible.

>    
>    * 2 and 3 may not be a problem if the client(UA) is not trying 
>      to contact the LoST server directly. In which case resolver is 
>      likely to have some useful cache. I am worried about a case where 
>      UA boots up and has no cache, sends a query to LoST server and 
>      fails. Where does it go then?
>
>
>   
The LoST server discovery procedures allow multiple LoST servers to be
returned. Hence, the client could ask some of the alternative servers.
If none of the available LoST servers works then there is indeed nothing
you could do. Maybe the network interface card of the laptop / mobile
phone is broken. What should you do?

> Clarifications needed:
> ----------------------------------------
> 1. Relationship of sourceId/version is ambiguous.
>     > If user A and B queries for "sos"/"regionA" would 
>       they get the same mapping data with same sourceId/version?
>   
Yes. They would receive they same mapping if it did not change in
between the two requests if their location falls within the same region.
>     > If above are the same when does sourceId/version ever change?
>   
If the mapping Location+Service -> PSAP (+service boundary+location
profile) association changes.

>     > Assuming server that caches the data can't change sourceId/version, 
>       they need to be the same for both A and B? 
>     > I think the text needs to be elaborated to clarify what 
>       I have raised as a question.
>
>   
I will look at it in order to determine what has to be done.

> 2. <lastUpdated>
>     > Again, the relationship between the client/mapping should be 
>       clarified. Is it the time when the mapping response was sent?
>       Or is it really the time when boundary/service relationship has 
>       changed. From the in the later section I am assuming it's the 
>       latter.
>   

Currently, there only two fields that carry date information: expires
and lastUpdated

They do not indicate when the response message was sent.

> 3. <serviceNotImplemented> makes me uncomfortable. 
>    > Considering for an emergency case, if this is returned without any 
>      alternative services related to the requested service or 
>      redirection targets and my resolver(my UA) happened to know only one 
>      LoST server(one that returned this response)... 
>      How would I make a successful emergency call? 
>    > Suggestions should be made to either return a default URI for the 
>      service requested or send redirection response.
>      *Currently the server can either chooses to return an alternative 
>       service or simply send "serviceNotImplemented". 
>   

For the emergency call you would send the services defined in
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-05.txt
document and for an emergency services deployment you would provide
mappings for these services.

If a client asks for a service foobar and foobar just does not exist
then there needs to be an error back that the service is not implemented.
You cannot return a "default" service for every
> 4. <serviceBoundaryReference>
>    > Now the text currently states that the identifier MUST be changed
>      when the boundary changes. I don't know if it happens often but 
>      assuming there may be multiple geodetic profiles supported by 
>      the server, would the identifier need to be changed when  
>      datum in one of the profile changes? (Say profile A contains 
>      NumFloors and because a new high rise was introduced value of 
>      NumFloors changed from 6 to 12.) 
>      * It's probably nothing to worry about as the boundary doesn't 
>        seem to change often.
>
>   

The mapping would most likely not change too often.

In your example, if the service boundary changes then the mapping would
change. Whether the change affects multiple location profiles is hard to
say and depends on the specific location profile.

> 5. <uri> element.
>    > Requirement Ma7 talks about returning multiple PSAP URIs that may 
>      cover different regions. I am assuming the serviceBoundary doesn't 
>      allow LoST server to express correlation between serviceBoundary 
>      and URI provided. For example assuming sip:psap1 covers region1
>      and tel:psap2 covers region2, which URI would be expressed by the 
>      serviceBoundary? Do we need to worry about this? Does this happen? 
>      I am assuming it may happen. Some of the more major protocol 
>      are likely to be supported by most PSAPs, but for example real time 
>      text for hearing impaired may only be supported by major PSAP that 
>      may have larger boundary than others.
>   
Requirement Ma7 says:

"
Multiple PSAP URIs: The mapping protocol MUST support a method to return
multiple PSAP URIs which cover the same geographic area.
"

The <uri> element may indeed appear multiple times in the response.

>  
>
> 6. Section 7.2.1/7.2.2 a sentence before the answer example
>    "This instructs the client that if its location changes beyond the
>    give service boundary or the expiration time has been reached, it
>    would need to requery for this information." 
>     I don't think the statement here is wrong but I feel uncomfortable 
>    with this. strict Resolver like the one that may sit in VSP may 
>    be a client in some sense but unless it goes through a scheduled 
>    reboot, it does not meet any of the criteria mentioned in section 3 
>    for triggering the mapping. Now if we consider these resolvers that cache 
>    values and considering the long expiration time for the mapping, 
>    seeker may be pointed to inappropriate PSAP more than we want to see.
>
>   
I would not have a problem deleting the sentence.

> 7. <locationValidation>
>   > The text seems to imply that there is a coherency in granularity 
>     expressed in <valid> and that of <serviceBoundary>. 
>     If the boundary is cut at state level, the location validation is 
>     done to the state level only is what I gather from the text. 
>     If that's the case the example contains a false, it seems to 
>     validate down to <A6 /> when the boundary is cut at <A3 />
>
>   

The content of the <valid> and the <serviceBoundary> element have a
totally different semantic.

The content of <valid> says that the listed tokens are checked and
considered valid (in the sense of the definition in the requirements
document).

For the service boundary the situation is a bit more difficult and more
text is needed.

> 8. <ListServicesByLocationResponse> 
>   > From the example and the description of the element I gather that 
>     the response does not contain which server may provide the services 
>     listed in <serviceList>. This is problematic if the seeker is looking 
>     for a service that the target LoST server doesn't support and recursive
>     is not declared(default="false") or set to "false".
>
>   
I agree. That's missing.

> 9. Section 5.3, last sentence: 
>    I am assuming resolver is the entity that actually queries the LoST 
>    server, in which case the following sentence:
>    "Resolvers SHOULD re-attempt the query each time a seeker 
>    requests a mapping." seems to invalidate the whole concept of caching. 
>    In DNS term, I am assuming that the LoST server likely to be deployed 
>    at VSP is analogous to 'strict' Resolver which may not want to query 
>    each time a seeker requests a mapping. Some clarification at terminology 
>    may be necessary..
>   

As mentioned by Patrik we should avoid the DNS terminology. We should
only talk about client and server.

I don't have a strong opinion about the strategy of fetching
information. You can either say that the default is to fetch information
from the authority server whenever possible (and fall back to the cache
when you have connectivity problems) or to be more lazy by exploiting
the caching functionality.

> 10. Clarifying caching
>    > Based on what information would the entity cache or delete cache? 
>     > When location validation is requested, I believe it makes it 
>       a unique request even when there is a cache available for the 
>       region asked( cache for region civic:Munich is available, 
>       the query is for civic:Munich,x,y + location validation = "true").
>     > Criteria on when caching is to be done should be clarified.
>
>   
We should probably provide more text.

Ciao
Hannes

> Editorial Fixes:
> ----------------------------------------
>
> 1. Term server/resolver/seeker/client are used, I am assuming there are 
>    some overlaps and trying to minimize the varieties on term used would 
>    be good.
>
>
> 2. Section 6. 2nd paragraph:
>     "If a query is answered iteratively, the querier includes all servers
>     that it has already contacted."
>    
>     Is it recursively and not iteratively?
>
> 2. Section 7.2.1/7.2.2: 1st sentence
>    "The following is an example of mapping a service to a location using
>    geodetic coordinates, for the service associated with the police
>    (urn:service:sos.police)."
>
>   Isn't it an example of mapping query/request not mapping.
>
>
>  I hope it helps.
>
>  Regards
>   Shida 
>
>
>
>
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit
>   

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit