Subject: RE: [Ecrit] Proposed Requirement

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 19 Oct 2005 19:32:07 -0500

Hi Marc,

Thank you for your response.
If what you propose below is true, and that the LCMS is not a location
recipient in the sense of RFC-3693, I am assuming that no-association
between location and the user must be possible. Can you confirm this?
If this is the case then it really needs to be a requirement in Roger's
draft, otherwise the argument does not carry the weight that you
purport.

Further to this, if the PIDF-LO contains a ruleset or ruleset URI, the
proxy MUST not provide the location information to the LCMS unless the
ruleset indicates that it is okay. This is exactly the same basis for
location being provided for location-by-reference, so if it is okay to
do this for by-value, then it MUST be okay to do it for by-reference.

A note of warning, if the LCMS MUST not be able to associate location
with user identity, then sending a PIDF-LO to the LCMS where the value
for the presentity parameter is traceable to the user's true identity
will be not acceptable. This implies that the proxy will need to
understand this.

Cheers
James

> -----Original Message-----
> From: Marc Linsner [mailto:[email-masked]]
> Sent: Tuesday, 18 October 2005 11:28 PM
> To: Winterbottom, James; 'Tom-PT Taylor'
> Cc: [email-masked]
> Subject: RE: [Ecrit] Proposed Requirement
> 
> James,
> 
> I believe we need to view the VSP, the LCMS service, and the PSAP as
three
> separate entities with no relationship between them.  I also agree
with
> you
> that in *some* cases, the PSAP will be the entity that operates the
LCMS,
> but from an architectual point of view, I don't believe we should
depend
> on
> that in 100% of the cases.  Therefore, we cannot make assumptions that
> privacy rules, as determined by the rule-maker with respect to a PSAP,
can
> be extended to the LCMS service.
> 
> I believe it's reasonable to view the LCMS service simply as an 'aid'
to
> the
> session initiation process, similar to a 'dial plan'.  With this view,
the
> LCMS service will simply match location data to a URI, and will not be
a
> true Location Recipient as defined in RFC3693 (no user identified,
etc.).
> This obviously needs further discussion within the GeoPriv realm as we
> work
> through the ecrit protocol.
> 
> So, dereference any location-by-reference prior to submitting to the
LCMS
> service, the protocol is easy, quick, clean and covers all cases.
> 
> Thanks,
> 
> -Marc-
> 
> 
> > -----Original Message-----
> > From: Winterbottom, James [mailto:[email-masked]]
> > Sent: Monday, October 17, 2005 7:33 PM
> > To: Marc Linsner; Tom-PT Taylor
> > Cc: [email-masked]
> > Subject: RE: [Ecrit] Proposed Requirement
> >
> > Hi Marc,
> >
> > I understand the argument, and I think that it is well put in
> > that sense.
> > If the VSP has to do the locationURI dereference and pass the
> > location to the lcms then short of the VSP being a B2BUA and
> > inserting the location into the SIP body, access to location
> > from a PSAP will be required via the locationURI anyway.
> >
> > Do you see that the lcms are likely to be operated by the
> > PSAPs, or at the very least have the services contracted to
> > them by the PSAPs? If so then I don't see why the suggested
> > authority can't be delegated in this situation. My point here
> > to is that if you make a call and do not have a relationship
> > with a VSP, it is likely that the only rule you can apply is
> > to the lcms or PSAP. So I think that it is still necessary to
> > allow the lcms to accept a location-by-reference in place of
> > a location-by-value.
> >
> >
> > Cheers
> > James
> >

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 20 Oct 2005 09:50:45 -0400

James,

Comments in-line.... 

> If what you propose below is true, and that the LCMS is not a 
> location recipient in the sense of RFC-3693, I am assuming 
> that no-association between location and the user must be 
> possible. Can you confirm this?

Ecrit has yet to figure out what information a LCMS client will submit to a
LCMS server.  What I am asserting is user information is certainly not
needed for LCMS to perform the requested task, matching location information
to uri.

> If this is the case then it really needs to be a requirement 
> in Roger's draft, otherwise the argument does not carry the 
> weight that you purport.

I don't feel we (I) know enough to make this a requirement, yet.  I'd like
more opinions on the subject of what information is required at the LCMS
server.

> 
> Further to this, if the PIDF-LO contains a ruleset or ruleset 
> URI, the proxy MUST not provide the location information to 
> the LCMS unless the ruleset indicates that it is okay.

This is what causes heartburn.  If Joe User simply 'forgets' to include the
LCMS in his ruleset (unaware that such a service is necessary to complete
emergency calling), then his attempts to complete a properly-routed call
will fail.  So my question, is the act of matching just location (no
user/host identity) to uri a breach of RFC-3693?  I don't believe so, there
is nothing interesting about 123 Main St. equals [email-masked].

 This 
> is exactly the same basis for location being provided for 
> location-by-reference, so if it is okay to do this for 
> by-value, then it MUST be okay to do it for by-reference.

Location-by-value does not equal pidf-lo.  I think this is the point I'm
attempting to make: If you expect the LCMS server to dereference a
location-by-reference, the LCMS server MUST be in the ruleset.
Alternatively, if the proxy (LCMS client) performs dereference and uses only
the location-by-value data (no user identity) then the LCMS server does not
fall under the definition of location-recipient spelled out in RFC-3693.
Obviously, if Joe User forgets to include his proxy in the ruleset, then the
proper call-routing will fail as the proxy cannot dereference the LBR.

> 
> A note of warning, if the LCMS MUST not be able to associate 
> location with user identity, then sending a PIDF-LO to the 
> LCMS where the value for the presentity parameter is 
> traceable to the user's true identity will be not acceptable. 
> This implies that the proxy will need to understand this.

Again, the pidf-lo contains way more data than necessary for LCMS to perform
it's task, IMO.

Thanks,

-Marc-

> > work through the ecrit protocol.
> > 
> > > I understand the argument, and I think that it is well 
> put in that 
> > > sense.
> > > inserting the location into the SIP body, access to 
> location from a 
> > > PSAP will be required via the locationURI anyway.
> > >
> PSAPs, or 
> > > at the very least have the services contracted to them by 
> the PSAPs? 
> > > If so then I don't see why the suggested authority can't be 
> > > delegated in this situation. My point here to is that if 
> you make a 
> > > call and do not have a relationship with a VSP, it is likely that 
> > > the only rule you can apply is to the lcms or PSAP. So I 
> think that 
> > > it is still necessary to allow the lcms to accept a 
> > > location-by-reference in place of a location-by-value.
> > >
> > >
> > > Cheers
> > > James
> > >
>