RE: Subtypes

[Avi Lior <avi@bridgewatersystems.com>]

> 
> Well, my point is that the current stuff will probably change 
> if RADext is chartered - we cannot expect that the current 
> stuff will just be rubber stamped.  

Sure.  But we have to be practical as well.  And if there is a huge
deployment that sometimes we just have to live with it.

>I think adding support 
> for subtypes will 
> change RADIUS.
It depends what you mean by changing RADIUS.

If by change you mean it will force folks to change their RADIUS
implementations then I don't agree.

To a RADIUS server the attribute would just look like a string.

RADIUS servers that have to dive into the attribute would have to parse this
string.

So all we are saying is that we want to define how something is encoded in a
string.

Lots of examples of that in RADIUS.  So what is the big issue here.

I think the real discussion should be based on an attribute by attribute
basis.

I could have a AAA application that has an attribute that is opaque.  What
is wrong with that?

A fair argument would be that a component of this string (a subtype) should
be exposed as its own attribute because of some reasons.

So if it is just a string encoding why do I raise the issue?  Because when I
do want to parse the string I don't want to have to support billions and
billions of different encoding styles.

To proffer an example:

I didn't hear too many folks complain about
draft-adrangi-radius-extension-for-pwlan-00.txt PWLAN Location Information
Attribute (2.1) the proposed encoding in that document would yield an
attribute that contained a string that would look something like this:
        
        Operator-name=GSM:T-Mobile, location-ID=44,location-
        name=starbucks-4,location-type=coffee shop, city= seattle, 
        state=Washington,country=us 

We want this now to be encoded using subTLV.  What is wrong with that?  It
saves space and it saves parsing time (when it needs to be parsed)

In my opinion a valid argument would be for someone to say Operator-name
should be its own attribute because blah blah blah....


>  It is then reasonable to provide further 
> justification why these changes are good and how it will 
> impact existing RADIUS standards and deployment. 

Since I don't think we are fundementally changing RADIUS (above argument) I
don't think we need justification.  I see this as more of an exercise of
providing guidelines to a practice that has been in place.

> Will these 
> changes be backwards compatible? 

Yes.  Its just a string attribute we are not adding a new type.

>I don't think that it is 
> sufficient to say that there are existing 
> vendor extentions so we should support them.


> thanks,
> John
> 

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