Re: [dispatch] draft-winterbottom-dispatch-locparam

To correct one error. In item 1) 1st sentence "additional header field" should be "additional header field parameter"

Keith

> -----Original Message-----
> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf 
> Of DRAGE, Keith (Keith)
> Sent: 22 July 2015 16:30
> To: dispatch@ietf.org; Cullen Jennings
> Subject: Re: [dispatch] draft-winterbottom-dispatch-locparam
> 
> I've now read all the versions of meeting notes distributed.
> 
> None of these expand on Cullen's privacy concern, so perhaps 
> he could elaborate.
> 
> I would state that:
> 
> 1)	the trust statements in the document relate only to the 
> additional header field. The privacy requirements on the 
> remainder of the Geolocation header field are unchanged.
> 
> 2)	for SIP deployments that use trust, neither the trust 
> nor the entities involved in that trust are the same for 
> every header field. So the trust for RFC 3325 is: a) on the 
> sender to trust that the recipient to apply any "id" privacy 
> indicated; b) on the recipient that they trust the sender to 
> assert the identity. For this draft, the only trust required 
> is that the receiver trusts the sender to assert that the new 
> header field parameter was applied by a "originating 
> telephony or electronic communications service provider".
> 
> 3)	I do not believe there is any privacy issue about the 
> recipient receiving information that any contained 
> Geolocation header field came from a "originating telephony 
> or electronic communications service provider" as opposed to 
> anywhere else. If there is, then the trust requirements could 
> be altered in the same manner as already used for a number of 
> 3GPP specific header fields.
> 
> Keith
> 
> > -----Original Message-----
> > From: DRAGE, Keith (Keith)
> > Sent: 22 July 2015 10:17
> > To: dispatch@ietf.org
> > Subject: draft-winterbottom-dispatch-locparam
> > 
> > Issues from the dispatch meeting discussion:
> > 
> > 1)	In regard to trust, what is needed is a mechanism to 
> > meet the following from the EC mandate:
> > 
> > ". The enhancement, i.e. location data provision, is expected to be 
> > determined by the originating telephony or electronic 
> communications 
> > service provider, capable of originating voice calls 
> through a number 
> > or numbers in national telephone numbering plans, and be 
> provided at 
> > call setup to the PSAP as soon as the call reaches the authority 
> > handling the emergency calls."
> > 
> > The proposal in the document is that the recipient of a SIP request 
> > will either know that the entity that sent or proxied the 
> SIP request 
> > is either an "originating telephony or electronic communications 
> > service provider" or trusts that entity to make a proper 
> > discrimination of that.
> > 
> > Relying on certificates or known domain names would require 
> PSAPs and 
> > networks routeing emergency calls to have a maintained 
> database of all 
> > known "originating telephony or electronic communications service 
> > provider" worldwide.
> > 
> > 2)	The question was raised as to whether it should be 
> > specific for emergency call. I see no reason why it should 
> be. It does 
> > not interfere with the location itself, or the privacy of 
> the location 
> > itself. Further, I have a concern of any protocol mechanism that is 
> > emergency call specific, as it never gets tested until one wants to 
> > make an emergency call.
> > 
> > 3)	I believe Cullen mentioned privacy, but I am not sure 
> > in what context. The mechanism does not interfere with any of the 
> > privacy requirements defined for the Geolocation header 
> field. Further 
> > if the trust in 1) above is not met, it is only the 
> parameter that is 
> > removed, not the Geolocation header field itself.
> > 
> > Regards
> > 
> > Keith
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
> 