Re: "Last Look" at the RADIUS Design Guidelines document

[Avi Lior <avi@bridgewatersystems.com>]

David,

This document and the topics around this document have been problematic from day one as you say and its not just complex attributes.
> We need to make progress on both the Guidelines BCP and the Extended
> Attributes document, and continued debate over issues such as complex
> attributes is blocking progress.  It's time to move on.  Please.

If you want to make progress then do something about the complex attributes and other areas that are problematic.  It seems from the remark you are making you a suggesting that we stop complaining about these complex attributes and other things.  This has been the style in RADEXT and I am sorry but you have objections to certain topics and treatments that are as you say "been around for as long as RADEXT has been around".  Thus RADEXT had never had a rough consensus on this document - that is why we are here again.


People like myself are tired of bringing up issues on this document over and over again and have them being ignored.

I can just ignore this document at the IETF but the problem is that it will haunt me at the SDO level.  Several people told me that no one will take this document seriously and that I should let it go.  Then if that is true the why have it in the first place.  What is the purpose of this document?

In any case:

A document that tells you not to do something and yet does not offer a reasonable alternative is problematic

A document that makes assumptions about the reader's understanding of the RADIUS model - where in fact there is more then one model. Is problematic.

A document that states that SDOs can do anything they want but on the other hand says that the specification being produced are not RECOMMENDED is problematic.

I agree that with the following:  No introduction of new types as in the base attributes that RADIUS supports at least for now.

I dont agree that using a String to codify a complex attribute introduces any security risks in the base protocol - the dictionary driven side of things - because new new code has been introduced at that layer.  At the higher layer - the security risks are no different when anything new is being introduced including the introduction of a new attribute (of an existing type) - since such introduction requires code change.

I dont agree that complex attributes as those used by embedding them in a string or in a VSA are a bad thing. They are necessary.

And by the way, usage of an integer type to codify a set of flags (a bit map) has been used over and over again - there are lots of examples in the IETF such usage etc ....  i believe if you look at your email archive you will see copious examples from RADIUS.

I can go on and on..... and I have gone on and on in the past.


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