RE: Capabilities: Summary

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

I don't think this is a valid question to ask.  We should not be
designing protocols based on assumptions such as the one you want us to
make.

Furthermore, sending a challenge to a node that supports challenges but
does not support location is just wastefull.

Having an advertizement in the access request does not add any new
attributes (since the attribute for requesting location and advertizng
location is the same) and does not requires any extra messages.  

So forgive me but, the approach of advetizing takes the quess work out
of the protocol and  I don't understand why we need to discuss this
issue over and over again.

 

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David
> Sent: Monday, October 10, 2005 11:52 AM
> To: radiusext@ops.ietf.org
> Subject: RE: Capabilities: Summary
> 
> Hannes Tschofenig writes...
> 
> > a) problems seem to appear if the nas does not support the 
> challenge.
> > then the challenge will be treated as a reject.
> 
> Yes.  However, we know that the RADIUS EAP method requires 
> support in the NAS for challenges.  Are there any deployment 
> scenarios of interest for GEOPRIV that expect to use the 
> RADIUS PAP or CHAP methods?  If not, this may well be a moot point.
> 
> 
> --
> 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/>