---------------------------------------+------------------------------------
Reporter: martin.thomson@andrew.com | Owner: bernard_aboba@hotmail.com
Type: defect | Status: new
Priority: trivial | Milestone: draft-ietf-geopriv-3825bis
Component: rfc3825bis | Version:
Severity: Active WG Document | Keywords: determination
---------------------------------------+------------------------------------
The following statement does not necessarily hold true and needs to be
challenged:
>The location information is derived from a wiremap by the DHCP server,
>using the Circuit-ID Relay Agent Information Option (RAIO) defined (as
>Sub-Option 1) in RFC 3046 [RFC3046]. The DHCP server is assumed to have
>access to a service that can correlate a Circuit-ID with the geographic
>location where the identified circuit terminates (such as the location of
>the wall jack).
Indeed it goes beyond what is necessary for interoperability. Would it
cause interoperability problems if I just looked up the MAC address of a
client in a table to determine where they are? Because that's not a lot
different from what happens in cable networks from what I remember?
Since this is hidden, this is only really useful as a way of pointing out
one way that this could be done - a feasibility proof as it were.
It shouldn't take much to fix this:
>The location information could be derived from a wiremap by the DHCP
>server, using the Circuit-ID Relay Agent Information Option (RAIO)
defined
>(as Sub-Option 1) in RFC 3046 [RFC3046]. In this case, the DHCP server
>could correlate the Circuit-ID with the geographic location where the
>identified circuit terminates (such as the location of the wall jack).
Furthermore, the lead-in to this paragraph seems to be incorrect also:
>These options enable a wired Ethernet host to obtain its location.
Since this is being used in other network types, I think that it would be
sensible to say this:
>These options enable a DHCP client to obtain its location. For example,
a
>wired Ethernet host might use this option to obtain its location. In
this
>case, the location information could be derived from a wiremap by the
DHCP
>server ...
--
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/21>
geopriv <http://tools.ietf.org/geopriv/>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
