[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



"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.

  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.

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

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