That's OK, because we don't set policy.
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
