RE: Status of Issue 225

["Glen Zorn" <glenzorn@comcast.net>]

Alan DeKok [mailto:aland@deployingradius.com] writes:

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

I'm not really interested in taking a walk on the psychic side just now, so
how about I just pretend that you are expressing your (necessarily biased)
opinion based upon your (necessarily limited) experience, just like
everybody else?

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

But you didn't _say_ that; similarly, your suggestion that " attributes
generated by a client or server MUST NOT be fragmented at boundaries other
than 246 octets" says that values the length of which is not evenly
divisible by 246 are illegal.  I suspect that you actually _meant_ that all
but the final fragment must be 246 octets in length but again, that's not
what you _said_.  I suppose that it's possible that you spent hours
designing these "solutions" but giving you the benefit of the doubt, I'll
assume that it's more like 10 seconds.  Maybe you could take a little bit
more care in crafting your suggestions because as it is you are not offering
solutions so much as you are creating bugs for others to find and fix.

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

Amazingly enough, you're not the only person in the world to have talked
with (or been) a RADIUS developer; _my_ personal experience (which I suppose
must be less valid than the royal form that you seem to possess) suggests
that the vast majority of developers are highly intelligent & when questions
about standards arise they are about far more subtle things than this.

...


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