Review of draft-ietf-geopriv-http-location-delivery-07

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



$Id: draft-ietf-geopriv-http-location-delivery-07-rev.txt,v 1.1 2008/05/24 15:03:19 ekr Exp $

TECHNICAL


S 4.2.
   which a Location Recipient (LR) can use to retrieve LI.  A location
   URI provided by a LIS can be assumed to be globally-addressable; that
   is, anyone in possession of the URI can access the LIS.  However,
   this does not in any way suggest that the LIS is bound to reveal the
   location associated with the location URI.  This issue is deemed out

I don't understand this point. anyone in possession of the URI can
access the URI but the LIS isn't required to reveal it? Those
seem kind of contradictory.


S 4.3.1.
   Devices that establish VPN connections for use by other devices
   inside a LAN or other closed network could serve as a LIS, that
   implements the HELD protocol, for those other Devices.  Devices
   within the closed network are not necessarily able to detect the
   presence of the VPN and rely on the VPN device.  To this end, a VPN
   device should provide the address of the LIS server it provides, in
   response to discovery queries, rather than passing such queries
   through the VPN tunnel.

How do you envision this happening? Isn't this going to require 
changing every VPN protocol? I think some more text would be 
appropriate here...

S 5.1.
   o  The HELD protocol must provide authentication, confidentiality and
      protection against modification per Section 10.3.

Are you talking about HELD, which doesn't seem to have these
features, or about the transport protocol? Also, authentication
for who? Based on what model?


S 6.5.
I'm having trouble keeping straight two kinds of URIs:

- URIs that a Device uses to get its own LI.
- LbyR references that the LIS hands out.

This text seems to imply that an LIS can hand out a helds:
URI. Is that *also* the URI that a Device derferences?


S 6.5.1.

   A "locationURI" SHOULD NOT contain any information that could be used
   to identify the Device or Target.  Thus, it is RECOMMENDED that the
   "locationURI" element contain a public address for the LIS and an
   anonymous identifier, such as a local identifier or unlinked
   pseudonym.

1. This seems like it should be clearer about what is desired.
   In particular it's not just "identify" but also "link".
   Also this needs to be clarified to indicate the implications
   of idetntifiction by position.

2. Shouldn't this be MUST strength?



S 8.
Does this say somewhere what "helds" actually means? I see the
definitition of the URI, but it doesn't say what the 
underlying transport is, as far as I can tell. Given
a "helds:" URI, what am I supposed to do with it?


S 9.
OK and here's how I get confusied about the two types of URI,
since this is an HTTP binding, but there's no corresponding
URI.


   The implementation of HTTP as a transport mechanism MUST implement
   TLS as described in [RFC2818].

Is this MUST implement or MUST use? Don't the next two sentences
imply MUST use?


   TLS provides message integrity and
   privacy

"privacy" -> "confidentiality"

   between Device and LIS.  The LIS MUST use the server
   authentication method described in [RFC2818]; the Device MUST fail a
   request if server authentication fails, except in the event of an
   emergency.

This is incomplete, because 2818 assumes the presence of a URI to
compare against. Where does that come from? 

How is client authentication supposed to work here?


S 10.3.
   o  The network SHOULD have mechanisms that protect against IP address
      spoofing, such as those defined in [RFC3704].

Is this WG really in a position to levy a SHOULD level requirement
for network ingress filtering? Recall that this is really a global level
technology. Or do you mean something else?


   o  The LIS and network SHOULD be configured so that the LIS is made
      aware of Device movement within the network and addressing
      changes.  If the LIS detects a change in the network that results
      in it no longer being able to determine the location of the
      Device, then all location URIs for that Device SHOULD be
      invalidated.

This probably needs some more detail about how it's going to work.


   When there are further mechanisms available to authenticate ownership
   of the IP address, the LIS SHOULD use them to authenticate that the
   client is the owner of the target IP address.  For example, in a TLS
   transaction, the client could present a certificate with a public key
   bound to an IPv6 Cryptographically Generated Address, and the LIS
   could verify this binding.

Not that I think that any situation in which the client has an IP
level cert is particularly likely, but this one seems particularly
unlikely.




    

EDITORIAL
Abstract:
   independent of session-layer.  This document describes the use of
   Hypertext Transfer Protocol (HTTP) as a transport for the protocol.

This should be HyperText

Also, isn't this using HTTPS, not HTTP.


S 1.
   information.  The LIS service applies to access networks employing

This is the first reference to LIS. Please expand.


   [I-D.ietf-geopriv-l7-lcp-ps] provides some scenarios in which the
   Device might rely on its access network to provide location

"the" -> "a"


   capable of MIME transport.  This document describes the use of
   Hypertext Transfer Protocol (HTTP) as a transport for the protocol.

See comments about abstract.




S 4.3.
I would move this to precede 4.1 and 4.2, since it's orthogonal
to the value/reference distinction.


S 5.1.
   o  The HELD protocol is a request, response protocol, thus the

I would write request/response.


S 6.6.
   schema Section 7 for a location response message due to XML schema

"schema Section 7" -> "schema in Section 7"





_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]