Subject: RE: [dhcwg] Two companion IDs for consideration

From: Barr Hibbs <[email-masked]>
Date: Mon, 25 Nov 2002 22:30:00 -0800

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
James M. Polk
Sent: Wednesday, October 30, 2002 15:44

A few of us have written two companion Drafts for consideration into 2
WGs (GEOPRIV and DHC).

The first ID (into the DHC WG) is at:
http://www.ietf.org/internet-drafts/draft-polk-dhcp-geo-loc-option-00.tx
t
and defines a Location Object format...

The second ID (into the GEOPRIV WG) is the semantics ID for the DHC ID.
It's at:
http://www.ietf.org/internet-drafts/draft-polk-geopriv-loc-object-semant
ics-00.txt
and shows why the meaning of "resolution" is better suited to meet the
requirement of granular (im)precision than "accuracy".

...comments about the two drafts follow.

--Barr

draft-polk-dhcp-geo-loc-option-00:

--editorial matters

as you never repeat the acronym "RAIO" in the document, please spell it
out completely ("Relay Agent Information Option") in the first sentence
of the second paragraph of section 1.0, "Introduction."

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

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.

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.

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.

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.

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.

---

From: Marc Linsner <[email-masked]>
Date: Wed, 27 Nov 2002 12:30:56 -0500

see in-line

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

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

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

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

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

> would be more complete in and of itself.

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

-Marc Linsner-

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 27 Nov 2002 11:33:10 -0600

Barr

Interesting comments, I've provided some replies in-line below

>of the second paragraph of section 1.0, "Introduction."

This will be changed, thanks for the suggestion

>provided BY the server TO the client.  

This is the direction DHCP works in. RAIO is a special case and one that
the client will never know about I believe.

>This seems applicable to both
>wire-connected clients and some wireless clients 

It can be, but the wired applicability is a known when the DHCP Server
interfaces to a known wiring map of the infrastructure, wireless isn't as
known, except maybe for:

>(a specific access
>point might identify location with sufficient precision), 

This can provided for with this option proposal. The AP is a wired device
(typically) and is connected to a wired port (hopefully in a known wiring
map infrastructure).

>but can you
>the location information TO the server?  

We don't (at this time) consider this to be under the charter of DHCP, but
it does fit into GEOPRIV's charter explicitly (a device providing its
location).

>If so, perhaps this sentence

I agree with your last comment here

>information as application data, not entirely appropriate for DHCP.  

I don't agree. Getting the location object (LO) into the endpoint at
configuration time allows the application layer to use and manipulate it as
whatever/however the user/policy wants to (with GEOPRIV or SIP or another
protocol)

>If
>question the need.  

Getting the LO to the IPT endpoint/UA allows it to then immediately place
an e911 session/call without another process potentially failing. No one
knows if GEOPRIV will be coded into all UAs or other endpoints, but this
option in DHC is fairly trivial to add. I for one want a consistent LO
format (at least in certain critical fields). Another protocol can then use
this LO for its purposes. If GEOPRIV is coded into a particular UA or
Target/endpoint, then the fullness of the GEOPRIV Protocol can be used with
the LO already local to it. This can provide the ability to do some
relative location determination (where the nearest Pizza Hut to me?), which
isn't part of GEOPRIV in its current form (but is foreseen in its future dev)

>I can think of other uses for this information

Once the LO is in the endpoint, those other apps can use it (preferably if
they meet GEOPRIV's security requirements)

>maximum precision of latitude and longitude?  

34 bits are used for each (and 30 for Altitude)

>Here I'm imagining future

On the equator, 34 bits of La/Lo will get to a granularity of 
3.11mm x 2.62mm (this trapezoid gets smaller as you get nearer the poles),
do you want explicitly more granularity than that? We could add 4 or 8 bits
more to each (La/Lo) field if the WGs desire it, but I don't know if this
is terribly useful at this point. comments?

>be completely appropriate, such as room and cubicle number.  

Ahhh, what Henning calls "Civil" coordinates. We thought about this, but
couldn't come up with how a endpoint can make its location
deterministrically less precise based only on Civil addressing. I agree
that this is more information, but it's also only known to those who built
the building. This can be gotten upon entrance to the building (based on
the wire-map and provided La/Lo/Alt (in Floors).

>If so, then

I agree that this would be required if employed, but this will also be
unique to each building (conceivably everywhere).

>measure if devices are much above passenger aviation levels?  

Anyone in a plane isn't in a wired connection (even considering Boeing's
future plans). Further, that device in the plane moving at between 200 and
650nmph wouldn't have their location provided very precisely moment to
moment... GEOPRIV is working on providing the necessary information for
tracking a moving target (with the vector/velocity fields, and potentially
a delta field), and thus I don't think that DHCP Reply should attempt to
tackle that situation.

BTW - if another Altitude Measurement Unit were proposed, satellites in
Geo-synchronous Orbit could have known LOs applied to them. But everything
between the top of Mt. Everest and Geo-sync would not be stable (or wired)
so we chose not to include km as a MU in this version of the doc.

>Again, I'm
>what system is used for, say, the lunar lander or a mars probe, 

All related GEOPRIV efforts are based on a spheroid with a single and know
center. Any LO for our Moon or Mars will be possible with a given datum to
work from (but it won't be from Earth)

>let

This split explanation was always the intent with this effort. I believe an
informational semantics doc should be right along side this standards track
option doc through this process (allows for freer wording/writing and
explanation that mechanism docs don't like in them)

cheers,
James 

              *************************************
"People generally demand more respect for their own rights than 
                         they are willing to allow for others"

---

From: Barr Hibbs <[email-masked]>
Date: Wed, 27 Nov 2002 11:52:31 -0800

comments in-line

--Barr

-----Original Message-----
From: Marc Linsner [mailto:[email-masked]]
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.

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

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