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

["Brian Rosen" <[e-mail]>]

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

> -----Original Message-----
> From: [e-mail] [mailto:sipping-emergency-
> [e-mail]] On Behalf Of [e-mail]
> Sent: Wednesday, September 29, 2004 7:28 AM
> To: Peterson, Jon; Jonathan Rosenberg
> Cc: Marc Linsner; [e-mail]
> 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
> 
> 	-----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