RE:Two companion IDs for consideration

see in-line

> --content matters
>
> 1. the first sentence of the first paragraph of section 1.0
> "Introduction" clearly limits the scope of this option to be data
> provided BY the server TO the client. This seems applicable to both
> wire-connected clients and some wireless clients (a specific access
> point might identify location with sufficient precision), but can you
> imagine a future scenario where a wireless or roaming client supplies
> the location information TO the server? If so, 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.

>
> 2. section 1.2, "Motivation," provides some of the background for this
> option that I asked about above, but I see the use of the location
> information as application data, not entirely appropriate for DHCP. 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.

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.

>
> 3. section 1.3, "Rationale," includes rationale for the composition of
> the three components of location (latitude, longitude, and altitude) but
> has a few interesting discrepancies. Let me state that I'm NOT an
> expert in geolocation, so I may not appreciate the design choices that
> have been made here, but 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.

The altitude part of the object is defined by the cooresponding measure unit
value. We currently define 2 of the possible 16 values - 14 undefined
values should leave enough room to cover several other measurement unit
types.

>
> 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.

>
> 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.

>
>
> draft-polk-geopriv-loc-object-semantics-00;
>
> --my only comments on this draft are that some of the explanation and
> examples presented here could be included in the other draft so that it
> would be more complete in and of itself.

You'll see some changes along those lines in the next few weeks.

-Marc Linsner-
Received on Wed Nov 27 12:30:31 2002