Re: capabilities problem

["Alan DeKok" <aland@ox.org>]

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.

> 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".

  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.

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

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

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

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