RE: [dhcwg] Two companion IDs for consideration

["James M. Polk" <[e-mail]>]

Barr

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

At 10:30 PM 11/25/2002 -0800, Barr Hibbs wrote:
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]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."

This will be changed, thanks for the suggestion

>
>
>
>--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 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
>imagine a future scenario where a wireless or roaming client supplies
>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
>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 agree with your last comment here

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

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

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
>besides E911 over IPtel (operations, management, and troubleshooting
>come to mind) but all are really applications-layer functions.

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

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

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

>Here I'm imagining future
>implementations of millimeter-sized devices such as medical implants
>where additional precision might be considered essential.

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?

>
>4.  in fact, I wonder whether even less-precise planar coordinates might
>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
>some mechanism for specifying which units were employed for the
>coordinates would seem to be required.

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

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

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
>not sufficiently conversant in the technology of location to know even
>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
>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.

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"


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg