John Morris | 3 Dec 22:21 2002

Comments on draft-cuellar-geopriv-scenarios-02.txt??

Jorge Cuellar, Go Kanai, and I are going to do another revision of 
draft-cuellar-geopriv-scenarios-02.txt, and we would greatly 
appreciate any and all comments, either to the list or (if the 
comments are small) directly to me at jmorris <at> cdt.org.

We really want to make sure that we have covered a broad enough range 
of scenarios in which the Location Object must work.  I hope everyone 
can read the draft carefully -- BUT, even if you cannot, PLEASE do 
look over the specific diagrammed scenarios (pages 22 - 30 of the 
draft) and let the list (or me) know about important scenarios that 
are not covered.

At the WG meeting in Atlanta a couple of weeks ago, we discussed 
whether this document should become a WG internet-draft.  I don't 
believe anyone raised any objection in Atlanta (and at least a few of 
us thought it was a good idea), but the entire list should consider 
and if needed discuss that question.

(The same goes for draft-danley-geopriv-threat-analysis-00.txt, which 
I believe Michelle Danley, Jon Peterson, et al., will revise.  The WG 
charter calls for a threats document, and in Atlanta we discussed, 
without objection, turning the Danley draft into a WG document.)

Send comments!

John
--------------------------------------------------
John Morris // CDT // http://www.cdt.org/standards
--------------------------------------------------

(Continue reading)

Michelle E. Danley | 3 Dec 21:24 2002
Picon

Re: draft-danley-threat-analysis-00.txt

I tried to send this out last week, but I think it got lost somewhere in the void.
 
We are working on the next draft of this document and we're interested in any comments-- large or small-- that you may have on the document.  We are particularly interested in compiling a fairly complete list of threats, so if you spot any threats that are not currently in the document, please let us know.
 
Thanks,
 
Michelle Danley
 
Henning Schulzrinne | 5 Dec 19:32 2002

DHCP options for civil locations

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

Rohan Mahy | 6 Dec 23:13 2002
Picon

Re: DHCP options for civil locations

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:

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

Henning Schulzrinne | 7 Dec 00:17 2002

Re: DHCP options for civil locations

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.

Rohan Mahy wrote:
> 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  

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.

> 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

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

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

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.

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

Barr Hibbs | 8 Dec 10:40 2002
Picon

RE: DHCP options for civil locations


-----Original Message-----
From: Henning Schulzrinne [mailto:hgs <at> cs.columbia.edu]
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

Henning Schulzrinne | 8 Dec 16:40 2002

Re: DHCP options for civil locations

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

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

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

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

> 
> This draft seems prone to failure, so I caution that operational and
> 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.

> 
> --Barr Hibbs
> 

Carl Reed | 8 Dec 23:20 2002
Picon

Re: DHCP options for civil locations

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

----- Original Message -----
From: Rohan Mahy <rohan <at> cisco.com>
To: Henning Schulzrinne <hgs <at> cs.columbia.edu>
Cc: <geopriv <at> mail.apps.ietf.org>
Sent: Friday, December 06, 2002 3:13 PM
Subject: Re: DHCP options for civil locations

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

Henning Schulzrinne | 9 Dec 03:50 2002

Re: DHCP options for civil locations

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.

Carl Reed wrote:
> 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.

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.

> Regards
> 
> Carl Reed, PhD
> OpenGIS Consortium
> 

Dominic Pinto | 10 Dec 16:02 2002
Picon

Re: DHCP options for civil locations

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.

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

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.

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

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


Gmane