[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Location draft issues raised today
Hi,
On Tue, Mar 21, 2006 at 02:43:23PM -0500, Alan DeKok wrote:
> There were concerns rasied in the meeting today about the encoding
> of location data in RADIUS attributes. I'll expand on my comments here:
>
> - If the encoding of the location information is taken from a
> normitive reference (as suggested in the WG meeting), then the packing
> of that information should be outside of the scope of RADEXT. The
> description of the complex encoding in the draft should be replaced by
> a normitive reference to another document.
>
> That would resolve all of the concerns around complex attribute
> encodings in RADIUS.
I agree that it would support the packing as it is, but I think the
overriding criterium is whether or not the server wants access to
individual members in order to apply administrator defined policy.
If so, an encoding using multiple attributes, however grouped (if needed
at all; a request only contains at most one instance of location
information if I understand correctly), would be desireable over
packing, even if such a packing is standardized for another protocol.
The repacking by the RADIUS client can be well defined and nonambiguous.
I don't see any problem with that.
Note that we can't foresee all future policies that servers or their
administrators would wish to execute. It's better to err on the side of
caution (splitting in multiple attributes where that's not really
necessary) than on the other side, as that would require servers to be
updated with GEOPRIV-specific parsing code as soon as they would want to
support location-specific authorisations.
In this case, if there is any reasonable use for individual member
fields, they should use separate attributes, in my opinion.
> - If, on the other hand, the encoding is specific to these attributes
> and occurs nowhere else, then the packing is within the scope of
> RADEXT, and the concerns raised should be addressed by the document
> authors.
It's in our scope anyway. It's not that "if there's any other encoding
for this information, in any other protocol, we have nothing to say
anymore". This is also what I seemed to hear from Bert as well as
Bernard.
It depends on whether there's any meaning to be attached to the elements
*at our level*, that is, the RADIUS proxy or endpoint.
Cheers,
Emile.
--
E-Advies - Emile van Bergen emile@e-advies.nl
tel. +31 (0)78 6136282 http://www.e-advies.nl
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>