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

Hi Shida,

to summarize my feedback, I think we need to make sure that the Phone
BCP indeed captures the aspects we have been silently assuming all the
time.

A few minor comments below:

Shida Schubert wrote:
> Hi Hannes;
>
> My comments inline..
> First of all thank you for clarifying a lot of my concerns.
>
> Hannes Tschofenig wrote:
>   
>> 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.
>>   
>>     
> I completely understand that the protocol was designed for general
> usage. But until
> now I haven't seen enough normative text anywhere for an emergency case.
> I have read
> the phone BCP last October, but I don't recall reading normative
> behaviors addressing
> my concerns.
>
>   
Then we need to push the Phone BCP authors to include something in there.

>>   
>>     
>>> 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?
>>   
>>     
> Yes I understand, as I commented before to Henning, I am all happy if I see
> my concerns addressed in Phone BCP.
>   
Good.

>>   
>>     
>>>  
>>>
>>>  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.
>>   
>>     
> Some text that would yield implementation to come up with the output above
> needs to be documented somewhere (I guess the phone BCP).
>   
>>   
>>     
>>>  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.
>>   
>>     
> Agree.
>   
>>   
>>     
>>>    
>>>    * 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?
>>   
>>     
> I just want every effort to be made for a client to succeed in making
> the emergency call.
> If there is some fundamental problem on the client side, there is really
> nothing we can 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.
>>   
>>     
> Understood. That's what I gathered. Thank you for the clarification.
>   
>>   
>>     
>>>     > 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.
>>   
>>     
> That's what I gathered. Thank you for clarifying.
>   
>>   
>>     
>>> 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
>>   
>>     
> I understand what you are saying. My comment was specifically addressed
> to an emergency case.
> BTW are you saying service-urn-05 mandates returning a parent
> service(service:sos) to be
> returned when child service(service:sos:police) is not? I read the 03
> version but I don't recall
> any such text.
>   

The Service URN draft does not mandate that a parent service has to be
returned when the child service is not available.
I also think that the Phone BCP document has to say that.

>   
>>> 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.
>>   
>>     
> Do you expect any correlation between the location profile requested and
> location profile
> expect to be seen in getServiceBoundaryResponse? If I send a query with
> profile A and B,
> would the data referenced include all the profile the server supports or
> only those that
> were asked.
>   

I would say "Yes"; there has to be a correlation.
It need to review the text to ensure that this is really the case.

>>   
>>     
>>> 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.
>>   
>>     
> I apologize I must had been dreaming... You are right I made up the text.
>
>   
>>   
>>     
>>>  
>>>
>>> 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.
>>
>>   
>>     
> Okay here is the text that made me raise the question.
>
> "<valid> element enumerates those civic address elements that have been
> recognized as
> valid by the LoST server and that have been used to determine the mapping."
>
> It's the last bit that states "that have been used to determine the
> mapping", I am assuming
> if this is true, the granularity of boundary and that of valid should be
> equal.
>
>   

There is no relationship between the <valid> elements and the <serviceBoundary>. 

>>   
>>     
>>> 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.
>>   
>>     
> Thank you. I completely agree with not using the DNS terminology.
> I don't have any preference here, I just felt odd seeing the text after
> arguing about
> caching so much over the years.
>
>   
>>   
>>     
>>> 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.
>>     
> Thanks.
>
> Regards
> Shida
>
>   
Ciao
Hannes

>> 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