Re: Draft of extensions format

[Peter Deacon <peterd@iea-software.com>]

On Thu, 2 Sep 2010, Alan DeKok wrote:

> > The underlying question for me: Is this just a solution in search of a
> > problem?  With my recommendation the same underlying goal is met and the
> > dot naming exercise is unnecessary.

>  The dot naming exercise *also* allows for naming and allocation of
> nested TLVs.  Without it, a TLV "1" could be seen as being in conflict
> with attribute "1".

>  Your solution has a problem (conflict) that this solution does not
> have.  It provides for allocation of ~8K attributes which you say here

I think this boils down to my advocating for a flat model where each item 
stands alone while the draft is advocating a hierarchical model where each 
items identity is strictly dependent on its parent.

When draft says TBD.1 it means attribute 'TBD.1'

When I say TBD.1 it means User-Name (Type 1) encoded in whatever TBD is. 
(TLV, Extension..etc)

For example lets say I have two TLVs (Containers) labeled Input and 
Output.

Input
- Octets
- Packets

Output
- Octets
- Packets

Under the drafts scheme the attributes defined would be:

Input
Output
Input.Octets
Input.Packets
Output.Octets
Output.Packets

Under my recommendation the attribute picture is flattened:

Input (TLV Attribute)
Output (TLV Attribute)
Octets (Attribute)
Packets (Attribute)

On the wire the basic structure of the packet is the same with octets and 
packet data encapsulated within input and output TLVs.

This boils down to a classic flat vs hierarchical schema argument.

As I see it the benefits of my recommendation are:

1. More flexibility.  Existing attributes that were never labeled as 
groupable can be grouped.  For example I could create a generic TLV 
container labeled 'suspect' containing all attributes that an intermediate 
proxy does not like.

2. "Like" attributes within TLVs can be reused.  In the example above 
Octets and Packets need only be defined once and then apply to Input, 
Output and maybe a future "Combined" TLV container.  To some extent this 
is just a schema/definition argument.

3. The standard VSA space can be extended with less complexity/wholesale 
change to existing infrastructure as every attribute definition stands 
alone and is therefore fully compatible with the current model.

I think its important to recognize there are two separate issues: 
Extension of standard attribute space and introduction of TLV (Container). 
The two address separate concerns.  It may not be in everyones best 
interest to marry them.

Disadvantages of my recommendation:

1. What is allowed in a group may or may not simply be defined by 
declaration in a dictionary.  Need a concept to declare constraints (LDAP 
"object classes").  I would argue you would need this anyway if there was 
interest in for example declaring minimum required sub attributes for a 
specific TLV.

2. There is a strange aspect in that the additional space has to be 
"bootstrapped".  Either hardwired or configuration to say standard space
> 2^8 goes to a TBD extension attribute along the same lines as
Vendor-Specific (26) in the implementation.


Anyway after looking over the draft again I have some (un)related 
comments:

I think fragmentation support for 'jumbo' attribute values is a good thing 
however with the draft there does not seem to be a way to do both TLV 
grouping and attributes with large payloads at the same time.  IIRC wimax 
VSAs support this.  Could perhaps just get rid of TLV format and reuse the 
extended type as TLV?

In RADIUS everything is a "TLV" .. If it were labeled Container TLV or 
something similar to disambiguate the data types actual intended use it 
would be less confusing (to me).

2.4.3

"to the number of the encapsulating
   attribute ("241.1"), to yeild "245.1.1".  "
                           ^^^^^ should be yield

               ^^^ should be 245?

> isn't necessary.  And even if it was necessary, our proposal can address
> that problem, too.  If your solution allows for TLVs, a "dot naming"
> scheme is *also* necessary for it, too.

To the extent relationship between TLVs and attributes need to be defined 
your correct.  At the same time however it's not required when TLVs are 
not used.  In my view an important difference.

>  On the "plus" side, I don't see a lot of differences between the two
> solutions.  On the "negative" side, there are issues with your proposal
> that our document does not have.

I would think the wire format is similar either way.

regards,
Peter

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