[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: New Technical Issues RE: WG last call in progress on VLAN/Priority Draft
> -----Original Message-----
> From: email@example.com [mailto:firstname.lastname@example.org] On Behalf
> Of Alan DeKok
> Sent: Thursday, March 16, 2006 1:43 PM
> To: Avi Lior
> Cc: email@example.com
> Subject: Re: New Technical Issues RE: WG last call in
> progress on VLAN/Priority Draft
> "Avi Lior" <firstname.lastname@example.org> 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.
> 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
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 email@example.com with
the word 'unsubscribe' in a single line as the message text body.