Subject: RE: [Ecrit] Proposed Requirement

From: "Marc Linsner" <[email-masked]>
Date: Mon, 17 Oct 2005 08:48:05 -0400

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]

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 20 Oct 2005 18:47:23 -0500

Okay, then let's make it a hard requirement so the debate can end and
specifications of mapping protocols can continue.

> From: Marc Linsner [mailto:[email-masked]]
> Sent: Friday, 21 October 2005 9:35 AM
> To: Winterbottom, James; 'Tom-PT Taylor'
> Cc: [email-masked]
> There is one more point I'm trying to make.  If the LCMS knows
location
> and
> identity, then it falls under the rules of RFC-3693.  This is
something
> I'm
> advocating is not necessary for LCMS to complete it's assigned task.
> 
> -Marc-
> 
> > Sent: Thursday, October 20, 2005 7:04 PM
> > To: Marc Linsner; Tom-PT Taylor
> > Cc: [email-masked]
> > Marc,
> > I think what it boils down to it whether the LCMS is allowed
> > to know location AND identity. If it is, then
> > location-by-reference must be allowed. If the LMCS is not
> > allowed to know location AND identity, then this must be a
> > formal requirement, otherwise the rationale is confusing and
> > contradictory.
> >
> > Cheers
> > James
> >
> >
> > > From: Marc Linsner [mailto:[email-masked]]
> > > Sent: Thursday, 20 October 2005 11:51 PM
> > > To: Winterbottom, James; 'Tom-PT Taylor'
> > > Cc: [email-masked]
> > > Comments in-line....
> > > > 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?
> > >
> > > 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-
> > >
> >

------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
[mf2]