Subject: RE: [Ecrit] Proposed Requirement

From: "Winterbottom, James" <[email-masked]>
Date: Mon, 17 Oct 2005 18:32:30 -0500

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

> -----Original Message-----
> From: Marc Linsner [mailto:[email-masked]]
> Sent: Monday, 17 October 2005 10:48 PM
> To: Winterbottom, James; 'Tom-PT Taylor'
> Cc: [email-masked]
> Subject: RE: [Ecrit] Proposed Requirement
> 
> James,
> 
> This may be more of an argument for geopriv as the motivation stated
for
> this requirement, IMO, lines up with RFC3693.  I'm not sure I agree
(nor
> does RFC3693) that all lcms servers should have 'carte blanche' access
to
> anyone's location data on every LIS globally.  Of course, the
rulemaker
> could have a rule that '*.lcms.net' (or similar) has all access, which
I
> see
> as unlikely.  I do see the entity in front (in terms of making an
> emergency
> call) of the lcms server as being closer to the rulemaker and more
likely
> to
> have access to the target's location data (i.e. ability to resolve
> location-by-reference), since this entity is most likely to be the
> rulemaker's contracted/controlled/well-known VoIP provider (in the
case of
> emergency voice calls).  Hence, I believe that only
known-to-the-rulemaker
> entities should be resolving location-by-reference into
location-by-value.
> 
> Thoughts?
> 
> -Marc-
> 
> > -----Original Message-----
> > From: Winterbottom, James [mailto:[email-masked]]
> > Sent: Tuesday, September 20, 2005 7:18 PM
> > To: Tom-PT Taylor; Marc Linsner
> > Cc: [email-masked]
> > Subject: RE: [Ecrit] Proposed Requirement
> >
> > I could not disagree more with this requirement!
> >
> > The Mapping service by its very virtue of providing
> > destination routing information based on location grants it
> > the very trust that is being argued below that it does not
> > have. Further to this, the mapping functions are in most
> > cases likely to be in the best position to have this trust
> > placed on them. I see the argument raised for having this
> > requirement as being moot.
> >
> > A mapping function MUST be able to accept either a
> > location-by-reference (preferred in the mobile case), or
> > alternatively by-value, preferably if the source can be verified.
> >
> > Cheers
> > James
> >
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > [mailto:[email-masked]] On Behalf
> > Of
> > > Tom-PT Taylor
> > > Sent: Tuesday, 20 September 2005 12:06 AM
> > > To: Marc Linsner
> > > Cc: [email-masked]
> > > Subject: Re: [Ecrit] Proposed Requirement
> > >
> > > I like it.
> > >
> > > Marc Linsner wrote:
> > > > A proposed new requirement for the 'almost finished' req.
> > draft.....
> > > >
> > > > Requirement: The ecrit mechanism will only deal with location
data
> > in
> > > value
> > > > form, any location by-reference or location-key MUST be
> > resolved to
> > a
> > > > location by-value prior to query submission to the
> > mapping database.
> > > >
> > > > Motivation: It cannot be expected that the entities
> > considered to be
> > > 'the
> > > > mapping database' (accepting the queries and returning a
> > resolution)
> > of
> > > the
> > > > location mapping-to-uri function be part of any trust or
> > authentication
> > > > mechanism that may be required to resolve location
> > > > by-reference/location-key.
> > > >
> > > >
> > > > This requirement spurs the need to define location by-reference,
> > > > location-key and location by-value in section 2 - Terminology.
> > > Hence....
> > > >
> > > > Location by-reference: A URI that when accessed by an authorized
> > entity
> > > will
> > > > yield the location of the end-point to which the reference is
> > > associated.
> > > >
> > > > Location-Key: A mechanism used to provide a reference to
> > a location.
> > > This
> > > > may be a URI, a URL or some other kind of identifier.
> > > >
> > > > Location by-value: The location data in it's native form (see
> > location).
> > > >
> > > >
> > > > Fire-away,
> > > >
> > > > -Marc-
> > > >
> > > > _______________________________________________
> > > > Ecrit mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/ecrit
> > > >
> > > >
> > >
> > >
> > > _______________________________________________
> > > Ecrit mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/ecrit
> >
> > --------------------------------------------------------------
> > ----------------------------------
> > 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]

------------------------------------------------------------------------------------------------
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: Tue, 18 Oct 2005 09:28:00 -0400

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- 

> Sent: Monday, October 17, 2005 7:33 PM
> To: Marc Linsner; Tom-PT Taylor
> Cc: [email-masked]
> 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
> 
> > > The Mapping service by its very virtue of providing destination 
> > > routing information based on location grants it the very 
> trust that 
> > > is being argued below that it does not have. Further to this, the 
> > > mapping functions are in most cases likely to be in the best 
> > > position to have this trust placed on them. I see the argument 
> > > raised for having this requirement as being moot.
> > >
> > > [mailto:[email-masked]] On Behalf Of
> > > > Tom-PT Taylor
> > > This message is for the designated recipient only and may contain 
> > > privileged, proprietary, or otherwise private information.
> > > immediately and delete the original.  Any unauthorized 
> use of this 
> > > email is prohibited.