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

From: Shida Schubert <[email-masked]>
Date: Thu, 01 Feb 2007 02:25:52 -0800

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. 

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. 

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

 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.
   
   * 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?

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?
    > If above are the same when does sourceId/version ever change?
    > 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.

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.

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

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.

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.

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.

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

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

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

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.

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 1 Feb 2007 06:21:37 -0500

Shida,

thanks for your comments; please see some initial responses and  
questions inline. I'll skip items that I'll try to integrate directly.

>      recommendation, things are likely to get messy and simply not  

I don't know what one can say in this case. In some cases, the client  
has to fix the address submitted, possibly with human input. In other  
cases, such as a system failures, a client will either have to retry  
later or use stale cached data. It seems fairly obvious in most cases  
what behavior is appropriate; we have been rightly admonished that  
the spec is somewhat wordy as is, so I'm reluctant to belabor the  
obvious. Can you identify places where an implementor would be in  
doubt what to do?

>      locationProfileUnrecognized,internalError,loop,notFound).

I don't understand what you're suggesting here. Unless you posit a  
general worldwide emergency call service, where you can send calls if  
all else fails, I don't see how this can work. If a LoST system  
doesn't understand an address at all, for example, it has no clue  
whether you are in England or Estonia. I think provider-specific fall- 
back call center information should probably be conveyed outside of  
LoST, as it is SIP-level configuration.

>      rather than sending an error and stalling an emergency call.

See above. I think the phone BCP should specify what happens if a  
device has no usable mapping at the time of an emergency call. As  
noted above, I think that will mean falling back to a VSP-provided  
call center URL.

>      fails. Where does it go then?

Again, see above.

To be continued.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 1 Feb 2007 06:22:24 -0500

Shida,

Again, see above.

To be continued.

Henning

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 1 Feb 2007 07:00:13 -0500

We could cover some normative behavior for emergency calls in -phonebcp

Brian

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Thursday, February 01, 2007 6:22 AM
> To: [email-masked]
> Cc: ECRIT
> Subject: Re: [Ecrit] Review of draft-ietf-ecrit-lost-03.txt - part 1
> 
> Shida,
>

---

From: Shida Schubert <[email-masked]>
Date: Thu, 01 Feb 2007 11:43:50 -0800

Hi Henning;

My comments inline..

Henning Schulzrinne wrote:
> what behavior is appropriate; we have been rightly admonished that the
> spec is somewhat wordy as is, so I'm reluctant to belabor the obvious.
> Can you identify places where an implementor would be in doubt what to
> do?
Probably for most cases, I am likely to come up with a conclusion analogous
to yours and implementors are likely to be smarter than I, so may be I am
simply over concerned here.

Anyhow, I don't think it's a bad practice to lay out some
recommendations to
ensure every effort is made for emergency call to succeed. After all
people can
get quite creative with their way of thinking/interpreting the so called
obvious.
> whether you are in England or Estonia. I think provider-specific
> fall-back call center information should probably be conveyed outside
> of LoST, as it is SIP-level configuration.

I will try to paraphrase the problem that I see with few examples.

- "serverError"
If serverError is returned to a client as a result of a recursive query for
service:sos:police and LoST server happens to know of a URI that can map
service:sos(but not service:sos:police thus the recursion)/location, URI
representing service:sos, I believe should be returned.

Rather than just returning an error=serverError(Which I believe is useless
without any details of error..).

- "loop"
I am not sure what client is supposed to get out of this? If it looped once
will it loop again for the same request? Is this a dead end? This error
I believe
is useful for debugging purposes but means nothing to a client(UA).

- "serviceNotImplemented"
According to the text in the draft, server may return these errors even
when there is an alternative. It may return these errors even if the server
is aware of a server that can serve the request righteously.

Rather than returning this error, it may be better to respond with a
redirect
with URI of LoST servers that can serve the request or ensure
alternative is
sent back.

> noted above, I think that will mean falling back to a VSP-provided
Do you envision this VSP-provided call center URL provided through means
such as
DHCP/Sip configuration framework?

As I noted in my comments below, I think the problem that's giving me
the stomach
pain will be nonexistent if client(UA) is not acting as a resolver itself.

I guess if above URL that you mentioned is not provided through means
such as DHCP/
Sip configuration, some text needs to recommend the UA to try sending
out an INVITE
with service URN despite its own attempt to resolve fails(And hope that
some
entity on the signaling path will be able to do the resolution on UA's
behalf).

Also I agree that phone BCP is probably a good place to include the
normative behavior.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 01 Feb 2007 22:15:45 -0500

Hi Shida,

thanks for your review.

> Draft:  draft-ietf-ecrit-lost-03
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:

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?

>      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:[email-masked]</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.

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

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

>       I have raised as a question.
I will look at it in order to determine what has to be done.

>       changed. From the in the later section I am assuming it's the 

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

They do not indicate when the response message was sent.

>       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
>      * It's probably nothing to worry about as the boundary doesn't 

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.

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

>    seeker may be pointed to inappropriate PSAP more than we want to see.
I would not have a problem deleting the sentence.

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

>     is not declared(default="false") or set to "false".
I agree. That's missing.

>    each time a seeker requests a mapping. Some clarification at terminology 

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.

>     > Criteria on when caching is to be done should be clarified.
We should probably provide more text.

Ciao
Hannes

---

From: Shida Schubert <[email-masked]>
Date: Thu, 01 Feb 2007 22:05:21 -0800

Hi Hannes;

My comments inline..
First of all thank you for clarifying a lot of my concerns.

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

> 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.
> 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).
> For some extreme error cases this is just not possible.
Agree.
> 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.
> profile) association changes.
Understood. That's what I gathered. Thank you for the clarification.
> They do not indicate when the response message was sent.
That's what I gathered. Thank you for clarifying.
> 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.

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

> For the service boundary the situation is a bit more difficult and more
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.

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

> We should probably provide more text.
Thanks.

Regards
Shida

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 2 Feb 2007 05:22:15 -0500

> get quite creative with their way of thinking/interpreting the so  

Concrete suggestions are most appreciated, keeping in mind that we  
want to avoid writing a 150-page document.

> without any details of error..).

The server should do service substitution in that case, as discussed  
in the document.

> is useful for debugging purposes but means nothing to a client(UA).

For any error, it is unknowable of whether repeating the same request  
some time in the future will succeed. After all, even asking for an  
"unknown" location a day later may succeed, after the road has been  
built or the database has been updated. There are even syntax errors  
that might "fix" themselves, e.g., after a client or server  
implementation gets updated with the next automatic software update.

Thus, unless you have a crystal ball protocol we should reference, I  
don't see how this can be made more concrete.

> with URI of LoST servers that can serve the request or ensure

We can't fix broken implementations. You are essentially duplicating  
the existing mechanism here.

> DHCP/Sip configuration framework?

Yes, with SIP configuration being the more likely case since VSPs are  
unlikely to operate DHCP servers unless they are also ISPs.

> Also I agree that phone BCP is probably a good place to include the

As you say, this belongs in the phone BCP, not the LoST protocol spec.

Henning

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 02 Feb 2007 12:38:31 -0500

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:

> the phone BCP last October, but I don't recall reading normative
Then we need to push the Phone BCP authors to include something in there.

> my concerns addressed in Phone BCP.
Good.

> version but I don't recall

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.

> would the data referenced include all the profile the server supports or

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

> if this is true, the granularity of boundary and that of valid should be

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

Ciao
Hannes

---

From: Shida Schubert <[email-masked]>
Date: Fri, 02 Feb 2007 10:32:10 -0800

Henning;

My comments inline..

> want to avoid writing a 150-page document.
I don't think we need to worry about this in the LoST spec itself.
I will have a look at the next revision of phoneBCP and comment there if
necessary.
> The server should do service substitution in that case, as discussed
It's at server's discretion right now to return an error or an alternative.
If the behavior is recommended as in your comment with a "SHOULD", it's
all good.
Again wait for phoneBCP I guess.
> don't see how this can be made more concrete.
I understand.
Again if the loop was caused by recursive search for sub-services the
spec can possibly
states to recommend returning a substitution if the server knows such
information.
> the existing mechanism here.
Well this is not always returned when the implementation is broken.
AFAIK from the text, server can return this error if the server does not
support
the service client requested. There is a possibility that it knows of
other server that
support the service requested in which case it should return a reference
and return
an alternative if one exists. Again a topic for phoneBCP.
> As you say, this belongs in the phone BCP, not the LoST protocol spec.
Agree. phone BCP it is.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 04 Feb 2007 13:00:29 -0500

Hi Brian,

I would strongly suggest it.

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 04 Feb 2007 13:45:25 -0500

Hi Shida,

>>> Editorial Fixes:
We have two choices:
a) Avoid using resolver and seeker.
b) Reference the LoST architecture document.

>>>     Is it recursively and not iteratively?
Iteratively is correct.

>>>   Isn't it an example of mapping query/request not mapping.
The examples indeed show how the location+service URN in the query is
mapped to a PSAP URI

Ciao
Hannes

---

From: Shida Schubert <[email-masked]>
Date: Sun, 04 Feb 2007 12:09:22 -0800

Hi Hannes;

> b) Reference the LoST architecture document.
I advocate option a). and simply use client and server through out the
whole document.
>>>>     Is it recursively and not iteratively?
Understood.
> The examples indeed show how the location+service URN in the query is
Understood.

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 04 Feb 2007 15:31:01 -0500

Hi Shida,

> I advocate option a). and simply use client and server through out the

That's how we are currently changing the document. I hope it increases
the readability since the LoST server can play multiple roles.

Ciao
Hannes