Re: Draft of extensions format

[Alan DeKok <aland@deployingradius.com>]

Peter Deacon wrote:
> Even with the TLVs there is still a unique integer identity.. IE each
> wimax VSA itself is nnn not nn.nn.nn.

  Uh... the document proposes that each TLV have a unique integer
identity.  It's called the "type" field of the TLV.  This is the same as
WiMAX.  The "dotted number" scheme exists solely for IANA allocation.

>  The sub-encodings can be
> addressed using the text encoding scheme that virtually everyone seems
> to be using so that in terms of referencing a WIMAX attribute externally
> its abstracted and treated in terms of external interfaces as an
> ordinary attribute and value string no different than User-Name.

  i.e. referring to an attribute by name.  This is irrelevant to the
numbering scheme.

> With this proposal for the first time in a down-to-earth practical sense
> what look like SNMP OIDs would be practically necessary to reference
> ordinary ungrouped attributes using the extension types added after the
> standard space was exhausted.

  This argument is nonsensical.  I could make the same statement about
your proposal:

  A 16 bit attribute number?  The horror!  Everything in my
implementation assumes only 8bits!  Now I have to use *16 bit* integers
to deal with attributes?  You must be joking!  That's too much code!

> Another approach I would favor is to acquire an enterprise number for
> future RADIUS attributes just treat them as VSAs and have this draft
> focus entirely on the grouping problem and sub-attributes.

  Perhaps you missed the previous RADIUS extensions document, which
proposed exactly that.  The consensus was that the scheme was unworkable.

>>  i.e. the data shows that the cost is relatively small.
> 
> What data?

  The data I posted, and which you deleted in order to claim that no
data exists.

>  Is there a survey you can point me to?  Our own first hand
> knowledge paints a much different picture.  I would be interested in any
> data showing the cost to supporting infrastructure that you or anyone
> else has compiled on the subject.

  If 6K lines of changes ("diff / patch" format) too high a cost for
you, then your programmers are too highly paid.

> Can I ask how would you define a grouped VSA with multiple
> sub-attributes in your draft where the total length of the entire VSA
> exceeds the 1-byte type field?

  For one, the question is meaningless.  What does it mean if "a VSA
length exceeds a type field"?

  If I interpret your question properly, the answer is to read the
document.  Section 7.3.  It doesn't matter if the data is a 251 octets
of "a", or 251 octets containing a sequence of TLVs.

  If that is still unclear, we can add more thoroughly worked examples
in a future rev of the doc.

> Having manually coded Wimax VSAs I know how to do this in Wimax.  I just
> don't see a path to doing it in the current draft as written.

  For the life of me, I don't see why.

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