[Geopriv] Review of draft-winterbottom-geopriv-held-lis2lis-bcp-00.txt

[Hannes Tschofenig <[e-mail]>]

Some comments for 
http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-held-lis2lis-bcp-00.txt

The document looks good to me. Still, I would merge it with the 
requirements draft.

I would appreciate more RFC 2119 language in Section 4:

4.  Detailed Description

   In a typical environment using HELD, the Target discovers the LIS
   using one of the methods described in
   [I-D.thomson-geopriv-lis-discovery], and makes a request for location
   information.  The ISP LIS receives the location request from the
   Target, adds additional information, and then sends the location
   request on to the regional access provider LIS.  The regional access
   provider LIS uses the extra information provided in the ISP LIS to
   determine the location of the Device and provide the PIDF-LO
   [RFC4119] in the requested form.

   The ISP LIS will, in many cases creates the identity used in the
                                   ^^^^^^^ create
 "pres" field of the PIDF-LO.  This value needs to be conveyed from
   the ISP LIS to the regional access provider LIS.  HELD can convey
   this value using a URI identity extension as described in
   [I-D.winterbottom-geopriv-held-identity-extensions].

I don't think that it is necessary to send the identity to the 
regional access provider LIS

   The ISP LIS may need to provide Device network attachment
               ^^^ MAY

   information, in the form of measurements, to the regional access
   provider LIS to aid it in determing the Device's location.
                             ^^^^^^^^^ determining
 A
   comprehensive set of measurements and how they are used is provided
   in [I-D.thomson-geopriv-held-measurements].  HELD supports the
   inclusion of these additional elements without modification.

   The ISP LIS should not send a request for a location URI to the
               ^^^^^^^^^^SHOULD NOT 
   regional access provider LIS.  This is because the regional access
   provider LIS is, in most cases, invisible to entities other than the
   ISP LIS.  A location URI contains the hostname of the LIS that will
   service a location request, which is the ISP LIS and not the regional
   access provider LIS.  Consequently only the ISP LIS should create
                                                       ^^^^^^ SHOULD 

   location URIs for the Device.  A regional access provider LIS
   receiving a request for a location URI from an ISP LIS should respond
                                                          ^^^^^^ SHOULD
   with a "cannotProvideLiType" error.
                                     ^^^ if it got a request for creating 
a location URI that it cannot fulfill. 


   The ISP LIS should pass all elements included in the Device's
   location request to the regional access provider LIS, with the
   exception of a request for a location URI which was described in the
   previous paragraph.  This behaviour ensures that any new options made
   available to the LIS through HELD can be supported without
   necessarily requiring changes to the ISP LIS.

I cannot imagine a use case where this would really be helpful as the ISP 
LIS is not really a relay but rather the endpoint of the communication 
from the HELD Target-to-LIS point of view. 


   The ISP LIS should provide usage in any returned location object that
   match the user's desired settings, or in the absence of these, the
   default settings for <retransmission-allowed> and <retension-expiry>
   as applied by the ISP LIS.

This corresponds to the HELD default procedure and does not need to be 
repeated here. 


   Basic HELD is provided with an HTTP binding, which is suitable for
   the application of a Device requesting its own location.  Where a
   nailed up connection between two entities and continual transaction
   streaming is required, HTTP may be less appropriate.  In this
   configuration an alternative transport, such as BEEP
   [I-D.thomson-geopriv-held-beep], may be used.
                                    ^^^^MAY

I would say that it is useful to indicate that the regional access 
provider LIS and the 
ISP LIS have to implement HELD, HELD Identity extension and HELD  
measurements. I would make this clear in this section. 

The implementation of [I-D.thomson-geopriv-held-beep] is optional. 


* Examples. The examples are code fragments. Please add the 
<?xml version="1.0"?>
header. 


* Security

 A strong trust relationship needs to exist between the ISP and the
   regional access provider in order for this type of access network to
   operate successfully. 


I would use something like "To provide proper privacy protection the 
regional access provider
LIS would enforce access control on entities requesting location 
information to ensure that only
ISP LISs  that have a pre-established trust relationship (potentially 
based on a business contract)
are granted authorization."



_______________________________________________
Geopriv mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/geopriv