RE: draft-jones-radius-geopriv

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

hi henning, 

do you remember our discussions in the washington interim meeting? there we
considered the http proposals for distributing location information. andrew
daviels proposed a custom location information format. there we argued that
we have to consider privacy issues (and therefore our results of the geopriv
working group). the geopriv working group decided to build their location
objects based on xml (and also the policies). some size considerations go
along with it (also with the usage of s/mime). 

regarding your dhcp example: 
the dhcp scenario is a little bit different to the radius/diameter example
since the location information which is distributed is not only about the
visited network but rather about the user (and also used in this sense).

ciao
hannes


> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Tuesday, February 17, 2004 3:44 PM
> To: Tschofenig Hannes
> Cc: 'John Schnizlein'; radiusext@ops.ietf.org; geopriv@ietf.org
> Subject: Re: draft-jones-radius-geopriv
> 
> 
> Why not re-use the encoding used in the civil version for DHCP? 
> Compression will not help significantly unless you use a SIGCOMP 
> approach and your dictionary is exactly right. The complexity 
> of doing 
> that boggles the mind.
> 
> Tschofenig Hannes wrote:
> 
> > hi john, 
> > 
> > thanks for your observation. 
> > 
> > i see the following ways to tackle this problem: 
> > - forget xml and use a different encoding which is more "lighweight"
> > - switch to diameter 
> > - compress xml objects
> > 
> > i personally think that the privacy issues are worth 
> thinking about these
> > options. 
> > 
> > ciao
> > hannes
> > 
> > 
> >>-----Original Message-----
> >>From: John Schnizlein [mailto:jschnizl@cisco.com]
> >>Sent: Monday, February 16, 2004 1:53 AM
> >>To: Tschofenig Hannes
> >>Cc: radiusext@ops.ietf.org; geopriv@ietf.org
> >>Subject: Re: draft-jones-radius-geopriv
> >>
> >>
> >>I am sorry I quoted the wrong part of RFC 2865.
> >>The length of an attribute is at most 255, one octet [page 25].
> >>It seems unlikely that GML, or any XML, would be efficient 
> >>enough to be carried in a RADIUS attribute.
> >>
> >>At 01:12 PM 2/10/2004, John Schnizlein wrote:
> >>
> >>>>One concern, if this location configuration information (LCI)
> >>>>is to be carried over RADIUS, is that the example in section 6
> >>>>seems to be 993 characters long. This one attribute seems to be
> >>>>taking a large share of the maximum RADIUS packet size of 4096.
> >>>>[RFC 2865, p 15] Is there enough room for everything else that
> >>>>would be expected with this attribute?
> >>
> > 
> > --
> > 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/>
> 

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