[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Ecrit] Review of draft-ietf-ecrit-lost-03.txt
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
Ecrit at ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit