comments in-line
--Barr
-----Original Message-----
From: Marc Linsner [mailto:mlinsner@cisco.com]
Sent: Wednesday, November 27, 2002 09:31
> --content matters
>
> ... perhaps this sentence needs to be generalized, or a specific
> exclusion be included that prevents client to server notification
> (I'm not clear on how or why a DHCP server might use this information
> as it seems more application-oriented than network-oriented.)
I envision a 'service' that may be the receiver of the location object,
but can't imagine why the DHC server would want it after the client is
initialized. I don't think we want to change the role of the DHC
server.
...after reflecting on this for a few days (while fighting off a cold) I
slightly regret the way I phrased that statement: the physical location
of a network host is a very useful and practical bit of information for
several purposes including operations and management. For example, an
application service might recognize that communication is lost with the
host, and open a trouble ticket that includes the location of the host
for dispatching a technician. But, the location really is a piece of
application-layer information.
> ... If I could see a clear motivation for needing location information
> at this point in the initialization process (likely to be before
> higher-layer protocols, such as IP telephony, are loaded and
activated)
> I wouldn't question the need. I can think of other uses for this
> information besides E911 over IPtel (operations, management, and
> troubleshooting come to mind) but all are really applications-layer
> functions.
It could be argued that gaining knowledge of one's location is outside
the scope of host configuration, but hosts without additional hardware
are still going to require 'something' of the network in order to gain
it's geo-location from a possible newly defined protocol/service
mechanism. This 'something' would most likely be a piece of network
information, similar to DNS info, NTP info, etc.
...if you'll allow me to pontificate for a moment, configuring the
client host with the *address* of a geolocation server is what a DHCP
server would traditionally supply. The advantage of this (indirect)
approach is that no matter how much the syntax or semantics of the
geolocation information might change in the future, no changes at all
are required to the proposed DHCP option.
We view the act of geo-location, for a 'hardwired' device, as a
configuration/initialization issue. We are attempting to provide a
mechanism where the IP Telephony device can gain knowledge of it's
location without the need for additional hardware or communication
protocols. Since we are targeting 'hardwired' devices with this method,
the fact that the device will already know it's location when it is
registering with it's call agent (SIP proxy, H.323 gatekeeper, etc.) via
an 'already understood and widely implemented' protocol, we view as a
good fit for the 2 million plus installed IP Telephony devices. So, the
question remains: 'When is the proper time for a device to figure out
it's location?' The quickest answer to us was - at host configuration
time.
... as much as I understand the difficulty of defining a new protocol
and getting it accepted and widely implemented, I still believe indirect
configuration of an essentially application layer service is the correct
way to do this.
> ... I wonder why only 48 bits is used for the maximum precision of
> latitude and longitude? Here I'm imagining future implementations
> of millimeter-sized devices such as medical implants where additional
> precision might be considered essential.
The object allows for 25 bits of fractional degrees on both latitude and
longitude. Before we go for a higher resolution, I think we need to
consider what is practical for current implementations and try to
predict
the 'near future' uses. I agree that a 'few more bytes' added to the
resolution certainly wouldn't break and any size rules with the object,
but we also need to consider it's intend use. Currently, most (more
accurately - all) commercially available devices can't take advantage of
the offered resolution within this object, we are at 3.11 mm at the
equator, which will be your largest longitude resolution. It wasn't our
intention to use this object to locate things that have a different
coordinate system than the planet earth. One would guess that the
medical
micro implant on a human body would use a location coordinate system
that
has a different starting point than 0,0 lat/long. It would most likely
use a reference point on the body it resides within, hence would need a
different coordinate system with a different starting point, and a
different geo-location object.
...okay: clearly there's been lots of thought given to these topics,
and I appreciate your taking a few moments to enlighten me.
> 4. in fact, I wonder whether even less-precise planar coordinates
might
> be completely appropriate, such as room and cubicle number. If so,
then
> some mechanism for specifying which units were employed for the
> coordinates would seem to be required.
There are others that are working on defining location objects that are
more suitable for human consumption. Objects that express civil
locations, or objects that express network locations. Our intention is
to define an object that is in current use 'globally', and is very
small. Let's not slow down the progress on this object, as it seems to
be
globally acceptable.
... yes, latitude, longitude, and altitude are pretty much globally
useful measurements from a universally accepted coordinate system, but
the work to develop other objects raises the question, "will there be
need for other, future implementation objects with different formats?"
If the likely answer is yes, then my opinion is that it would be
preferable for this option to pass a [list of] geolocation servers
rather than the specific coordinates currently proposed.
> 5. altitude should be able to be specified to near-orbital precision
in
> 30 bits, but I wonder if latitude, longitude and altitude is the best
> measure if devices are much above passenger aviation levels? Again,
I'm
> not sufficiently conversant in the technology of location to know even
> what system is used for, say, the lunar lander or a mars probe, let
> alone what is sufficient precision, but it seems appropriate to ask.
There will still be several DHC option numbers available when someone
sees
the need to define a location object to handle the galaxy.
... <grin> can I sign up now for on-site testing???
Received on Wed Nov 27 14:51:28 2002
This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:23 EST