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

[Emile van Bergen <openradius-radextwg@e-advies.nl>]

Alan, Avi,

On Thu, Oct 20, 2005 at 12:34:46PM -0400, Alan DeKok wrote:

> Emile van Bergen <openradius-radextwg@e-advies.nl> wrote:
> > Are you being serious? You're *seriously* claiming each item follows
> > from the previous one?
> 
>   I would prefer that you discuss the content of my message, rather
> than the manner in which it was presented.  That would be much more
> productive.

I did. I read the content as a list of requirements for a solution to
the two problems we seem to agree on.

But for the life of me, I did not see any connection between the two
problematic scenarios and even C1, leave alone the rest.

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.

> > I think you missed Bernard's line that shopping lists make bad design
> > documents. You seem to try and distill requirements from every shopping
> > list item that has ever floated here.
> 
>   No.  I started with the two scenairos as stated in my message.  The
> first requirement (C1) followed from that.  You haven't presented
> concrete objections to that, or any of the other statements.

My concrete objection is that it's a /very/ broad statement, presented
without much explanation as THE requirement for ANY sane solution to the
two problems.

The steps you took to arrive at that conclusion were perhaps present in
one the 10-20 earlier attempts, but I didn't find them in the version
you sent.

> > So, if we FIRST get a SHORT list of real world problems that are
> > currently fundamentally impossible to solve due to lack of information
> > at the client or server AND clearly describe the decision that cannot be
> > made correctly due to the lacking information,
> 
>   My message did so.  You haven't responded to it.
> 
>   I think part of the problem here is that we're talking at cross
> purposes.  I've been reading the different posts, and trying to
> distill a common set of scenarios.  I presented those, and some
> requirements in my post.  Rather than address those, you've responded
> with your own set of requirements.

I didn't respond with my own set of requirements to the solution. I
responded with a set of suggestions for the /process/ to arrive at a
solution, starting from Bernard's suggestion to focus on a clear problem
statement first.

I also added the capabilities-related problems I've been able to gather
from the discussion, and tried to describe them in terms of missing
information at either party.

>   If the conversation is going to be nothing more than people
> presenting what they want, and ignoring what other people say, I don't
> see any point in continuing.

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.

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. My reaction is basically that you haven't demonstrated at all
that those requirements follow from the problem.

Avi, I also think it doesn't help to make broad references to features
('prepaid', 'cui', 'geopriv') to make a case for any capabilities
design. What does help is to describe, in excruciating detail, who needs
what information when (and why). 

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

Unless we start doing that, explaining the *problem* at the bit level,
without immediately going to broad generalities, I don't think we'll
ever reach consensus about any solution.

Cheers,


Emile.

-- 
E-Advies - Emile van Bergen           emile@e-advies.nl      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

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