Re: capabilities problem

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

> Indeed.  To put the point more forcefully -- continued attempts to advocate 
> for the original capabilities advertisement draft are not productive.

  I don't understand.

  From my reading of recent messages and the draft, even Avi isn't
advocating the solution proposed in the draft.  And I'm certainly
opposed to much of what the draft says, for reasons I've articulated
previously.

  To address one of Emile's points:

> In the case of GEOPRIV, and we've been at this at length, the case
> of service being dependent on Location information CANNOT be
> implemented in a single round trip AT ALL, because the NAS first
> needs to be informed of the user's privacy policy -- in short,
> whether or not that NAS is allowed to send the user's Location at
> all.

  There is no conflict that I can see between this requirement and my
position, or Avi's position.

  The ability to perform multi-round negotiation of data to include in
a packet is itself a capability that can be advertised.  That
capability MUST (IMHO) be advertised in the first packet, otherwise
the server may send an Access-Challenge to a NAS that doesn't support
it.  The user then ends up with no service rather than limited service.

  The only disagreement I can see is that Avi and I believe that
multi-round capability negotiation is itself a capability that has to
be advertised, and others believe it's OK to send Access-Challenge
without knowing if the NAS supports it.

  For the record, my original position was that I was OK with blindly
sending Access-Challenge, as it was fail safe.  But if there are
use-cases where it's useful to offer limited services, then sending
Access-Challenge is itself a capability that has to be negotiated or
advertised.  The alternative is to make it impossible to "fail
gracefully", and offer limited service.  The choice will be all or
nothing.

  To put it another way:

  If Emile's NAS supports multi-round negotiation, then it advertises
that, and the NAS and server perform the negotiation that Emile wants.

  If Avi's NAS doesn't support multi-round negotiation, then it
advertises that, and rather than doing negotiation, the server offers
limited service, which is what Avi wants.

  I don't see any disagreement between the two positions, and I don't
see how this relates to the original draft, which didn't talk about
these issues.

  Avi's position (I believe), and mine, is to allow both scenarios.
Emile's position (from what I can understand) would appear to prevent
Avi from deploying his scenario.

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