RE: Possible Resolution to Issue 198: Attribute Concatenation/Splitting

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Bernard Aboba <> supposedly scribbled:

> I am wondering if the following approach to the
> concatenation/splitting problem with NAS-Filter-Rule might work: 
> 
> a.  Add a single octet Tag field:
> 
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      
>      
>      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |  
> Type      |    Length     |      Tag      |      String...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
> 
> b.  Specify that a multiple NAS-Filter-Rule attributes with the same
> value of the Tag field represent a single rule and are to be
> concatenated when translating to Diameter NAS-Filter-Rule.  
> 
> c.  Prohibit reordering of NAS-Filter-Rule attributes.
> 
> d. Suggest that ASCII values (e.g. '1'=0x31, etc.) be used in the tag
> field so they can be entered easily. 

This sounds very similar to what was discussed in Montreal.  I think that this would work fine, and particularly well with the VSA method of extending the attribute space.

...

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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