Subject: AW: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt

From: "Tschofenig, Hannes" <[email-masked]>
Date: Sat, 3 Sep 2005 21:41:15 +0200

hi john, 

> The inclusion of the "entity" field reintroduces the problem we had 
> with the initial draft, which is that no practical mechanism has been 
> identified through which the NAS would know the location of the host 
> attempting attachment.

i wonder why you believe that these mechanisms are not available today.
a number of other people have already provided you with references to
existing products. 
let me add two links that explain how location determination works in a
wlan environment: 
http://www.tkn.tu-berlin.de/publications/papers/hoene_paper2.pdf 
http://www.tkn.tu-berlin.de/publications/papers/tkn_04_16_paper3.pdf
(there are certainly more papers about this subject available and i
guess i do not again need to mention 3g networks.) 

i have a question for you: you are the co-author of rfc 3825. now,
consider the discussions we have in the emergency context (in geopriv &
ecrit) and the idea to provide location information using dhcp to the
end host for inclusion into an emergency call. do you think that there
is a relationship between the location of the dhcp server/dhcp relay and
the location of the end host?

> 
> Rather than prolong the illusion, it would be better to 
> eliminate this 
> field and let the location attribute refer to the location of the NAS.

ciao
hannes

> 
> John
> 
> On Aug 30, 2005, at 9:11 AM, Bernard Aboba wrote:
> 
> >> Are you sure? The Location-Information attribute includes a field
> >> called "Entity", described as follows
> >>
> >>    Entity (8 bits):
> >>      Describes which location this attribute refers to:
> >>      (0) describes the location of the user's client device
> >>      (1) describes the location of the AAA client
> >>
> >> It looks like NAS could use this field to describe which location
> >> it's sending, or send two Location-Information attributes if it
> >> knows both.
> >
> > But the NAS isn't sending location by default.  So how does 
> the RADIUS
> > server that requires a given kind of location indicate what 
> it needs? 
> > Keep
> > in mind that if the RADIUS server REQUIRES location then it 
> may need to
> > send an Access-Reject.
> >
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

---

From: John Schnizlein <[email-masked]>
Date: Tue, 6 Sep 2005 10:43:06 -0400

Answering your question: I think there is no meaningful relationship 
between the location of the DHCP server and the host.  The utility of 
including the 'what' element value (zero) for the location of the DHCP 
server in draft-ietf-geopriv-dhcp-civil-06 has been questioned in IESG 
review as well.

John

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 06 Sep 2005 14:50:00 -0400

We've had this discussion a few times, like so many other evergreens on 
this list. While this is not universally useful, in many cases, the DHCP 
server is known or very likely to be close (i.e., within about 100 m) to 
the actual end user. This is true for corporate networks and for home 
networks, presumably two of the largest users of DHCP.

Providing a location, with qualifications, is likely to be more useful 
than either pretending one knows the real end system location or not 
providing any location information, which are the only other options.