Discovering the Local Location Information Server (LIS)
draft-ietf-geopriv-lis-discovery-15

Section 2.2 begins

   A Device MUST avoid performing LIS discovery over a VPN network
   interface unless discovery on other interfaces is unsuccessful.  A
   LIS discovered in this way is unlikely to have the information
   necessary to determine an accurate location.

I find this use of RFC 2119 a little vague. In trying to parse it, I
think I concluded...

   A device MUST NOT attempt LIS discovery over a VPN network interface
   until it has attempted and failed to perform discovery on all other
   non-VPN interfaces. A device MAY perform discovery over a VPN network
   interface if it has first attempted discovery on non-VPN interfaces, 
   but a LIS discovered in this way is unlikely to have the information
   necessary to determine an accurate location.

Note s/Device/device/

---


Nits:

Section 1

   for providing that location information to devices with an access
   network.  The LIS uses knowledge of the access network and its

This is hard to parse and it is only when we get to the definitions 
later that we discover it means:

   for providing that location information to devices with attached
   access networks used to provide Internetr access.  The LIS uses
   knowledge of the access network and its


---

Section 1.1
   The bulk of DHCP information is largely static

That looks like a double vagueness :-)
Either
   The bulk of DHCP information is static
Or
   The DHCP information is largely static

2.  LIS Discovery Procedure

   A device MUST support discovery using the access network domain name
   DHCP option (Section 3) as input to U-NAPTR resolution (Section 4).
   If this option is not available, DHCPv4 option 15 [RFC2132] is used.

I would like to see more justification in the document of why the option 15 is not acceptable/sufficient for LIS discovery. An example would satisfy me.

   Other domain names MAY be used, as described in Section 3.4.

I support the Lars/Ralph Discuss, and the way to resolve that is to get
the review the DHC WG. Our process for DHCP option development is to
host it in the "user" working group (such as GEOPRIV), but run
simultaneous WGLCs also in DHC WG. This ensures that both the use case
and DHCP encoding is done correctly.

Section 2., paragraph 1:
>    A device that has multiple network interfaces could potentially be
>    served by a different access network on each interface, each with a
>    different LIS.  The device SHOULD attempt to discover the LIS
>    applicable to each network interface, stopping when a LIS is
>    successfully discovered on any interface.

  What if I have multiple access interfaces connected to multiple
  operators, all of which operate LIS servers that satisfy the criteria
  for use? According to the outlined procedure, I'd only ever use one of
  them. Does it truly not matter which LIS I use? How does this
  procedure intersect with what the MIF WG is doing?


Section 5., paragraph 2:
>    methods are described here that can limit the probablity of, or

  Nit: s/probablity/probability/

Editorial suggestion for the details in sections 3.2 and 3.3: make the field names in the diagram and the textual explanation match; e.g., in section 3.2, use either "Code" or "option-code" in both the diagram and text.

I support Pasi's discuss, which addresses the same issue as my comment, but more concisely
and eloquently.  I have retained the text of my comment, since authors may want to read this
with Pasi's discuss.

The security considerations paragraph on "https:" URIs does a nice job of explaining the 
rationale for the differences with RFC 3958 (compatibility with existing client software) but
fails to explain the security ramifications.  

Specifically, the authentication process authenticates the LIS against the output of the 
U-NAPTR process, but does not verify that the discovery process identified an LIS that is
appropriate for the requested domain.  If the attacker has compromised stages 1 or 2, the
process provides an authenticated connection to the attacker's rogue LIS.  If the process
satisfied the requirements from 3958, the https connection would authenticate the LIS
against the domain name used as input to the U-NAPTR process.  An attacker would need to
compromise stage 1 (and provide a falsified domain name) to succeed and the
vulnerability of the DNS would not be an issue.