Re: Draft of extensions format

[Alan DeKok <aland@deployingradius.com>]

Peter Deacon wrote:
> I am suggesting what I believe to be a small change to make the existing
> draft better and more likely to be implemented in the wild.
> 
> - 16-bit Type field
> - All attributes (Including TLVs and sub-attributes) have distinct
> integer identities.

  We had discussed this option, and decided to propose something else.

>  Flipping a switch in a RADIUS server to
> support a new extension format is no problem.  However plumbing SNMP
> OIDs into existing infrastructure is a significant cost issue that is
> worth the attempt to avoid if possible.  For this reason I strongly
> oppose the draft in its current form.

  See git.freeradius.org.  WiMAX VSAs with nested TLV support was added
in less than 1000 lines of code.  Additional internal API changes
(mostly automated changes with a Perl script) were another ~5000 lines
of code.

  i.e. the data shows that the cost is relatively small.

> If you look at what some are doing with the existing nested formats they
> write string parsing functions and stuff them into opaque strings that
> are then processed by the *RADIUS server* decoded and sent over the
> wire. Not exactly the shining example of widespread support of TLVs and
> not something I care to see be repeated for standard attributes as well.

  Implementation choices (and limitations) are outside of the scope of
the document.  While they need to be taken into account, the evidence
shows that the proposed format has been widely implemented, no matter
how ugly the method.

> In your draft TLV is actually the same thing as Wimax VSA.

  No.

> When I say TLV is limited to 2^8.. I essentially mean the container
> grouping object (TLV) which is the same as Wimax VSA.

  No.

> So I still believe I am correct in that TLV in your draft does not
> provide the same fragmentation options as the wimax implementation
> because the entire container is limited to 2^8 while wimax is not.

  No.

  You have not understood the document, or the WiMAX specs.

> TLVs are used in more wire protocols than I can count.  When you say TLV
> I think attribute.. I don't assign the explicit use WRT containment /
> encapsulation with the description.  Container TLV. Envelope TLV... some
> qualifier to explain its use I think would be helpful to people with
> limited brain cells like myself but at the end of the day its a
> subjective assessment.

  I welcome the suggestion of a better name.  Until that happens, there
is no pre-existing "TLV" data type in RADIUS. So adding one should not
cause any confusion.

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