[Geopriv] Review of draft-winterbottom-geopriv-lis2lis-req-01.txt

[Hannes Tschofenig <[e-mail]>]

A few notes to the 
http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-lis2lis-req-01.txt 
document.

* I would put a few lines of motivation to the indicated assumptions.

   1: A strong trust relationship exists between the regional access
      provider and ISP.

The motivation for this one is created by the need to provide strong 
authorization. It needs to make sure that only authorized ISP LISs 
are able to retrieve location information from the regional access LIS


   2: Targets only deal directly with the ISP LIS, and may be totally
      unaware of any regional access provider LIS.  A regional access
      LIS will only ever receive location requests from an ISP LIS.


To the end host the regional access provider behaves like a physical / 
link layer provider. Allowing the end host to deal with the ISP LIS 
hides the details of the underlying network infrastructure. 


* Requirements: The requirements need to be written in a way that they 
point to protocol functionality.

   1: Connections (physical and logical) from the ISP LIS to the
      regional access LIS require both ends to authenticate as part of
      connection establishment.  The security of the data conveyed
      between the two servers MUST be ensured for both privacy and
      integrity.

Modified requirement: 

The protocol used between the ISP and the regional access LIS MUST offer 
mutual authentication and communication security. 

   2: The data used to identify a Target to the ISP MUST be able to be
      passed to, and be recognizable by the regional access LIS using
      the LIS to LIS protocol. 


This is not really a protocol requirement either. 
This sentence should go into the BCP. 

I would say that "The LIS-to-LIS protocol MUST support a wide variety 
of identities to assist the location determination procedure. 
The chosen identity is likely to depend onthe specific deployment 
environment. The set of identities MUST be extensible."
 


 The data used to identify a Target to
      the ISP MUST be consistent with the traffic aggregation method
      supported by the Regional Access Network Provider.


I am not sure I understand this part of the requirement. Can you motivate? 

   3: Location information returned over a LIS to LIS protocol MUST be
      in PIDF-LO [RFC4119] format, and MUST comply with
      [I-D.ietf-geopriv-pdif-lo-profile] .


I would also add the revised civic spec here. 


   4: The type of location information requested by the end-point MUST
      be relayed to the regional access LIS by the ISP LIS using the LIS
      to LIS protocol.


This is also text that should go into the LIS2LIS BCP. 

   5: The method used by the regional access LIS to determine the
      location of the Target MUST be provided to the ISP LIS along with
      the determined location.

This is also text that should go into the LIS2LIS BCP. 
I suspect that "method" refers to the location determination method. 



   6: Any usage-rule preferences provided by the Target to the ISP LIS
      MUST be included in any location returned to the Target or
      Location Recipient.

This requirement has nothing todo with the LIS2LIS communication. 
This text may go into the LIS2LIS BCP. 



   7: Additional information provided by the Target to the ISP in a
      location request that cannot be processed directly by the ISP LIS
      MUST be forwarded to regional access LIS using the LIS to LIS
      protocol.  The intention of this requirement is to support future
      LCP functions that require additional information from the Target.

I don't have a strong opinion about this requirement. 


   8: The presentity in the PIDF-LO returned by the regional access LIS
      MUST have been provided by the ISP LIS.  The ISP LIS may create
      the presentity, or it may have received a presentity from the
      Target.

Hmmm. Why isn't it possible for the ISP LIS to just set the presentity to 
whatever it wants. The regional LIS wouldn't want to sign the PIDF-LO anyway. 



   9: The protocol MUST provide support for returning and dealing with
      error conditions such as "no location found" or "timeout".

Is it necessary to state that a protocol has to provide error conditions? 



* I would merge this document with
http://tools.ietf.org/wg/geopriv/draft-winterbottom-geopriv-held-lis2lis-bcp-00.txt
since
 -- few documents need to be read
 -- draft-winterbottom-geopriv-held-lis2lis-bcp-00.txt does not define 
new protocol mechanism
and is therefore quite lightweight




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