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

[[e-mail]]

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:[e-mail]] 
	Sent: Wed 9/29/2004 3:34 AM 
	To: 'Jonathan Rosenberg' 
	Cc: 'Marc Linsner'; [e-mail] 
	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:[e-mail]]
	> Sent: Tuesday, September 28, 2004 8:04 PM
	> To: Peterson, Jon
	> Cc: 'Brian Rosen'; 'Marc Linsner'; [e-mail]
	> 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
	> [e-mail]                     FAX:   [phone]
	> http://www.jdrosen.net                      PHONE: [phone]
	> http://www.dynamicsoft.com
	>
	
	_______________________________________________
	Sipping-emergency mailing list
	[e-mail]
	https://www1.ietf.org/mailman/listinfo/sipping-emergency
	
	
	

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