RE: capabilities problem

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

See inline please: I think we are darn close....

> -----Original Message-----
> From: owner-radiusext@ops.ietf.org 
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok
> Sent: Friday, October 21, 2005 2:02 PM
> To: Emile van Bergen
> Cc: radiusext@ops.ietf.org
> Subject: Re: capabilities problem
> 
> Emile van Bergen <openradius-radextwg@e-advies.nl> wrote:
> > Ok. So can we conclude that the inefficiency objection of a second 
> > round trip in case of GEOPRIV is moot, because it's needed 
> anyway, and 
> > that this is solved perfectly by your proposal with my refinements?
> 
>   Yes.

Unless I am missing something I don't agree.

The second round trip should not happen unless the NAS indicates that it
supports location fetching via a challenge.

If  the NAS happens to supported fetching of location via challenge then
its everything is okay.  But if the NAS did not support fetching of
location via challenge then the challenge was wasteful, and worse, it
can result in the termination of the session which may not be desired.
Therefore an initial advertizement will give the RADIUS server an
indication whether a challenge for location will be fruitfull.


> > Agreed. Problably the misunderstanding lies in that I take 
> > 'advertising a capability', as 'This party implements standards 
> > document X, containing numberous clauses with musts, shoulds and 
> > mays', which I find problematic. That's perhaps my biggest 
> objection.
> 
>   Which is why I avoided implementation and semantic 
> problems, by saying "advertises a capability".


Yes.

>   First, we can decide what we need from capabilities and 
> their advertisement, independent of the definitions for each 
> capability.
> Then, we can define the capabilities.  Finally, we can 
> describe their on-wire formate.

Agreed.
 
> > But I want to get rid of the explosion of possible states that a 
> > system can get when two parties state their abilities, 
> their wishes, 
> > and then have to do a form of negotiation.
> > 
> > It took numerous endless looping implementations of PPP to get that 
> > right in PPP.
> 
>   Agreed.  I vew capability negotiations a bit like the final 
> "show of hands" in poker.  Everyone's cards go on the table, 
> and everyone runs the same algorithm on the available data.  Once.

Agreed....Nobody has suggested a multi-round negotiation.
 
> > If the use of challenges to get at information that can be 
> put in the 
> > first access request was Avi's worry too, then I completely agree.
> 
>   To put it more strongly, if we don't have *any* capability 
> advertisement in the first packet, we're back to today's 
> RADIUS, and we can't break that by changing server behavior.

Yes.  Thankyou.

> > Luckily here, you've misunderstood. I'm surprised. Am I 
> really so bad 
> > at explaining my position clearly?
> 
>   There was significant opposition to allowing Avi's scenario.
> 
> > So I think we may have complete agreement on the problem 
> and abstract 
> > solution for GEOPRIV and alike future cases, at least 
> between you, Avi 
> > and myself.
> > 
> > We only need to work out the attributes and values
> 
>   I disagree.  I think we're pretty close, but I don't think 
> we're ready to design a solution based on the stated 
> requirements.  I would like to ensure that *all* capability 
> requirements are spelled out, to ensure that the solution is 
> applicable to later capabilities.

I agree.  And unless I am missing something the first issue above is
still problematic.

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

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