RE: Subtypes

[Avi Lior <avi@bridgewatersystems.com>]

> 
> Avi Lior <avi@bridgewatersystems.com> wrote:
> > Okay so are you (David Nelson) going to ask the Sterman draft to 
> > flatten their attribute?
> 
>   As an implementor, my response is "Yes, please."

I doubt that the SIP folks would support not using what they have in the
draft already.  But I will let them voice their objections (or not).
 
>   Having packed attributes is irritating.  VSA's are packed 
> solely for namespace considerations.  They are logically in 
> the same "flat" attribute space as all other RADIUS attributes.
> 
>   Having "grouped" attributes (other than tags) significantly 
> changes the RADIUS model, in my opinion.  Even the RFC 
> 2867/2868 tagged attributes are a pain.  (See recent posts to 
> full-disclosure for an
> example.)


I totally agree with your comments about the grouped attributes.  Subtypes
should have been invented at the writing of that RFC.

> > RADIUS already has the machinery for coding/decoding 
> subtypes.  What 
> > is the problem?
> 
>   It's specific to VSA's, and therefore magic.

I don't consider VSAs magic.  I do get the point that there would be some
work.
But this work would only be required where the attribute is generated and
interpreted.
 
> > We use the scheme that the top level attribute is a string that 
> > contains subTLVs.  A RADIUS server that is not interested in that 
> > attribute will see a string.  This is exactly what sterman does.
> 
>   The same argument can be applied to any unknown attribute, 
> tagged, sub-typed, or other.

Exactly. So what is the problem?

> 
>   The benefit with re-using the existing attribute structure 
> is that intermediate RADIUS servers can filter new attributes 
> through simple dictionary updates.  They may not be able to 
> *process* such a request, but that can *catch* it.
> 
>   With new attributes having sub-types, it's often impossible 
> for any intermediate server to do *anything* with the 
> attribute, other than blindly forward it.  This can 
> significantly increase the cost of adoption.

But if those subtypes were not to be interpreted by intermediaries?

The guideline would be that subtypes would only be used if they were
intended for a particular application.  Prepaid is a perfect example so is
the Location Attribute and Digest attribute.

Attributes that are needed by intermediaries should not be subtypes.

Attributes that could be reused, that are general in nature should not be
subtypes etc.....

 

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