RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft

["Avi Lior" <avi@bridgewatersystems.com>]

See inline.... 

> -----Original Message-----
> From: aland@nitros9.org [mailto:aland@nitros9.org] On Behalf 
> Of Alan DeKok
> Sent: Thursday, March 16, 2006 1:43 PM
> To: Avi Lior
> Cc: radiusext@ops.ietf.org
> Subject: Re: New Technical Issues RE: WG last call in 
> progress on VLAN/Priority Draft
> 
> "Avi Lior" <avi@bridgewatersystems.com> wrote:
> > That is fine.  But why should we balk when we are faced 
> with a complex 
> > attribute as required by a complex application. The 
> argument that it 
> > breaks the dictionary should NOT stop the work going forward.  The 
> > Dictionary should only parse it up to String.  Let the application 
> > decode the rest.
> 
>   Agreed.
> 
>   If the content of an attribute is a complex structure as 
> determined by the application, I would *prefer* that the 
> structure is defined elsewhere, and the RADIUS docs simply 
> reference it.

I don't agree.  Why should that be?

>   The contention comes when more and more complex structures 
> are shoe-horned into RADIUS attributes, where those 
> structures have no definition outside of RADIUS.  In those 
> cases, the preference is to use existing RADIUS types where possible.

Defining a RADIUS based RFC does not mean that your simple RADIUS server
has to implement that attribute.  It should though be able to transport
it pass-through though.  So it must be able to parse through that
attribute.

Again,  what you are saying if it doesn't fit into my dictionary then I
don't think its RADIUS.  The attributes do fit in the Dictionary  it
just that you have to go beyong the strings at a different layer.

So attributes like User-Name does not belong in RADIUS - by your logic.
Neither does 3162, CHAP etc.... Which all use encoding that are not
supported by RADIUS.

I think this logic is seriously flawed.

>   Where not, use the Diameter attribute format, and leverage 
> it's grouping mechanism to get complicated structural relationships.
>

Which will also not be RADIUS....

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