Re: Draft of extensions format

[Alan DeKok <aland@deployingradius.com>]

Peter Deacon wrote:
> 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.

  Pretty much, yes.  That's a result of adding the TLV format, which is
breaks the flat model wide open.

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

  Yes.

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

  That's the issue.

> Under the drafts scheme the attributes defined would be:
> 
> Input
> Output
> Input.Octets
> Input.Packets
> Output.Octets
> Output.Packets

  Yes.  It's not optimal, but it's been proven to work in 3GPP2 and WiMAX.

> Under my recommendation the attribute picture is flattened:
> 
> Input (TLV Attribute)
> Output (TLV Attribute)
> Octets (Attribute)
> Packets (Attribute)

  How do you encode the TLV's?  As 16 bit quantities?  They must be,
because otherwise all 256 attributes would be already allocated.

  And this suggestion is largely the Diameter Group attribute.  If we go
down that path, it would be preferable to use a method compatible with
Diameter, rather than one which is slightly different.

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

  Yes.

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

  What is the use-case?

  And we've had that discussion already on this list.  The consensus was
that there are just too many uncertainties and confusions with that
approach.  What does it mean when a User-Name is grouped inside of a new
TLV?  How do existing proxies deal with that data?  Do you put the
User-Name outside of the TLV, and also inside?

  These issues *must* be answered before your proposal can move forward.

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

  That is an admirable goal, and one which the document does not meet.
Existing information (3GPP2, WiMAX, vendors, etc.) shows that the re-use
isn't much of a problem, as it has been done.

  Again, what is the use-case for this?

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

  What is the use-case?  How is it "less complex"?  How is encapsulating
User-Name in a TLV "fully compatible" with current RADIUS?

  The answer to the last question is easy: it isn't.

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

  The TLV format as defined in the document extends the standard
attribute space.

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

  Please propose something *concrete*, with use-cases.

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

  The discussions Avi and & had were that we couldn't see a use-case for
TLVs needing more than 253 octets of data.  The WiMAX VSAs do *not*
support TLVs having large payloads.

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

  RFC 2865 defines Attributes.  The acronym TLV does not appear in any
standards-track RADIUYS document.

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

  Yes, thanks.

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

  It's semantics.  Calling a new attribute 1234 or 241.1 makes little
difference.

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