Re: Draft of extensions format

[Alan DeKok <aland@deployingradius.com>]

Peter Deacon wrote:
> My thinking is the definition is more important than the wire format.
> The wire format is out of sight out, out of mind.

  The wire format has a strong dependency on the definition.  They
cannot be treated independently.

>  The universally
> standardized definition of attributes is what I am most concerned with.

  The document defines what it means by attributes.  It explains the
difference between the new format and the traditional format.  It
explains how the new attributes should be interpreted, and how they can
be handled in traditional systems.

> This was just a hypothetical to provide an example usage of which I have
> an infinite supply so if you need more just ask and I'll rattle off more
> use cases until everyone is satisfied.

  I would suggest writing a document with a proposal and examples, as we
have done.  Right now, this conversation isn't making much progress.
Nearly every subject (requirements, wire format, examples) has been
vaguely defined, and has required repeated questions asking "what do you
mean?"

  I'm sorry, but we put the time and effort into creating a draft
explaining exactly what we mean.  I would prefer to discuss that
document rather than to help you debug and design your proposal.

> I think fundamentally there is a difference in the efforts you cite have
> a finite scope to a specific problem domain.  The WG is defining a
> broadly scoped attribute that applies to many disparate problem domains
> and so what is workable in these cases may not be ideal in the general
> case.

  That is so vague as to be unanswerable.

> The issue is the attributes are defined based on their parents and don't
> standalone and so don't fit with the current flat model of defining
> attributes with integer values as self-contained entities.  Subgroups
> require implementation infrastructure change to support.

  I presume at this point that all major RADIUS servers support 3GPP2
and WiMAX.  This means that they have already implemented TLVs as
proposed in the document.

  i.e. the TLVs in the document are *not* new to RADIUS server
implementations.

> Again assume TLV grouping is *NOT* used in this case.  The drafts scheme
> has a dual use to extend the standard space AND support TLVs.  The
> problem is it should in my opinion be possible for a client to use use
> extended attributes without having to support TLVs and the sub attribute
> encoding scheme that go with them.

  This is a specious argument.  RADIUS clients implement the features
they need.  If they don't need EAP, they don't implement it.  The
document changes nothing of this behavior.

> My recommendation is easier because each attribute retains a unique
> integer identity as is current practice for all standard attributes and
> most VSAs and thus easier for client vendors to implement extended
> attributes within their existing systems if they do not also have a need
> to support TLVs.

  You're confusing the implementation data structures and the names in
the standards.  The document makes no requirements (or assumptions)
about internal implementation data structures.

> In terms of definition of attributes RADIUS is traditionally very
> loosely structured.  Attributes you don't understand can be tolerated
> even tho there is no way to communicate the information attribute x was
> ignored.

  The document does not change that behavior.

> In terms of adherence only Recommend they are followed and give clients
> or servers the option of rejecting TLVs if the constraints are not met.

  The use-case is... ?

>>  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.
> 
> I double checked and I don't believe this is correct..  See:
> http://www.juniper.net/techpubs/software/aaa_802/sbrc/sbrc70/sw-sbrc-admin/html/WiMAX_Overview6.html

  You are not correct.  I suggest reading the WiMAX specifications.

> I have found other material that explicitly say the continuation flag
> may be used specifically with WiMax TLVs allowing up to 4k or so TLVs.

  No.  There may be up to 4K of TLV's in a WiMAX VSA.  But each TLV can
only carry 253 octets of data.  The hint should be that the
"continuation" flag is *only* at the VSA layer, and not inside of each TLV.

> In any event this statement seems a little confusing to me.  On one hand
> you introduce a container that supports fragments but on the other hand
> say that there is no use case in TLVs supporting fragments.

  I suggest reading the use-cases and examples again.  The document
explains this, and I have explained it here.

> In terms of a use case my Proxy-Suspects TLV would work here as well as
> it needs to potentially be larger than 2^8 for cases where the proxy
> server does not like multiple attributes.

  That presents a solution.  I still have no idea what the problem is.

> TLV is universally understood to mean Type-Length-Value which all RADIUS
> attributes are.  This is the source of my confusion.

  The standards are written to be consistent, without referring to
unwritten "universal understanding".  There are many things that are
"understood" in RADIUS but which are unwritten, and therefore not
standardized.  See this mailing list archive for many examples.

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