RE: draft-jones-radius-geopriv

[Tschofenig Hannes <hannes.tschofenig@siemens.com>]

hi john, 

thanks for your summary. please see a small comment below:

> -----Original Message-----
> From: John Schnizlein [mailto:jschnizl@cisco.com]
> Sent: Tuesday, February 10, 2004 8:49 PM
> To: Bernard Aboba
> Cc: Tschofenig Hannes; radiusext@ops.ietf.org; geopriv@ietf.org
> Subject: Re: draft-jones-radius-geopriv
> 
> 
> 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.)

i guess there are two issues here: 

a) encoding of location information
b) who is authorized to distribute location information

for (a) the draft suggests to take a look at the results of the geopriv
working. initially i was a little bit skeptic about gmlv3 but when i looked
at the details i saw that these guys did good work. 
for (b) there are different scenarios. we tried to describe them in detail
to make an analysis easier. first, the visited network might distribute its
own location information to other networks - fairly simple stuff. second,
the visited network makes the location information of the end host
accessible. call me strange but i think that there are some privacy
considerations. 
once such infrastructure is deployed people tend to use it for other
applications as well. 

> 
> 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.
certainly. 

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

ciao
hannes

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