Subject: RE: [Sipping-emergency] RE: Civil location syntax validation - was RE: How to handle Validation failures

From: [email-masked]
Date: Wed, 29 Sep 2004 07:27:33 -0400

Validation of location information should only occur once. This happens, in the case of a DHCP assigned location [draft-ietf-geopriv-dhcp-civil-03], before the device ever retrieves the information. I am not proposing a contiuous ping of location information against a validation database from the device itself. Routing information could routinely be tested in the absence of any device actually having location associated with it. This could be a random selection of pre-validated locations using known routes to the ERC from different origination points (to the extent possible - perhaps a test to end point where a device MAY reside and then a test to ECC from the same testing origination point using LO based routing information). The only time that the location gets delivered is in the event of an emergency call and then only once and only to the ECC. Of course, for mobility this would be different as continuous updates should occur during an emergency call based on geo loc only. 
 
Recontact information should only be sent during emergency calls as well. Personal information to the extent possible may never be sent.
 
Nate

	-----Original Message----- 
	From: Peterson, Jon [mailto:[email-masked]] 
	Sent: Wed 9/29/2004 3:34 AM 
	To: 'Jonathan Rosenberg' 
	Cc: 'Marc Linsner'; [email-masked] 
	Subject: RE: [Sipping-emergency] RE: Civil location syntax validation - was RE: How to handle Validation failures

	Privacy concerns are one aspect of the authorization problem, sure. A lot of
	it depends on what sort of information is exchanged in the routing query.
	Realistically, I think that the revelation of the existence or non-existence
	of an address does not intrinsically have privacy implications. Proximity of
	addresses to one another is also, I believe, public information I could get
	from Yahoo! Maps or Mapquest or something, and is not intrinsically a source
	of privacy leakage. On the other hand, if you can use it to determine the
	name of the family that lives at a particular address, or something, then
	that's problematic.
	
	Either way, I suspect that there will probably be a business model
	associated with validation, and that people won't want to validate your
	address gratis at will. As such, I imagine that there may be some
	authorization policies surrounding all of this irrespective of privacy
	anyway.
	
	Of course, it makes sense to have some privacy text in the charter. It's
	easier for me to see how a route query outside the context of validation
	(for a real emergency call) has privacy implications. If validation is
	essentially indistinguishable from validation, then the protocol will have
	to provide the some privacy tools for both.
	
	Jon Peterson
	NeuStar, Inc.
	
	> -----Original Message-----
	> From: Jonathan Rosenberg [mailto:[email-masked]]
	> Sent: Tuesday, September 28, 2004 8:04 PM
	> To: Peterson, Jon
	> Cc: 'Brian Rosen'; 'Marc Linsner'; [email-masked]
	> Subject: Re: [Sipping-emergency] RE: Civil location syntax
	> validation -
	> wa s RE: How to handle Validation failures
	>
	>
	> inline.
	>
	> Peterson, Jon wrote:
	>
	> > So, just to make sure I understand, validation uses the same network
	> > operation, basically, that would be used for a route query?
	> >
	> > Agreed that it should be possible for a route query to
	> return 'I didn't
	> > understand your address format', 'I understand your address
	> and it isn't
	> > actually valid', and so on beyond just the sunny-day case
	> of returning the
	> > route. Also, plus or minus some authorization and
	> operational issues, I
	> > agree that an ordinary user should be able to launch this
	> sort of query
	> > outside the context of an emergency call.
	>
	> I'm not so sure of that.
	>
	> It seems that there is a lot of very useful information in
	> this database
	> - which addresses exist, which do not, and information on the
	> relative
	> proximity of civil addresses to each other (two addresses that map to
	> the same ERC would be "close" in some way). As a result, I feel that
	> there are probably privacy implications of allowing worldwide open
	> access to this database. Seems like it would be mined by spammers to
	> validate mailing addresses, and used for all sorts of other nefarious
	> purposes.
	>
	> Along those lines, I think it might be a good idea to
	> sprinkle some nice
	> words into the charter about taking into consideration
	> privacy concerns,
	> and properly balancing them with the needs of emergency call routing.
	>
	> -Jonathan R.
	>
	> --
	> Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
	> Chief Technology Officer                    Parsippany, NJ 07054-2711
	> dynamicsoft
	> [email-masked]                     FAX:   (973) 952-5050
	> http://www.jdrosen.net                      PHONE: (973) 952-5000
	> http://www.dynamicsoft.com
	>
	
	_______________________________________________
	Sipping-emergency mailing list
	[email-masked]
	https://www1.ietf.org/mailman/listinfo/sipping-emergency

_______________________________________________
Sipping-emergency mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-emergency

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 29 Sep 2004 08:45:47 -0400

I think it should be POSSIBLE for a user at a UA to determine if the address
he has is valid.  Normally, the address will come from a source that is
pretty reliable, assuming you trust the last mile provider, and should be
validated prior to use.  Since there are many such last mile providers, and
quite a few "Master Street Address Guides" a standardized mechanism is
required.

Jon is correct; all we need is an error return from the mechanism that
determines route from location.  Again, since there are multiple entities
that need to get this information, and multiple entities that supply the
information, a protocol is needed. 

I agree that privacy concerns are real, and should be mentioned in the
charter. 

James' concern about location reported in geo is easily dealt with.
The point of validation is to make sure that the reported location is
dispatchable - a responder can be directed to that location and will be able
to find the person in need of help.  Geospatial coordinates are precise,
with no ambiguity of the sort that gives rise to the validation concern for
civic addresses.  To be sure, you have to convert geo to civil to do the
dispatch, which is yet another problem I think we must solve, and that
conversion must be accurate enough to yield a valid civic address, but for
the purposes of this discussion, a location reported in geo form does not
need to be validated.

Brian

> From: [email-masked] [mailto:sipping-emergency-
> [email-masked]] On Behalf Of [email-masked]
> Sent: Wednesday, September 29, 2004 7:28 AM
> To: Peterson, Jon; Jonathan Rosenberg
> Cc: Marc Linsner; [email-masked]
> Subject: RE: [Sipping-emergency] RE: Civil location syntax validation -
> wasRE: How to handle Validation failures
> 
> Validation of location information should only occur once. This happens,
> in the case of a DHCP assigned location [draft-ietf-geopriv-dhcp-civil-
> 03], before the device ever retrieves the information. I am not proposing
> a contiuous ping of location information against a validation database
> from the device itself. Routing information could routinely be tested in
> the absence of any device actually having location associated with it.
> This could be a random selection of pre-validated locations using known
> routes to the ERC from different origination points (to the extent
> possible - perhaps a test to end point where a device MAY reside and then
> a test to ECC from the same testing origination point using LO based
> routing information). The only time that the location gets delivered is in
> the event of an emergency call and then only once and only to the ECC. Of
> course, for mobility this would be different as continuous updates should
> occur during an emergency call based on geo loc only.
> 
> Recontact information should only be sent during emergency calls as well.
> Personal information to the extent possible may never be sent.
> 
> Nate
> 
> 	Subject: RE: [Sipping-emergency] RE: Civil location syntax
> validation - was RE: How to handle Validation failures
> 
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 29 Sep 2004 09:48:05 -0400

> the purposes of this discussion, a location reported in geo form does not

In some cases, it is helpful if the user can easily do a sanity check on 
the geo location. It is useful to know if my current geo location puts 
me, due to some technical error like a big-endian/little-endian snafu or 
a confusion of longitude and latitude, in Africa instead of New York.