On 9/17/09 8:32 PM, "Thomson, Martin" <Martin.Thomson@andrew.com> wrote:
> This analysis is telling. With Marc's clarifications, we essentially have the
> same process for all scenarios. The only thing that differs is the policy.
>
> That's OK, because we don't set policy.
Agree, 'we' don't set policy. But, we must provide the tools that allow:
1) The LIS to chose the correct policy.
a) Authenticate the requester
b) Provide the policy decision engine with the identity of the requester
c) Provide the policy decision engine with the posture of the request
(3rd party/target/etc).
c) May require a common requester identity architecture??
i) Is 192.168.1.73 a valid identity for 3rd party LR? (not to be
confused with the identity required for location determination)
All of the above is accomplished with the (2) LCPs we've created and SIP
Presence.
What am I missing?
-Marc-
>
> So, I'm left wondering why there is an apparent disagreement. Our task seems
> clear to me: identify areas where policy is necessary and highlight the
> associated problems.
>
> --Martin
>
>> -----Original Message-----
>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>> Behalf Of Alissa Cooper
>> Sent: Friday, 18 September 2009 12:20 AM
>> To: GEOPRIV
>> Subject: Re: [Geopriv] LCP & Arch....
>>
>> Before we get back to the terminology question that Marc has raised
>> regarding LCP, it might be useful to map out the use cases we are
>> discussing to see where the real differences are. I have made an
>> attempt below based on the recent discussions -- are these the
>> distinctions that we should be making?
>>
>>
>> In the rough process for an LS providing location to an LR, the LS:
>>
>> 1. Authenticates the LR.
>> 2. Checks whether the LR is authorized to receive the location it
>> requested.
>> 3. Provides the location if the LR is authorized.
>>
>> I think we have four basic use cases that we've been comparing.
>>
>> I. In DHCP, the steps above are as follows:
>>
>> 1. Authentication: based on DHC
>> 2. Authorization: implicit because LR is the Target
>> 3. Provide LI (per 3825 or 4776) or location URI pointing to LO (per
>> dhcp-lbyr-uri)
>>
>> II. In the base HELD protocol, the steps are:
>>
>> 1. Authentication: return-routeability of IP address
>> 2. Authorization: based on Rule Maker rules (which may be equivalent
>> to the "LCP policy" of only providing a Target with its own location,
>> or may forbid even that for certain Targets, per Martin's email [1]/
>> held section 9.3)
>> 3. Provide LO or location URI pointing to LO
>>
>> III. For a Target using a HELD identity extension to obtain its own
>> location, the steps are:
>>
>> 1. Authentication: required, but we can't mandate anything detailed
>> since it depends on the identifier presented (per Richard's email [2])
>> 2. Authorization: based on Rule Maker rules (which may be equivalent
>> to the "LCP policy" of only providing a Target with its own location,
>> or may forbid even that for certain Targets, per Martin's email [1]/
>> held section 9.3)
>> 3. Provide LO or location URI pointing to LO
>>
>> IV. For an LR using a HELD identity extension to obtain some other
>> Target's location, the steps are:
>>
>> 1. Authentication: required, but we can't mandate anything detailed
>> since it depends on the identifier presented (per Richard's email [2])
>> 2. Authorization: based on Rule Maker rules
>> 3. Provide LO or location URI pointing to LO
>>
>> [1] http://www.ietf.org/mail-archive/web/geopriv/current/msg07874.html
>> [2] http://www.ietf.org/mail-archive/web/geopriv/current/msg07880.html
>>
>>
>>
>>
> ------------------------------------------------------------------------------
> ------------------
> 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]
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
