Eric,

Thanks for the re-review. I've a few comments embedded below [MB].  

Mary. 

-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
Behalf Of Eric Rescorla
Sent: Tuesday, July 15, 2008 11:42 AM
To: geopriv@ietf.org
Subject: [Geopriv] Review of
draft-ietf-geopriv-http-location-delivery-08

$Id: draft-ietf-geopriv-http-location-delivery-08-rev.txt,v 1.1
2008/07/15 16:00:40 ekr Exp $

I've reviewed this revision of HELD. Comments below.


S 4.1.1.
   Devices that establish VPN connections for use by other devices
   inside a LAN or other closed network could serve as a LIS, that

s/could/should/?
[MB] This was purposefully changed to the "could" as the intent was not
for these sections to be normative, but rather to provide a guide as how
things will function best with the protocol. And, per past WG consensus,
the only normative 
statements that we can apply to the LIS are specific to the protocol and
not how the LIS might actually determine the location. [/MB]


   device should provide the address of the LIS server it provides, in

should/SHOULD/?
[MB] Ditto. [/MB]


S 4.1.2.
   should provide an error response to the requesting device.  The LIS

s/should/SHOULD/
[MB] Ditto. 


S 4.3.
   However, possession of the URI does not in any way suggest that the
   LIS indiscriminately reveals the location associated with the
   location URI.  The specific requirements associated with the
   dereference of the location are specified in
   [I-D.ietf-geopriv-lbyr-requirements].  The location dereference
   protocol details are out of scope of this document and are specified
   in [I-D.winterbottom-geopriv-deref-protocol].

This and the following text that has a SHOULD level requirement to
return locationURI in S 6.2 seem pretty clearly to me to produce a
normative dependency on draft-winterbottom-geopriv-deref-protocol.
[MB] I think that's fine since that seems to be the only way to resolve
this concern (unless we do as I suggested in my other response to the
consensus point email. [/MB]


S 5.1.
   o  The HELD protocol REQUIRES that the underlying transport provide
      authentication, confidentiality, and protection against
      modification per Section 10.3.

This requirement is not met when TLS is not used, which is apparently
permissible.
[MB] So, are you suggesting that we need to reword this as a should or a
MUST implement. [/MB]






S 6.2.
   specific order.  For example, a locationRequest for "civic" could
   yield any of the following location types in the response:

   o  civic
   o  civic, geodetic
   o  civic, locationURI
   o  civic, geodetic, locationURI
   o  civic, locationURI, geodetic
   o  geodetic, locationURI (only if civic is not available)
   o  locationURI, geodetic (only if civic is not available)
   o  geodetic (only if civic is not available)
   o  locationURI (only if civic is not available)

Unless I've misread this, there's no MUST level requirement to return
civic even if available,  right?
[MB] True, per the later examples. I think you're suggesting I should
have a blank response? [/MB]


   URI.  If the "locationType" element is absent, a location URI MUST be
   assumed as the default.  A location URI provided by the LIS is a
   reference to the most current available LI and is not a stable
   reference to a specific location.

Surely there are situations in which I would want a stable reference,
no? I haven't been tracking the WG that carefully, but this seems like
an odd rule, especially here.
[MB] The point is that the actually location for a locationURI is not
fixed at the time that the locationURI is returned to the user.  [/MB]


S 6.5.
   it supports and that each scheme is present only once.  The helds:
   URI scheme as defined in Section 8 is one possible scheme for the
   "locationURI" element.  URI schemes and their secure variants, such
   as http and https, MUST be regarded as two separate schemes.


helds or heldrefs?

[MB] I will reword as suggested. [/MB]


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

Can it contain the naked position?
[MB] I guess it could, but it would be good if we scoped an appropriate
example (which I honestly can't think of one unless it's a closed secure
environment and we don't define IETF protocols for that do we?). [/MB]


S 8.
OK, I'm still confused by the text here. Can heldref/heldrefs be
returned by the discovery system or are they just relevant for
locationURI? If the second, it seems pretty odd to have them here but
not to have the former here. In any case, this language is unclear.
[MB] No, the URIs, per the other email, are only relevant for a
locationURI. I'm not clear as to what specific language is unclear.
[/MB]


S 8.1.
This example should have "heldref:", no?
[MB] The ABNF is incorrect per Martin Thomson's comments, if that is
your concern. [/MB]

This section needs some description of how the URIs
are actually derefrenced with HTTP. I know it seems
obvious, but it should be clear. Is the URI translated?
How is the query string handled? Is there a GET or
a POST (you have examples with both). I realize that there
is an example, but normative langage seems appropraite.
[MB]  I will try to add some text to address this concern, although it's
not entirely clear to me. [/MB]



-Ekr
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv