Subject: DHCP options for civil locations

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 05 Dec 2002 13:32:51 -0500

Inspired by the Polk/Linsner/Schnizlein draft on using DHCP for 
conveying geospatial location information to client, I wrote up a 
complementary draft on civil locations:

draft-schulzrinne-geopriv-dhcp-civil-00

Until it appears in the archives, you can find it at 
http://www.cs.columbia.edu/~hgs/sip/drafts/draft-schulzrinne-geopriv-dhcp-civil-00.txt

Usage would be similar and complementary to the DHCP-geo draft, i.e., it 
would allow clients to determine their current (approximate) location at 
boot or network join time.

This is still very immature work; I would appreciate feedback.

Henning

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 06 Dec 2002 14:13:46 -0800

Hi Henning,

This is a fairly US centric. For example, it woud be very difficult to  
represent a Japanese address using this system.  I'd suggest adding ISO  
top level location (country), and changing state to "second-level  
location" (state, province, region, but well-defined worldwide).  you  
could also remove county and district and add third/fourth/fifth level  
administrative regions  (county, township, and probably district in the  
US).  Likewise, you may want to add a hierarchy of community name.

For example: Japan has an address hierarchy.  I have probably butchered  
it, but this should get the point across

to/fu or ken/do	metropolis or prefecture  (these are ISO level 2  
regions)
shi or gun		city or rural area
ku			ward (only within a "to" or "shi")
chou or mura	town or village
chome		district
ban			block

I originally researched this from a set of books that I no longer have,  
but I found a short description at:
http://www.csse.monash.edu.au/~jwb/afaq/addresses.html

---------

i once proposed a hierarchical format for civil names name incorporated  
this general idea.

administrative regions
a1 = top level (country)
a2 = second level (state, province, region)
a3 = county, shi, gun
a4 = township, chou?, mura?
a5 = smaller administrative division
...

habitated area
h1 = metropolitan area
h2 = city or town
h3 = ward, major town division, ku
h4 = district, chome
h5 = subdistrict, block, ban

road or way (by way of example)
r1 = primary, major road, multiple lanes, sealed
r2 = secondary major road
r3 = business thoroughfare
r4 = residential artery
r5 = residential feeder
r6 = other residential road or track
r6 = private or minor road or track
r7 = etc..

my house would be:
<a1>us</a1>
<a2>ca</a2>
<a3>santa cruz county</a3>
<h1>greater santa cruz</h1>
<h2>city of santa cruz</h2>
<h3>westside</h3>
<h4>linda vista district</h4>
<r6>ladera drive</r6>

You can represent a Japanese address, and even an address like this one  
(yes this is their real postal address sans postal code):

The Gibsons
Barmby on the Marsh
Near Goole
North Humberside
UK

hope this helps.
thanks,
-rohan

On Thursday, December 5, 2002, at 10:32 AM, Henning Schulzrinne wrote:

> Usage would be similar and complementary to the DHCP-geo draft, i.e.,  
> it would allow clients to determine their current (approximate)  
> location at boot or network join time.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 06 Dec 2002 18:17:53 -0500

Thanks for the comments. In general, I think I agree with your approach. 
My interpretation is that each country would need to define what nth 
level means. For example, Portugal has regions, but nobody uses them for 
addressing. They would be a 2nd level designation, but redundant.

> represent a Japanese address using this system.  I'd suggest adding ISO  

That's already there, as CountryCode. Since every address will have that 
and it has a fixed length, I figured it would be a waste to encode it as 
TLV.

> http://www.csse.monash.edu.au/~jwb/afaq/addresses.html

http://www.bitboost.com/ref/international-address-formats.html has lots 
of information on addressing topics (or weirdnesses, if you like).

> r6 = private or minor road or track

For the purposes of locating people and housess, I don't think it's 
necessary to make these r distinctions - we're not trying to draw maps 
here. These are somewhat arbitrary.

---

From: Barr Hibbs <[email-masked]>
Date: Sun, 08 Dec 2002 01:40:20 -0800

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Thursday, December 05, 2002 10:33
> Inspired by the Polk/Linsner/Schnizlein draft on using DHCP for
conveying
> geospatial location information to client, I wrote up a complementary
draft
> on civil locations:  draft-schulzrinne-geopriv-dhcp-civil-00
>

My only issue with this draft is that, like the Polk/Lisner/Schnizlein
draft, it is intended to convey essentially application layer
information through a protocol intended primarily for configuring lower
layers.  This does not make the draft unworkable, unusable, or any other
sort of "un-" but is just an observation that few DHCP options intended
for application configuration have ever been widely deployed (for
example, "default www server" and "default irc server") so I strongly
suggest you think carefully about the usability of the option.

Although I can envision several applications beyond emergency response
for location data, I still have trouble understanding how a
[centralized] server can know the precise location of the host without
solving some very difficult configuration issues.  Determining the host
location with sufficient precision for the intended application, then
configuring the server without introducing [transcription] errors, and
finally tracking the location of the host when it is relocated (as often
occurs in commercial or educational settings) is not a minor effort.  A
breakdown in performing any of these tasks invalidates host location and
renders the application marginal or unusable.

This draft seems prone to failure, so I caution that operational and
usage requirements be fully explored before advancing this draft.

--Barr Hibbs

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 08 Dec 2002 10:40:24 -0500

> suggest you think carefully about the usability of the option.

I agree in part. We've gone down this path before (e.g., the SIP 
outbound proxy option). I suspect that this is partially due to the fact 
that in many standard OS, it's basically impossible for a user 
application on a client to get at DHCP data. This is less likely to be 
an issue for embedded devices such as IP phones.

Unfortunately, I don't see a better delivery mechanism. You want 
something that's close to the physical location of the user, so having 
it, say, at the SIP or DNS layer seems counterproductive. (Same with 
ACAP, which would also likely be hosted in the 'home' domain, rather 
than the 'visited' domain.)

> renders the application marginal or unusable.

 From what I've heard about traditional 911/112 services, keeping the 
address database current is not a new problem. This does not imply that 
one should simply say "well, a few addresses are going to be wrong, so 
we won't bother at all".

In this particular case, there can be several mapping mechanisms:

- DHCP relay agents located on switches that know which interface a 
particular DHCP request came in on; any reasonably well-managed system 
will track the current termination point (room) of its LAN infrastructure.

- Some announcement protocol (there are proprietary ones only, as far as 
I can tell) where the client finds out the switch and interface number 
and then conveys that to the DHCP server, which looks into the local 
asset management table

- Manual configuration by MAC address (bad idea if things move and the 
asset database isn't kept up-to-date, but easily implementable).

Compared to the traditional phone system, we have the advantage that 
applications can easily display this information to the user. If the 
user sees a pop-up every week that says "Your emergency response 
location is registered in Room 1234, Main Street, Anytown; if this is 
incorrect, please contact your sys admin immediately" and this isn't 
true, the user may actually do this. (One reason I like civil addresses 
is that users can recognize mistakes in those addresses easily. There's 
not much point in displaying the longitude and latitude to a user for 
confirmation.)

> usage requirements be fully explored before advancing this draft.

I think the failure modes are roughly equivalent for both geospatial and 
civil locations.

Even if the precise room or floor-level location is wrong, the building 
or street address is likely to remain correct.

This is all about probabilities - increasing the probability that an 
emergency caller can be quickly located. There are no certainties here. 
After all, we use maps and phone directories even though we know that 
they have mistakes.

---

From: Carl Reed <[email-masked]>
Date: Sun, 08 Dec 2002 15:20:35 -0700

Two other standards documents that deal with "address" that might be of
interest.

[1] Federal Geographic Data Committee, "Address Data Content Standard -
Public Review Draft", December 2000. This has actually gone through a formal
review process and has moved beyond the draft stage.
[2] ISO/TC 204 N34, "GDF - Geographic Data Files - V4.0", August 23rd 2000.

Regards

Carl Reed, PhD
OpenGIS Consortium

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 08 Dec 2002 21:50:27 -0500

Thanks for the pointers. Any idea how I can get a copy of these 
documents? I indicate Google results below, but these may not be the 
latest or official versions.

> review process and has moved beyond the draft stage.

I found http://www.fgdc.gov/standards/status/sub2_4.html - is that the one?

That document deals, in its specific normative parts (Appendix A), 
primarily with postal addresses. I checked some of the examples (e.g., 
Appendix E), and I think I got those elements that are relevant covered 
in the document. (For example, rural route numbers and PO boxes are for 
postal delivery only, so they should not appear in civil addresses.) Let 
me know if I missed any. (I intentionally left NAM as a single unit, 
since the name in many cases is not going to follow last/first name 
format, plus it is not meant for mail delivery, but identification of an 
office, residence or commercial establishment. What is the first name in 
McDonald's or Taco Bell?)

In terms of civic hierarchy, they seem to stick to the US/Canada model 
of state/provice, county and city.

> [2] ISO/TC 204 N34, "GDF - Geographic Data Files - V4.0", August 23rd 2000.

I found http://www.ertico.com/links/gdf/gdfintro/gdfintro.htm, but this 
seems to be mostly about roads and such.

---

From: Dominic Pinto <[email-masked]>
Date: Tue, 10 Dec 2002 15:02:51 +0000

There are n-centricities to capture .......

Post codes where used can identify, depending on national systems, down
to discrete apartment blocks, groups of dwellings, individual buildings
within large campuses, etc., in urbanized areas. 

The post code, when linked with the national database (which should be
easily available), produces a fairly accurate location / address,
assuming the address is post coded, of course. In principle, the name
and post code should be enough to deliver physical mail to you, and
ensure that people can find you.

However:

1	Not all national systems use such a discriminating system, or indeed
any coding system at all.

2	In practice it appears that at the level of the local delivery office
in the UK the post code is not used for sorting mail in to postal
delivery rounds / routes. 

These are largely traditional routes. For example, where I live between
2 villages, along with 4 other dwellings, these have not reflected local
boundary changes over 40 years ago. In city centres, experience is that
physical location and post codes do not necessarily map onto knowledge
or mapping systems in the Royal Mail or other delivery agents.

It doesn't help when post codes may be advised to users, but the address
does not show up on Royal Mail post code databases some three years
later. These are supplied, and updated, to various large organisations
like insurance companies, or government departments.

3	In terms of physically locating the near neighborhood in my immediate
locality, the post code and address the Royal Mail prefers directs
deliveries and other visitors to either the town of Bicester (some 8
miles distant), or the village of Somerton, about 2 miles distant. The
area is in fact within the parish boundaries of the village of Souldern.

4	In UK Royal Mail usage, the county may seem fairly superfluous
.......... but the Post Town (i.e., the delivery / sorting office for
your locality) often more important, along with the post code. 

There are no doubt many exceptions proving that rule - Durham City in
County Durham being one. The Post Town is Darlington (some 20 miles to
the South), and not used in addresses. 

Name, house name, local area name, city/county (i.e. Durham) and post
code is sufficient for mail to reach you, and visitors to know 'where'
they are.

> US).  Likewise, you may want to add a hierarchy of community name.

Certain national regions, countries, dependencies may usefully be
provided for - e.g. England, Wales, Scotland, Northern Ireland, Jersey -
to suit local sensitivities and assist (particularly in border areas) in
location.

> (yes this is their real postal address sans postal code):

The north bank of the river Humber is now, I think, in the County of
East Yorkshire, the County of Humberside (north and south banks of the
river extending some way inland, and the city of Kingston upon Hull)
having been split up in recent years.

-- 
Dominic Pinto
-------------
					| Barn Cottage, Hill House
Senior Associate Telesphere Limited	| Somerton Road, 
					| between Souldern & Somerton
http://www.telespherelimited.com	| Bicester, Oxon, OX25 6LS, UK	
----------------------------------------------------------------------
Ph/Fax: +44 1869 346375 Cellphone/GSM Mobile: +44 780 302 8268
----------------------------------------------------------------------

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 10 Dec 2002 10:44:03 -0500

> within large campuses, etc., in urbanized areas. 

Before we go down the postal service rathole: my draft explicitly does 
*not* attempt to provide a means for the post office to deliver 
postcards and catalogues to my IP phone, laptop, router or PC, as much 
as my router might enjoy reading about getting new memory or a new 
interface card.

> ensure that people can find you.

For additional evidence, I suggest you subscribe to the NENA mailing 
list or look at its archives (http://www.nena.org), where this was 
discussed at length. At least in the rural areas in the US, there is 
often very little correlation between the postal and the physical 
(civil) address. I had asked for examples and got the indication that it 
is quite common that somebody lives, votes and pays taxes in Mainville 
but has to put Othertown on his return address if he wants to receive 
postal mail, since the post office serving the community is in 
Othertown. Indeed, there are apparently civil localities that are served 
by multiple post offices, so that different parts of the citizenry has 
to put different addresses on the envelope.

I'd be happy to provide examples that I was given if you consider this 
to be too weird to be true :-).

> any coding system at all.

That's why the postal code is optional and insufficient for locating 
things in the physical world.

> your locality) often more important, along with the post code. 

Again, we're not trying to deliver mail here, but get the ambulance (or 
technician) to the device (and the person standing next to it). I've 
included the postal code primarily since it provides an additional hint 
and may offer a sanity check.

---

From: Barr Hibbs <[email-masked]>
Date: Thu, 12 Dec 2002 20:07:15 -0800

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Sunday, December 08, 2002 07:40

> ... an observation that few DHCP options intended for
> application configuration have ever been widely deployed
> (for example, "default www server" and "default irc server")
> so I strongly suggest you think carefully about the usability
> of the option.

... in many standard OS, it's basically impossible for a user
application on a client to get at DHCP data. This is less likely
to be an issue for embedded devices such as IP phones.

[rbh] if this functionality [allowing an application to easily access
DHCP option data] is either required [by legislation or regulation] or
desired [for product differentiation or other marketing or service
reasons] it will be implemented.

[rbh] it's a fallacious assumption that a DHCP server is at all "close"
to the physical location of the user.  I know of several private
networks where the DHCP server is hundreds or thousands of miles from
the DHCP clients it serves.  Because of the possibility of intervening
relay agents between a client and server, the two aren't necessarily
"close" in terms of subnetwork addresses.

[rbh] yes, E911 services have issues with the correctness of their data,
but consider the source:  nearly all are based primarily on the Service
Address of the Local Exchange Carrier's Customer Records system.  These
typically are no more than a street address and [possibly] unit number.
Still, emergency services crews are dispatched based on this information
and usually are able to locate the person who initiated a response, even
when a cordless phone is used.

I mention cordless phones as a way of introducing the nagging issue of
actually knowing where the phone is located.  Recall that in the United
States, at least, the user is responsible for installing and maintaining
the "inside wire" between the Minimum Point of Entrance and wherever the
telephone set is actually located.  The actual location could be in
another building, at a different street address from the listed Service
Address.  The situation is somewhat better in businesses and commercial
installations, but the quality of location information is not perfect.

- DHCP relay agents located on switches that know which interface a
particular DHCP request came in on; any reasonably well-managed system
will track the current termination point (room) of its LAN
infrastructure.

[rbh] perhaps in some environments, but most commercial installations I
know simply do not bother recording the complete details of a
connection.  Switch or hub ports are often just extraneous information
because they are largely interchangeable.

[rbh] I'll acknowledge the possibility of a discovery or announcement
protocol supplying information about it's resources used for a
particular physical connection, possibly even associating that with a
logical connection (IP address and port numbers) -- which is potentially
useful in a number of contexts (security, access controls, environmental
controls, quality of service management, etc.), but I will strongly
object in the DHC Working Group to any requirement that a DHCP server
implementation have a specific configuration behavior.  Historically,
the means and methods for configuring a server are specifically "out of
scope" with respect to the protocol definitions, and I cannot see that
changing.

[rbh] I supervised a configuration management group in an organization
that had tens of thousands of DHCP clients.  In our experience, the
number of incremental moves, adds, and changes was approximately 10% of
the installed base per month.  I submit that such churn is not an
exception, but likely to be the norm in a large, widely distributed
organization.

[rbh] agreed, in some IP phones (but certainly not all!)  Civil
addresses are essential for routing emergency services personnel, and
people are generally pretty well adapted to resolving ambiguities and
errors in them, especially if corroborating information is available
such as "cross street" or "between."

[rbh] I agree with this point and the remaining ones that you made, but
perhaps I didn't state my fear correctly.  The failure will likely not
come from using the information in an emergency, but rather the
administrative issues for initially configuring the data for the server
and then for maintaining it.  I assert that much of the information
about location of a device is simply not recorded, not reported, and
unlikely to be kept up to date in most circumstances.  This may not be
much of a practical impediment to the use of the data in most
circumstances (paramedics responding to a suspected heart attack in an
office building will likely find the victim as long as they get to the
right floor because of local "guides" who await their arrival, for
instance) but there are corner cases where lack of sufficient precision
is a serious flaw (imagine the heart attack victim after hours, with no
one else nearby to guide the paramedics -- in this case, the imprecision
can be fatal!)

It's the data capture, data entry, and data maintenance issues that
worry me, especially if cordless phones or extreme displacement of the
tel set due to exceptionally long cords is considered.

--Barr

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 13 Dec 2002 09:18:26 -0500

> reasons] it will be implemented.

I also since found that the ISC DHCP software has a new API, called 
OMAPI. It apparently allows object-retrieval access to the local DHCP 
database, although it is unclear to me whether this applies to the 
server side or the client side or both. If somebody else knows more 
details, I'd appreciate hearing about your experiences.

> "close" in terms of subnetwork addresses.

They are at least likely to be run by the same network administrator, 
which isn't true for DNS, ACAP and SIP, to pick a few examples. If you 
know some other mechanism, I'm very interested. (There are better 
solutions, such as port-based broadcast approaches, but they are not 
standardized at all and are barely documented. Examples include CDP 
[Cisco] and EDP [Extreme Networks].)

Having the network admin determine location is about the only reasonable 
approach. Yahoo! or my SIP provider has no clue and has no mechanism to 
reach into my network attachment point.

> when a cordless phone is used.

This happens to be very close to the information that's in my draft, so 
I don't understand your comment.

> installations, but the quality of location information is not perfect.

All true, but this just shows that even the PSTN, with a much simpler 
wiring structure, has issues, so it's unrealistic to expect perfection 
in the IP network.

> because they are largely interchangeable.

At least three large universities that I'm familiar with (first hand or 
through a paper by Deep Medhi and his students at UMKC) do track jack 
locations. These include University of Missouri Kansas City, Columbia 
University and the University of Kentucky.

Also, there are probably two sub-cases:

- states where local law requires tracking PBX phone locations within a 
large enterprise (there are about half a dozen and there may eventually 
be an FCC regulation; see the APCO web site for details)

- other states

In the former category, anybody installing a VoIP system will have no 
choice but to get his house in order.

> scope" with respect to the protocol definitions, and I cannot see that

I have no intent to tell anybody what magic, crystal ball, divining rod 
or database they should use to populate this data. I'm just providing 
examples. No different than any other DHCP data.

> exception, but likely to be the norm in a large, widely distributed

That's why I said it's a bad idea :-)

> such as "cross street" or "between."

As usual, we can try to cover as many as possible. In some cases, this 
isn't necessary (small business where, say, the SIP outbound proxy 
server can know the location with confidence, since all devices are 
going to be in one office - I'm assuming no dial-in or VPN into this 
network), in others, it's not feasible.

Are you suggesting we shouldn't try since it isn't going to be feasible 
in 100% of the cases?

> one else nearby to guide the paramedics -- in this case, the imprecision

Rest assured, the first lawsuit of the family of the poor victim will 
send sys admins scrambling to record the correct information of every 
jack in the place :-)

As I said, this isn't a new problem. At least in some jurisdictions, 
they'll have to do it for PBX exensions. (Speaking from local 
experience, we have a large number of PBX patch panel location where 
nobody knows where the the wire ends up. The only way to find out would 
be to dial all 200 numbers until the phone rings. It's a little easier 
with a modern Ethernet installation - plug in laptop, fire up Ethereal 
and within one minute, you have the switch port.)

> tel set due to exceptionally long cords is considered.

I'm a little confused by this statement. I don't see how we can fix this 
problem, but that doeesn't detract from the general usefulness of 
address databases. Let me state what I think our common assumptions are:

- Locating emergency callers within a large campus or building is 
important, regardless of technology.

- In some jurisdictions, this is mandated by law, regardless of whether 
the communications device is using analog wires or IP packets.

- In all cases, the information has some probability to be somewhat 
wrong (in other words, some pieces may well be right); the important 
consideration is *expected* (average) time to find the caller. This is 
one reason I provide the different options of what location is being 
declared, so that the receiver of that information can make an educated 
guess of what to trust. (Switches and DHCP servers don't move nearly as 
often as PCs and IP phones and are more likely to be moved by sys admins 
rather than users.)

- We don't want to tell people how to populate such databases, as the 
mechanisms vary. (If at all, these types of issues are probably better 
handled by organizations such as NENA or TIA, since that's their bailiwick.)

- We don't want to tell people how to implement user interfaces.

- We need a mechanism that's run by either the L2 or L3 service 
provider, not the application service provider.

I'd be glad to receive additional wording that you would find helpful in 
the draft to clarify any issues. I don't think I want to get too deeply 
into operational issues since at least my wording would be likely no 
more useful than the "keeping track of network devices or jacks is a 
pain, get used to it".

---

From: Marc Linsner <[email-masked]>
Date: Fri, 13 Dec 2002 14:23:10 -0500

comments in-line

> reach into my network attachment point.

[ml] DHC is one place to perform this function, but I think 802.1X would
ALSO be a good place to convey location information to a hardwired host.  I
believe both mechanisms (DHC & 802.1X) should provide this capability (using
the same location object).  This would give implementors the choice that
would fit their individual needs.

> I don't understand your comment.

[ml] IP Telephony exacerbates the emergency responders dilemma of finding
the person in need.  The antiquated mechanism in use in today's PSTN/ALI
update process (24 hour average update time) would never even begin to
support the mobility afforded to a hardwired IP telephone device, not to
mention the wireless device.  We are trying to accomodate the hardwired
devices only, wireless obviously has other issues to deal with.  Our hope is
that the location object would fit all environments, one just needs to
change the discovery mechanism.

> choice but to get his house in order.

[ml]If the netheads want to assume the responsibility of the bellheads, they
will have to conform to rules and regs that govern the bellheads.  Most PBX
admins know with reasonable accuracy where their ports are connected to.
Most Net admins don't care.  Convergence means the best and worst of both
worlds.

> send sys admins scrambling to record the correct information of every

[ml]Alternative - Keep your phone system on the TDM PBX and keep the current
admin staff for that environment!

-Marc Linsner-

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 13 Dec 2002 14:31:09 -0500

> would fit their individual needs.

Do you know if IEEE 802 is willing to consider this? I agree that this 
would be a nice solution.

> Most Net admins don't care.  Convergence means the best and worst of both

Our net admins have started to care, usually after some host gets broken 
into and starts a DOS attack. They want to know quickly which power plug 
needs to be pulled.

---

From: Marc Linsner <[email-masked]>
Date: Fri, 13 Dec 2002 15:26:10 -0500

> would be a nice solution.

I think its more of an EAP issue.

-Marc Linsner-