Subject: Proposed Resolution of Issue #318: REJECT

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 25 Oct 2009 01:26:41 -0700

Alan DeKok said:

"This issue should be rejected.

  RADIUS specifications define format, meaning, interpretations, and
processing requirements for attributes.  Two implementations that
disagree about an attribute can inter-operate at the RADIUS level by
exchanging RADIUS packets.  They cannot be said have interoperable
implementations of the attribute."

Given that the Design Guidelines document has already been approved for
publication by the IESG, the bar for making changes is extremely high.  

In this case, that bar does not appear to have been reached. 

The assertion is that interoperability issues cannot be created by a 
mismatch of RADIUS data types and therefore that normative language
cannot be used. 

While it is possible for any RADIUS attribute to be expressed as a 
String of octets, configuration of attributes in Hex is both inconvenient
and error prone.  Moreover, if an attribute requires computation of any
kind, then a mismatch in the data type will result the data being 
misinterpreted, with unpredictable results. 

Therefore the text in question would appear to meet the RFC 2119 bar. 

The proposed resolution of Issue 318 is REJECT. 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 25 Oct 2009 21:34:42 +0700

Bernard Aboba [mailto://[email-masked]] writes:

> publication by the IESG, 

I hate to repeat myself, but this statement is STILL FALSE.

> the bar for making changes is extremely high.
> 

That may be Alan's assertion, but it's not mine.  My assertion is that
correctly implemented code changes (maybe that's asking too much?) do not
effect interoperability, nor does requiring such cause harm.

...

---

From: "Dave Nelson" <[email-masked]>
Date: Sun, 25 Oct 2009 10:59:52 -0400

Glen Zorn writes...

> My assertion is that correctly implemented code changes (maybe
> that's asking too much?) do not effect interoperability, nor 
> does requiring such cause harm.

Your assertion is that correctly implemented code changes at both the client
and server ends of a client-server protocol implementation would not affect
interoperability.  True, as far as it goes.  The point that is being
addressed in the RADIUS Design Guidelines is that *requiring* code changes
on the sever side, when a data dictionary change alone would suffice, is
harmful to interoperability, or at least forces maintainers of server
implementations to make code changes they would not otherwise have to make.
The guidelines discourage attribute design choices that would force a code
change on RADIUS servers when no such change would be required with a more
"traditional" choice of attribute design.

I suspect you don't attach much value (or even credence) to this data-driven
model on the server side, but many in the RADIUS community do.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 25 Oct 2009 22:25:23 +0700

> implementations to make code changes they would not otherwise have to

This claim is valid only for some (primitive) implementations.  I am
currently running a RADIUS server (w/a nice GUI, no less) that will handle
any length of integer, signed or unsigned, (not to mention arbitrary
"complex" attributes) with only a dictionary change or two.  It's hardly
rocket science to build a flexible, data-driven parser and I'm actually
personally offended by the attempt to standardize this kind of weak design.

> model on the server side, but many in the RADIUS community do.

In fact I hold the idea in great esteem; what I disvalue is the idea that
data-driven models have to be implementable by below-average high-school
kids.

---

From: "Dave Nelson" <[email-masked]>
Date: Sun, 25 Oct 2009 11:35:54 -0400

Glen Zorn writes...

> > I suspect you don't attach much value (or even credence)
> > to this data-driven model on the server side, but many in
> > the RADIUS community do.
> 
> In fact I hold the idea in great esteem; what I disvalue is
> the idea that data-driven models have to be implementable by
> below-average high-school kids.

There is no need for you to be so dismissive of, and insulting to, your
colleagues, who form the rough consensus on this issue.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 25 Oct 2009 23:55:39 +0700

> colleagues, who form the rough consensus on this issue.

If you would be kind enough to read my comment, you will see that I said
nothing whatsoever about my colleagues, let alone anything insulting or
dismissive.  The fact is, however,  (as Hannes has also pointed out) that
the processing model assumed in the Design Guidelines draft is simplistic
and limited, if not outright primitive.  If you wish to believe that that
fact makes the promoters of the model simplistic, limited and primitive as
well, that is your choice but I said nothing of the sort.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 26 Oct 2009 16:43:44 -0400

Glen Zorn wrote:
...
...
> dismissive.

  Nonsense.  In case you had missed the major shift in software of the
last 20 years, many world-class software products are written *without*
a budget.  i.e. Open Source projects, among others.

  Your comments are insulting to me personally, and to any number of
people whose customers demand something *other* than "what Glen wants".

>  The fact is, however,  (as Hannes has also pointed out) that

  Your statement was the equivalent of "have you stopped beating your
wife yet".

  It's insulting, dismissed, and damned well *intended* to be insulting
and dismissive.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 27 Oct 2009 09:15:34 +0700

> a budget.  i.e. Open Source projects, among others.

Do you ever read what you write?  I really wish you would, since the rest of
us have to.  I didn't say anything about budgets.

> people whose customers demand something *other* than "what Glen wants".

My sincerest apologies to all those customers who demand limited and
simplistic designs.  I really had no idea.

>   It's insulting, dismissed, and damned well *intended* to be insulting

Thank you for interpreting my intentions for me.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 27 Oct 2009 10:18:25 -0400

> us have to.  I didn't say anything about budgets.

  Of course not.  The best kind of argument is to make a claim based on
insinuation, and then deny that you made any such insinuation.

  You insulted everyone who made an implementation choice based on
limited time and/or money.

> simplistic designs.  I really had no idea.

  The reality is that many customers are *happy* with the status of many
RADIUS dictionary implementations.  Their priorities are *new* features
that make business sense for them.

  Instead of facing that fact, you dismiss the customers as "demanding
limited and simplistic designs", and you dismiss the implementors as
"below-average high-school kids" for making decisions based on limited
time/money budgets.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 27 Oct 2009 07:28:52 -0700

> "below-average high-school kids" for making decisions based on limited

Indeed.  The dictionary has *huge* value to real customers.  They *hate* having to do upgrades just to get support for new attributes.  These customers aren't stupid, or simplistic.