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

From: Shida Schubert <[email-masked]>
Date: Fri, 31 Dec 2010 19:26:29 +0800

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? 

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

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

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

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

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