> I don't disagree with this. But I view it a little differently. I view
> that there is a demark between the LCP and the policy engine, hence the LCP
> doesn't 'use' a particular policy.
I think you're a little too focused on mechanism here. When one says
that "X enforces Y policy", all that really means is that "X behaves in
such a way that Y policy is satisfied". The NAT in my home gateway
enforces a default-deny policy on incoming TCP connections not because
it has some policy engine that looks at a SYN and makes a decision, but
just because that's how it works. If you've got a DHCP or HELD server
that blindly responds to requests from a host with information on that
host's location, then it's enforcing the LCP policy just by virtue of
the way it acts.
In that spirit, I think Alissa's proposed text makes sense. Maybe an
additional sentence or two would be helpful to explain that applying a
policy doesn't imply specific policy machinery?
(Note that none of the above rules out having some policy engine in any
case, e.g., to support more sophisticated policy or multi-protocol
operations (as you suggest). It's just that the LCP policy is the one
that's really easy to implement.)
--Richard
> The LCP is simply the communication
> protocol that presents a location request to the policy engine. Hence, if,
> the LIS can authenticate a request as coming from a target by some other
> means, not using a LCP, the same 'LCP Policy' would be used. So, the policy
> isn't tied to the communication protocol, but in the case of a request
> coming in via a LCP, the process required to authenticate the requester as
> the target are taken care of by the communication protocol.
>
> If this makes any sense.....
>
> To carry this thought a little further. Someone *could* build a LS/LIS that
> includes a DHCP front-end, a SIP front-end, and a HELD front-end. Any
> request coming to this LS/LIS would be evaluated based on the protocol it
> arrived on, the authentication of the requester, and then a policy chosen
> that fits the posture of the request. Hence, a common policy engine that is
> demarked from the communication protocol.
>
> -Marc-
>
>
> On 10/13/09 4:16 PM, "Alissa Cooper" <acooper@cdt.org> wrote:
>
>> So am I right in thinking that if it said
>>
>>>> Location configuration protocols [can|may|might] make use of an
>>>> authorization model
>>>> known as "LCP policy,"
>>
>> that would be better?
>>
>> Alissa
>>
>> On Oct 13, 2009, at 1:28 PM, Marc Linsner wrote:
>>
>>> Alissa,
>>>
>>>
>>> On 10/10/09 3:40 PM, "Alissa Cooper" <acooper@cdt.org> wrote:
>>>
>>>
>>>> == Section 5 (based on text suggested below) ==
>>>>> The authorization model for a location configuration protocol
>>>>> assumes
>>>>> that the LR is also the Target, and that providing that LR with
>>>>> information
>>>>> about its own location is allowed. We call this property "LCP
>>>>> policy".
>>>> Replace with:
>>>>
>>>> Location configuration protocols make use of an authorization model
>>>> known as "LCP policy," which permits only Targets to be the
>>>> recipients
>>>> of their own locations.
>>>>
>>> GeoPriv should not set-in-stone "LCP Policy". That's up to the
>>> RuleMaker.
>>> We can assume the RuleMaker's policy for a target knowing it's own
>>> location
>>> is different from a 3rd party policy, and we can posture the request
>>> as
>>> such, but as Laura Leiss has stated for a long time, the Rulemaker
>>> will
>>> ultimately decide whether a target will see it's own location or not.
>>>
>>> -Marc-
>>>
>>>
>>>
>>
>> _______________________________________________
>> 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
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
