Re: draft-jones-radius-geopriv

[John Schnizlein <jschnizl@cisco.com>]

Comments embedded in context:

At 02:06 PM 2/10/2004, Bernard Aboba wrote:

>I'm curious as to the contrast in approach taken by this draft 
>versus the DHCP option.  Given the recent activity on encapsulation 
>of RADIUS attributes in DHCP, isn't it important for the DHCP 
>option and the RADIUS attribute to take similar approaches?

I would be surprised to see anyone determine the host's location
through the RADIUS server, and pass that location through the 
relay-agent sub-option to the DHCP server, in order for the DHCP 
server to configure it at the host. However, similar approaches 
to encoding the information would match the similar constraints
that both DHCP and RADIUS are carried in a single UDP datagram.

>For example, if the goal is to make both the client and RADIUS 
>server aware of their location, then the NAS might pass a location 
>attribute to the RADIUS server, as well as passing this to the 
>DHCP server in a relay option.  Encoding the information two very 
>different ways seems like it results in unnecessary overhead.

A summary of the various intersections might be useful here:
(for others - I know Bernard knows this background)

draft-ietf-geopriv-dhcp-lci-option-03.txt specifies a way for a 
DHCP server to give a host the host's location, using (circuit-ID)
information from the relay-agent and knowledge of the wiring plant.

draft-ietf-dhc-agentopt-radius-03.txt specifies a way for a DHCP
relay agent to relay RADIUS information to the DHCP server for its
use in allocating configuration options.

draft-jones-radius-geopriv specifies a way for a NAS to tell a 
RADIUS server the location of the NAS. The location of the NAS could
be manually configured either in the NAS or in the RADIUS server
with which it shares a secret. The radius-geopriv attribute might
be added to the RADIUS attributes that are forwarded to a different
(home) RADIUS server (in the global roaming situation).
(If this summary is incorrect, please clarify.)

Before combining these ideas in a creative way, one would need to
have a clear understanding of whose location information is needed
where, and which provider of the information has the best access to it.
Since this analysis is already too difficult for some of us to want
to attempt, making it worse with different information formats seems
like over-kill.

John


--
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/>