rfc6929 "tlv" type question

[Alan DeKok]

On Apr 12, 2016, at 9:47 AM, Vereecke, Katrien (Nokia - BE) <katrien.vereecke at nokia.com> wrote:
> 
> The RFC6929 states that "tagged" attributes must not be used in the extended-space, in stead "tlv" data types should be used.

  Yes.  Tags are a hack.  TLVs are better.

> ( 6.4 Design Guidelines for the New Types
> ...
> "tagged" attributes MUST NOT be defined in the
>     Extended-Type space.  The "tlv" data type should be used instead to
>     group attributes.)
> 
> With the extended format, can we indicate in the dictionary that certain attributes belong to different
> tlv attributes, similar as the tagged functionality before?

  No.  This is a topic of discussion in the RADEXT WG.

  The tags don't have this functionality, either.  What you're looking for is something like the Diameter "Group" attribute.

> e.g
> BEGIN-VENDOR    Alcatel-IPD format=Extended-Vendor-Specific-3
> ATTRIBUTE Alcatel-IPD-Ext-3-TestAttr-40          40   tlv
> ATTRIBUTE Alcatel-IPD-Ext-3-TestAttr-50          50   tlv
> ATTRIBUTE Alcatel-IPD-Ext-3-TestAttr-1           1 integer  => I want to indicate
> that this attribute Alcatel-IPD-Ext-3-TestAttr-1 is aswell part of Alcatel-IPD-Ext-3-TestAttr-40 and
> Alcatel-IPD-Ext-3-TestAttr-50 without having to duplicate and give another attribute name??

  You will need to duplicate it, and give it a different attribute name.

  RADIUS does not have the concept of name spaces for attributes.  e.g. you can't say

	Alcatel-IPD-Ext-3-TestAttr-50.Alcatel-IPD-Ext-3-TestAttr-1 = 5

  The names have to be *globally* unique.

> Similar as with the "tags" we want to be able to indicate that the same attribute can be received
> in the access-accept but with different tag.
> How can we achieve this behavior with the tlv extended attribute type without having to
> define different attribute-names for 40.1 and 50.1?

  You need to duplicate the attribute, with a different name.

  We're working on fixing this in FreeRADIUS, but it's not trivial.  And it would be good to get the IETF RADEXT WG to standardize on a solution.  But realistically, it will be 2 years at least before there is agreement in that WG.  It's slow...

  Alan DeKok.