Re: Capabilities: Moving forward - to the problem, please

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

Emile van Bergen <openradius-radextwg@e-advies.nl> wrote:
> But for the life of me, I did not see any connection between the two
> problematic scenarios and even C1, leave alone the rest.

  I tried to explain the connection.

  Avi's requirement is that we can't send Access-Challenge unless we
*know* the NAS won't treat it as Access-Reject.  That pretty much
forces some kind of capability advertisement in the first
Access-Request.  Add to that the belief that multiple round trips are
inefficient, and you have C1.

> If that's deduction, then I'm missing it, but I sure could do with some
> more steps in the line of reasoning there. It doesn't help to say, we've
> want GEOPRIV, we want mandatory session limiting, therefore all
> capabilties need to be advertised. QED.

  My previous proposal of a "challenge-capable" attribute minimizes
the capability advertisements in the first packet, and maximizes the
resulting traffic.

  If that's fine for you, OK.  But it's not fine for Avi, and I agree
with him here.

> Agreed. I'll do my best, but I was really surprised at what I saw as
> your complete ignoring of Bernard's suggestion to leave the solutions
> aside for a while and to focus on the problem first.

  I wasn't proposing a solution.  I was proposing a list of
requirements that would enable a capability solution to be
implemented.  My $0.02 is that if one of those requirements is not
satisfied, we probably will not be able to implement *any*
interoperable solution.

  There is a very big difference between saying "bits on the wire look
like X", and saying "in order for two parties to agree, they have to
exchange information".  Bernard wanted to avoid the first kind of
discussion, and I agree with him.  My requirements were solely of the
second kind.

> You repeated the two problems I've described too, without responding
> to my description of them, without adding any detail, scope or
> implications, and then skipping straight to a set of requirements
> for a solution.

  Uh, no.  I responded to Bernard's post, not yours.  The list
archives indicate that there have been no followups to your response.

> Not in a vague, general sense; but as in "for GEOPRIV, the NAS needs to
> know a single bit that says whether a user's privacy policy allows it to
> send Location information. The NAS currently has no way of obtaining
> that bit. In most cases the RADIUS server will have it, because that's
> generally where the user's profile is stored. Therefore GEOPRIV requires
> a roundtrip to the RADIUS server before an access request containing
> Location information can be sent, to obtain the bit. One way, but
> perhaps not the only way, of implementing that first roundtrip is as an
> Access-Request/Access-Challenge transaction".

  That contains a lot of implementation details, and is substantially
a proposed solution.

  My preference is to discuss the *concept* of capability exchange and
advertisement.  i.e. how two parties can mutually agree on *any*
capabilities via some general method.  i.e. what are the minimum
requirements for that agreement to be reached, like "the parties must
communicate".

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