Re: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft

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

"Avi Lior" <avi@bridgewatersystems.com> wrote:
...

  I think we're agreeing on most things, and just nit-picking on
details.  That being said, let's continue.

> But alan, you cant go on the assumption that you will only accept
> non-binary "code" changes.

  I'm not assuming that.  I'm assuming that, again, for the 99% common
case, dictionary updates are enough to enable the server to deal with
new attributes.  This has been true in my experience, in the last
decade of working with RADIUS.

> Some attributes -- like the prepaid -- or mobile ip -- EAP --- require
> complex algorithms to be executed.  I doubt you can do them via
> configuraiton files.

  Which is why I never claimed you could.  Please, don't think I'm
unaware of algorithm changes that require updates to the server
binary.  I've mentioned that explicitely in previous messages.

> Yes. I agree. But my parser in my product is very capable and can handle
> more complex attribute structures then the other fellow.  So I can
> restate your statement as "complex things should be simle to do"

  If your parser can handle algorithm updates, too, more power to you.

  The problem the dictionaries solve is, again, the 99% common case
where a more complex parser just isn't necessary.

> Semantics are handled by clever policy files which use the attribute to
> compute some outcome.  The policy files are NOT standard in RADIUS.

  Agreed.  But again, the dictionaries (to a large extent) simplify
policy engines by removing the requirement that the policy engines
understand RADIUS attributes.  They don't.  They just understand name
to type mappings, and instances of named objects.

> The bottom line is this:
> We ought not make descision based on how complex or simple it is to
> handle an attribute.  That is nuts.

  I'm not sure why.  If an application can be supported by simply
defining a new attribute, and requiring that the attribute be sent in
a packet, then that application could be standardized with little
discussion.

  If an application requires more complex changes to the protocol,
then the decision to standardize it requires more discussion than the
previous case.

  Complexity *does* influence decisions.  Strongly.

> My original motivation for having a standard for complex attributes
> was because people were encoding attribute using name value pairs
> such as: in a String address="24 oberon",phone=" ".  I wanted to
> stop that because parsing these strings would slow every RADIUS
> server out there, and it was wasting space.

  Agreed completely.

> Also I resent somewhat the push now is so much that it ignores what we
> did a two years ago.  Based on discussion it was Jari who proposed
> encoding RADIUS attributes using Diameter syntax (I seem to recall that
> one of you guys were taking credit for that).

  Sorry for any conflict... that wasn't the intent.

> I think any other coding scheme is nuts and we should just move on with
> diameter encoding.  Unless of course  there is already working code as
> in the case of Prepaid.

  Agreed.  Let's move forward on that basis.

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