RE: [dhcwg] Two companion IDs for consideration

[Barr Hibbs <[e-mail]>]

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



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

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