Re: Data Types defined in RFC 2865

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
...
> Moreover, within the value field of each attribute, RFC 2865 includes the
> data type:
> 
> a. "String" for type string.
> b. "Address" for type address
> c. "Value" for type integer
> d. "Text" for type text

  These are issues of inconsistency and terminology in the RFCs.  The
RFCs have always used "address" for IPv4 addresses.  Pretty much every
implementation I've seen uses "ipaddr" as the name of that data type.

  Similarly with other data types.  Where they are simple and often
re-used, implementations define names that are *different* from the
RFCs.  e.g. "ipv6addr", and "ifid" for IPv6 address, and Interface Id.

> No attributes of type time are defined in RFC 2865 or 2866. 
> 
> Looking at other RADIUS RFCs, the inclusion of the data type within the
> value field is less consistent. 

  Which is the source of the current discussion.  If the documents had
followed the practice of RFC 2865, they could have contained a section
describing the data types that they were defining.  They failed to do
that, so we now have curious claims about addresses being IPv6... and
not IPv6, all at the same time.  (Depending on which argument best suits
the current message, consistency be damned.)

> For example, RFC 2867, includes a type of "Lost" in Section 4.2 for
> Acct-Tunnel-Packets-Lost (4 octets).  It seems likely that this attribute
> was intended as type integer, rather than a "lost" data type. 

  The implementations I know of use the type "integer" for this attribute.

> In RFC 2869, the term "Value" is used in the value field for attributes that
> are not integers (e.g. ARAP-Challenge-Response in Section 5.15). 

  Agreed.

> RFC 3162 seems closer to the conventions of RFC 2865 & 2866, although the
> "Address" type used is 16 rather than 4 octets in size (IPv6 vs. IPv4). 

  Which is to even the most naive reader, not the same as the "address"
field defined in RFC 2865.  Hence my recent errata.

  However, everyone "knows" that the Address type in RFC 3162 refers to
IPv6 address.  The only disagreement is the message-by-message reasoning
of Glen, where it *is* an IPv6 address in one message, and
simultaneously *not* a new IPv6 address in another.

  Personally, it matters less to me whether we call it "Address", or
"IPv6 address", or "magic fairy dust".  All I want is a consistent
definition, so that I can talk about it without someone accusing me of
inventing the definition.

  I would ask for a definition from Glen, but it's clear that his
definitions are contradictory.

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