Subject: Re: [Ecrit] RAI-ART review for draft-forte-lost-extensions-02.txt

From: Andrea G Forte <[email-masked]>
Date: Mon, 10 Jan 2011 16:31:24 -0500

Please read comments inline.

Thanks,
-Andrea

On 12/31/10 6:26 AM, Shida Schubert wrote:
> I am the assigned RAI-ART reviewer for draft-forte-lost-extensions-02.txt.
>
> For background on RAI-ART, please see the FAQ at<http://www.softarmor.com/rai/art/FAQ.html>.
>
> Please resolve these comments along with any other comments you may receive.
>
> ***
> This draft is basically ready for publication, but has nits that should be fixed before publication.
> ***
>
> I am sending the nits to the authors so I am sending few technical concerns I have on the lists.
>
> ** Comments on the draft **
>
> 0. This draft	 alters a definition of region for non-emergency services, should this be
>       updating the RFC5222 in anyway? I am not sure if it should as emergency case
>       is obviously the main user of the protocol but will this be the case, say in 5 years?
I do not have any particular position on this.

> 1. Looking at the definition of "query" in RFC5222, the draft is not really defining
>      a new queries but defining a filter to limit the results. I don't feel that term
>      "queries" for this extension defined in this draft is appropriate. I apologize for not being
>      able to come up with a proposal but "query" just didn't sound right..
I do not agree with this. A filter as such, is applied on a number of 
existing results to further constrain
them based on some metric. In this case, we do not have a pre-existing 
set of results that we are filtering, here we
"ask" the server a more specific question and the server replies with 
the results fulfilling this specific question.

In RFC 5222 it reads:
"The query message carries location information and a service
    identifier encoded as a Uniform Resource Name (URN) (see [9]) from
    the LoST client to the LoST server.  The LoST server uses its
    database to map the input values to one or more Uniform Resource
    Identifiers (URIs) and returns those URIs along with optional
    information, such as hints about the service boundary, in a response
    message to the LoST client."

This is true also for our new queries. Can you please let me know where 
in RFC 5222 you see a definition of query
that is in contrast with what we define in the draft?

> 2. The draft clearly states that these extensions are NOT applicable to the
>       emergency uses. If that is the case the draft should probably say that it MUST NOT be
>       used in emergency cases somewhere in the draft, especially if it has negative
>       implication (I couldn't think of any but..).
OK, we will add the MUST NOT.

> 3.<region>  is used when you want to query the LoST server to find a service
>       that serves the requesting entity's location but default behavior of LoST as
>       defined in RFC5222 is to conduct a query based on the region so this seems
>       tad bit odd to me. Especially because when<region>  is absent, one is supposed
>       to conduct a search based on the distance from the user but it should be the
>       other way around. Either say that when<region>  is absent it is assumed true
>       or define alternative element which describes that it's for doing a "instance within
>       X distance".
Yes, to have a more consistent behavior between emergency and 
non-emergency services,
we can say that when <region> is absent, it is assumed to be true rather 
than false.
> ** General comments about the use of LoST for service other than emergency **
>
> I think this draft highlights lack of consideration during the creation of LoST generic uses
> beside emergency services and this raises some concerns not necessary with this draft
> but with the generic use of LoST in general.
>
> 1. When LoST server is used for generic uses, I believe the server will be stressed a lot
>      more than when used for Emergency cases due to unique computation required for
>      querying users's location to service region of the service or searching for services
>      within distance X. I just hope that encouraging
>      the use of LoST for generic uses will not interfere with the Emergency service in anyway..
>      I am assuming that in real deployment, the LoST server that handles the initial request
>      will probably dispatch or redirect the request to appropriate server that can handle the
>      requested service, so LoST serve that will handle the mapping of location to PSAP will
>      not be overwhelmed by trying to figure out what pizza delivery is close to Joe's current
>      location.
In real deployments I do not think that LoST servers in the ESInet will 
be available also for non-emergency
services. I think that access to the ESInet will be granted only for 
serving emergency queries or perhaps other
government-related needs.

>
>
> 2. Although, I am assuming most or all of the remaining queries will function as
>      defined in RFC5222, I think we should probably look at how the rest of the
>      query beside<findservice>  will look like and behave when used for generic uses.
>
>     e.g.
>      How useful is the listservice / listserviceresponse in generic uses as is now?
>>> Should there be an extension to query<listservice>  with a filter so
>              only a sub-element will be displayed (querying the LoST server with
>              urn:service:restaurants or urn:service:stores?
>
>     This has nothing to do with the draft in question.. But something we may want to
>     think about if we are going to encourage people to implement LoST for non-emergency services.
>
> Regards
>   Shida

---

From: Shida Schubert <[email-masked]>
Date: Mon, 17 Jan 2011 09:56:27 +0900

Hi Andrea;

 My comments inline.

> I do not have any particular position on this.

 Same here. I think we need additional feedback on this. 

> I do not agree with this. A filter as such, is applied on a number of existing results to further constrain
> them based on some metric. In this case, we do not have a pre-existing set of results that we are filtering, here we
> "ask" the server a more specific question and the server replies with the results fulfilling this specific question.
> 
> In RFC 5222 it reads:
> This is true also for our new queries. Can you please let me know where in RFC 5222 you see a definition of query

 The definition you are referring doesn't necessary contradict with what 
you are defining in the draft, but RFC5222 section 3 clearly 
identifies type of queries associated to each request type.

 This draft definitely doesn't add any new request type, rather it 
uses the pre-existing request type (findservice etc.) to allow 
specific search to be conducted at LoST. 

 AFAIK It's not a new query that you are defining, but an extension 
to an existing query which alter the semantics of the request to get 
desirable result. 

 I don't really have a strong opinion on this, but when I was reading, it 
was rather confusing to say that you are defining new queries. 

 Furthermore does it make sense to have these extension elements 
appear in other query type? 

> Yes, to have a more consistent behavior between emergency and non-emergency services,
> we can say that when <region> is absent, it is assumed to be true rather than false.
> In real deployments I do not think that LoST servers in the ESInet will be available also for non-emergency
> services. I think that access to the ESInet will be granted only for serving emergency queries or perhaps other

 I don't think how you would do this. 

 How would the client know which LoST server is for ESInet and which one isn't? 

 LoST is not like DNS, where you can look at the root domain and dispatch/delegate 
the request to appropriate server. With LoST, LoST server would have to parse the 
XML to see if the request is for emergency or non-emergency service. 

 However, it's an HTTP server after all and I do think scaling HTTP server 
is probably trivial so I will withdraw my concern on this. 

 Regards
  Shida