Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums



Hi Brian,

I quickly respond to your question but I do not plan to restart the last 2 years of GEOPRIV discussions.
(I personally got the impression that the work on a GEOPRIV Layer 7 LCP solution was not really subject for discussion anymore. I acknowledge the fact that some folks still don't agree but most of the GEOPRIV working group members do. The main issue was which solution proposal to pick as a baseline for future work.)


Brian E Carpenter wrote:
On 2007-04-20 09:21, Hannes Tschofenig wrote:
DHCP is not a great choice in a mobile environment and also not when it comes to more complex location representations.

Why can't a mobile system have a locally valid DHCP record (+/- the length
of a wireless link)? For that matter, why couldn't a DHCP server have
real-time triangulation data, if it exists at all?


I should have written "RFC 3825 is not a great choice in a cellular environment". It is fine for a WLAN hotspot and an enterprise environment.
where it also competes with other layer 2 location configuration mechanisms and LLDP-MED.


Do you mean more complex than can be expressed by RFC 4776 and RFC 3825 together?

RFC 3825 describes a point.
Civic address formats (RFC 4776) have good applicability in fixed and some selected wireless environments (WLAN hotspot).
They haven't been considered in the cellular space.


Location determination techniques produce other shape types. Please look at
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-06.txt

Brian

Ciao Hannes


_______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf




Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.