RE: Data Types defined in RFC 2865

["Glen Zorn" <glenzorn@comcast.net>]

Dave Nelson [mailto://d.b.nelson@comcast.net] writes:

> Glen Zorn writes...
> 
> > So am I to understand that, despite the multitude of counterexamples
> > and the lack of any explicit text even suggesting such in any RADIUS-
> > related RFC, you are claiming that the name of the V field in the TLV
> > construct denotes a formal data type (a thing apparently known only
> to
> > some secret society holding the same "internally consistent belief
> > system" (thought police, anyone? ;-)?
> 
> Well, your previous posting claiming to be able to implement an
> advanced
> server implementation 

Actually, I didn't claim to be able to implement it myself, nor to have done
so,  The server I have was done by people a _lot_ smarter than me.

> that intuits the syntax of a data model from the
> data
> stream itself notwithstanding, 

Isn't that the definition of a data-driven parser?  

> RADIUS *has* a formal, written data
> model.
> Many implementations rely on it.  It's a very simple data model.

So simple and so unnecessary (probably why it is so rarely used).  One of
the beauties of the TLV format is that the type completely defines the
value.

> 
> I think this extended discussion of what constitutes a "formal"
> definition
> of a new data type in the data model constitutes "protocol lawyering",
> a
> debate about form without any substance.

OK, then how do you know the data type of a new attribute?  Is the Value
field of the Login-IPv6-Host attribute of type "IPv6 address"?  If so, do
_all_ attributes of type "IPv6 address" assign special meaning to the values
0 & 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF?  If not, then it's mot of type "IPv6
address" is it?  A set of formal data types without any way to distinguish
between them is useless, except for use as a bludgeon.  If you really want
to develop a real data model for RADIUS, shouldn't it clarify the protocol
operation instead of muddying it?

> 
> In seeking to debunk some of these data model additions, you are
> apparently
> attempting to build a case for the precedence of using the RADIUS
> String
> data type to contain non-self-describing data structures.  

Not at all.  As I mentioned above, RADIUS attributes are completely defined
by the Type and the description.  

> This has
> been a
> point of debate in the RADEXT WG for several years.  The WG consensus
> is
> captured in the Design Guidelines draft.  

"Consensus" in this WG is, quite frankly, a joke.

> The String data type should
> be
> used for actual strings, or for opaque blobs of binary data, for use in
> some
> other protocol component, e.g. EAP.  There are specific exemptions to
> this
> recommendation that are spelled out in the draft.
> 
> 
> 
> --
> 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/>


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