Re: Status of Issue 225

[Alan DeKok <aland@deployingradius.com>]

Glen Zorn wrote:

>>   It is not *ridiculously* clear from the current document that
>> "Length"
>> and "Extended-Length" are strongly related.  
> 
> Maybe not to you...

  Pretend I'm channeling the 100's of people who've read the specs, and
implemented broken NASes.

> This would disallow the presence of multiple AVPs in a single attribute.
> Are you claiming "WG Consensus" for this massive change?  

  No.  If there *is* only one AVP in a single attribute, then that
relationship holds.

>>   Experience shows that without this text, people will create
>> attributes
>> that don't satisfy this criteria... and claim they're standards
>> compliant.
> 
> This comment is fascinating.  What, exactly, is the "experience" you are
> talking about?  Are there already multiple implementations of the extended
> attributes?  Have you perfected time travel?  

  I am, of course, not claiming experience with multiple implementations
of the extended attributes.  Pretending I'm making that claim is
disingenuous at best.  Instead, I'm claiming something much more
difficult to understand.

  The "experience" is with previous standards, and the people who've
implemented RADIUS software based on them.  It's called "learning from
experience", and "applying that experience to new situations".

  I've spent a lot of time talking with implementors of NASes and
servers about their software.  There are a number of styles of
misunderstanding that they have about existing specifications.  That
experience can be used to review new standards, to minimize the
potential for similar problems.

>>   Experience shows that without this text, people will create short
>> fragments, causing problems for everyone else.
> 
> More "experience".  Where does this "experience" come from?  The only
> problems caused will be for those who wrote code that can't handle fragments
> < 246 in length.

  Inefficient packing should be discouraged.  On top of that, the size
limitation of RADIUS packets means that inefficient packing of
attributes can cause packets to fill quickly.  This means that the
packets can carry less information than they would otherwise have been
able to carry.

  This has implications for all networks that depend on implementations
of the standard.

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