Subject: AW: [Geopriv] Introduction

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 3 Feb 2005 23:07:36 +0100

hi stefan, 

please find my comments below: 

> Hello!
> 
> > Welcome.
> 
> Thank you :-)
> 
> > Document review is something we always need.  If you find errors or
> > issues with the GEOPRIV RADIUS document, please bring it to our
> > attention.
> 
> I just summarised my thoughts about the doc to the authors of 
> the current 
> draft in a private mail. Of course I can copy&paste them here 
> again (Sorry, 
> Hannes et al., for sending this twice):
> 
> One point is that the content that is to be transferred is 
> encoded in a single 
> attribute, Location-Information. This implies that a possible 
> implementation 
> would need to write its own parser just to get to the content 
> (and, given 
> that most fields of the geospatial Location-Info part are far 
> from being 
> 32-bit aligned, this would be an errorprone job to do). That 
> is not the way 
> RADIUS usually works. You mostly often only put a single 
> piece of information 
> into a single attribute, so that the general RADIUS packet 
> parser can easily 
> decode the content you want. This would imply that either 
> IANA has to assign 
> more attribute values (no idea how generous they are in 
> issuing these) or that 
> a different solution had to be employed: VSAs. This wouldn't 
> be exactly 
> clean, but RADIUS servers are very well prepared to handle 
> VSAs if you just 
> give them a dictionary file. You also shouldn't forget that 
> NAS equipment 
> should be able to send the location information, and these 
> are usually very 
> hard to modify.

there are several issues regarding splitting the location-information
attribute into several attributes 

a) attribute space: 

in the radext working group people are very concerned about the limited
attribute space. 
hence, we tried to ensure that the encoding is quite compact. 

b) info carried within the attribute

the location-info attribute contains information that belongs together. in
case of the civic location the structure is a bit more complicated but is
aligned with the dhcp work. one could reuse the parser code. 

for the geospatial location info i think is not a good idea to separate
lat/long/alt info. 

it might be possible to split the civic loc-info and the geospatial loc info
into two separate avps. however, i am not sure that it helps a lot. 

> Another thing is the handling of user privacy. The Basic-Policy-Rules 
> attribute is very limited.

it is certainly true that the Basic-Policy-Rules is quite limited. we tried
to be as close to the existing geopriv work as possible. 

> You can only make a binary 
> decision to allow or 
> deny the transfer of the location information.

yes. 

> A more 
> fine-grained control 
> (like: only allow Country and City to be transported after 
> the first hop) 
> would be a nice addition.

rethinking it i think you need to explain the scenario a bit further. 

> Plus, giving a URL reference to a 
> policy is not 
> very practical IMO.

there are only two options: 

a) the policies are very small and lightweight then you can carry them
inside radius. in geopriv we tried to keep the policies as simple as
possible but they are still too large to be used in radius directly.
compressing them is also not a solution (they are still quite large - i
tried it). 

we thought that it is valuable to reuse existing work. (particularly since
we had long discussions about the policies in the geopriv wg. ) 

b) fetch them using another protocol as we did it. 
 
> You certainly don't expect a human being 
> to inspect each 
> arriving packet to get to know its policy.

i guess this refers to the note well attribute and not to the basic or the
extended ruleset in general. 

> My suggestion for 
> this attribute 
> is that instead of a "Note Well", a bit field is introduced 
> where each bit 
> represents a permission flag which type of information may be 
> transferred.

are you talking about the home network or the visited network? 

> (I 
> am aware of the reference to a richer ruleset in 
> Extended-Policy-Attribute, 
> but the need to first fetch the info via a TLS connection and 
> evaluating a 
> ruleset document and then modifying the RADIUS packet makes 
> an efficient 
> parsing and proxying of packets almost impossible). The "Note 
> Well" could 
> still survive, but I'd move it into the Extended-Policy-Attribute.

the reference to the note well text is not supposed to be processed by the
radius entity. however, we expect that people use the obtained location
information for location based services. there, we would like to be inline
with the geopriv architecture.  

ciao
hannes

> Greetings,
> 
> Stefan Winter
> 
> -- 
> Stefan WINTER
> 
> RESTENA Foundation - Réseau Téléinformatique de l'Education 
> Nationale et de 
> la Recherche
> Network and Systems Engineer
> 
> 6, rue Richard Coudenhove-Kalergi
> L-1359 Luxembourg
> email: [email-masked]     Tel.:      +352 424409-33
> http://www.restena.lu                     Fax:      +352 422473
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv