RE: Capabilities (was Re: AW: Review of draft-ietf-geopriv-radius-lo-04.txt )

["Avi Lior" <avi@bridgewatersystems.com>]

Hi Alan,

 

> -----Original Message-----
> From: aland@nitros9.org [mailto:aland@nitros9.org] On Behalf 
> Of Alan DeKok
> Sent: Thursday, September 08, 2005 2:26 PM
> To: Avi Lior
> Cc: radiusext@ops.ietf.org; Bernard Aboba
> Subject: Re: Capabilities (was Re: AW: Review of 
> draft-ietf-geopriv-radius-lo-04.txt )
> 
> "Avi Lior" <avi@bridgewatersystems.com> wrote:
> >  Hi Alan,
> > 
> > See inline....
> ...
> 
>   I concur with David's assesment.

No I don't because there is still a problem as I posted to Davids
statement.

You point this case out yourself here.

>   If the NAS SHOULD provide capabilites, then authentication 
> can still succeed if the capabilities are not provided.  If 
> the NAS MUST provide capabilites, then authentication MUST 
> fail if the capabilities are not provided.

Not exactly.... If the NAS says I can provide location and it does not,
then the RADIUS server MAY still allow the session on.  But here it is
the RADIUS server deciding what really happens to the session.  With
Bernards approach we can have the session terminate when we don't want
it to terminate.
 
>   The problem comes in when the RADIUS server wishes to 
> handle the session differently, depending on the NAS 
> capabilities.  If the RADIUS server challenges the NAS, the 
> session MAY be dropped, even though the RADIUS server MAY be 
> prepared to provide a lesser level of service.

Right....This is the case I am trying to get everyone to understand.

>   In that case, the NAS MUST always advertise it's new capabilities.
> The presence of the advertisement tells the RADIUS server 
> that full capability negotiation is possible.  The absence of 
> the advertisement tells the RADIUS server that no capability 
> negotiation is possible.

Exactly.....
 
>   One serious issue I had with the capabilities draft was 
> that it discussed the above situation, but didn't require the 
> NAS to always advertise it's capabilities.  I can't see how, 
> then, the capability negotiation could proceed.

True...we could tighten the draft on this issue....but I assumed perhaps
incorrectly that if a NAS supports the capability-draft then it MUST
advertize what it can provide.  But we can tighten the specification.

I think you and I are on the same page now.

>   Is the above design sufficient for your needs?

Yes, to summarize: 
Having a capability exchange for location -- that is the NAS indicating
its support for a feature is required to support the use case you
describe above and I described in various other emails.

 
>   Alan DeKok.
> 

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